I have an ongoing issue with my sites’ Google Page Speed results.
More and more customers complain about bad results due to “unused JS” – which I (not an HTML developer) cannot really solve.
Dear @Franzi_Sitejet_Team, it would be great if you could check what else can be optimized to reduce unused features automatically.
Also, it seems that formerly used but deleted Presets still remain in the code. Identifying which of them are redundant is difficult. Would be great it the system deleted them automatically. (Or am I mistaken here?)
Would love for “SiteJet’s SEObilities” to be improved …
Hey @Daniel_Kaesmacher - moved this to the helpdesk for this topic. I like to give you some insight and point you to a few threads we had about this topic already.
Aside from that, this can also be a case by case / website to website situation. If you like, I am happy to check on one or two specific websites for you to give you some feedback.
Lucian gave a great insight to Lighthouse/Pagespeed:
Well, @Andre you can say that this is not a big deal. But from the point of view of clean code, in my humble opinion, this is an issue. You may tell that this is not a priority, but I think it should be handled sooner or later by cleaning code before generating the production version of the website.
Clients are not all the same, and they can be picky on this subject, and Google Speed Insight output. And they are very aware, especially with all the Core Web Vitals communication and articles out there on the web. So, it is better not losing them by delivering a clean version of the site. I’m sure there is a way to do it automatically.
Just imagine, in case I test all presets on a website and then keeping only a few, the amount of non-used code we deliver. From a developer point of view, I don’t like it, as it is not optimal.
I’m very disappointed to read the responses from Sitejet, and the example used in your argument (Google Workspace not passing page speed insights) is just poor!
Google Workspace has global brand authority, people are more likely to be patient with Google, and if they are visiting that site, it’s because they are a customer or at the bottom of a sales funnel.
You cannot use this as an example of a comparison to a user of Sitejet who probably is trying to build their web presence, doesn’t have a global brand and needs more in their favour for their web sales funnel to convert.
Going back to 2016, we can read that Amazon found an additional 100 milliseconds in page load time cost them 1% in sales. See more
Typically for a CMS to operate, it will always have additional JS/CSS, which is the compromise users must make if they want to use a drag-and-drop system.
You should be honest with this and then at a minimum, guide on best practices on what users can do to improve their page speed whilst working with Sitejet.
e.g.
-Use smaller images and smaller formats (WebP)
-Use a CDN, if possible, for media files
-Minimise animations, videos and the number of fonts (which also is better U/X)
reduce/minimise the number of third-party tags/pixels as these add code bloat.
I wouldn’t put it as bluntly as @Naz_Haque said it, but I do also feel there is room for improvement.
For example: Convert all displayed images as actual WEBP.
About the unnecessary JS/CSS – I cannot assess whether or not SiteJet already addresses this to the best of its ability, but this issue does seem like a pressing one.
In either way: When clients look to Google’s tools and find orange or even red page speed results, the answer above does not help us as agencies …
How credible could the answer be that Google’s own assessment of performance should not be taken seriously?
Andre and team sitejet, apologies if my bluntness appeared rude; that wasn’t my intention; I did want to convey my disappointment, though.
I do have an overall level of dissatisfaction as a customer since 2021 and seeing few meaningful updates and progress specific to SEO matters with plenty of discussions about this. It just seems since being acquired by Plesk, there’s nothing meaningful happening.
All your updates are cosmetic, which means nothing if you can’t get the website to rank for competitive terms.
Just like to point out a few things mentioned between the lines here:
Just a quick one on this. I can currently exclude that this will be realized anytime soon. Why? Because we have a compression implemented, but we like the users to choose for their own which file type the like to use.
It is not a disadvantage to use WebP. For most people, the amount of compression is negligible, but for visual sites like photography or graphic design portfolios you want your visual quality at maximum.
So now, you can choose between different image formats and see what works best.
Hi! Related to your issue about keeping the non-used presets.
From a CSS perspective, Sitejet uses SCSS with the @mixin directive. By default(this is an SCSS feature) so, if you don’t use them (you don’t @include them), then, they will not be included in the bundled CSS.
One suggestion is that, if you know you’re not using a specific preset you can simple comment that line in the Code → CSS (panel)
To be honest, I find the code generated by Sitejet to be clean. Can you explain what “clean code” means for you(from my experience for different people means different things)? Can you explain what is not clean?
Related to PageSpeed Insights. I’ve also tested a lot of Platforms/Website Builders but, they all get similar hints in PageSpeed Insights (especially “Reduce unused JavaScript”).
Can you give an example of a Platform/Website Builder/Framework that doesn’t show the “Reduce unused JavaScript” hint in Google PageSpeed Insights?
On the SiteJet’s SEObilities, part… I think there is room for improvement, I have also added a few feature requests myself. I suggest also adding yours or voting on the existing ones.
Hi! The main idea with the examples like “Google Workspace” was to illustrate that Google Speed Insights metrics don’t give you the entire story of a website or SEO. Google Speed Insights just gives you some recommendations.
Amazon is an e-commerce website, and the site loading speed impacts, in this case, the conversion rate + bounce rate. So, in Amazon’s case is important because they have huge traffic.
There’s so much a web framework/cms/builder can do, but in the end, I think the page loading speed falls more on the web designer’s side responsibility and the way the page is designed/structured.
I recommend adding your suggestions as feature requests or voting on the existing ones.
Thank you for your message and clarification about the @mixin use.
Please allow me to expose the issue again: Imagine you start a website from scratch or from an already made template, you play around with the components (presets), you add, you test, you don’t like, you remove, then add other components, and you keep doing this until you’re happy with your design. Now you are ready to publish. What is happening is that you are also publishing all the presets that have served as tests (those which you have decided to discard) - let’s call them draft presets -, along with those you have kept. And this is the issue I wanted to point out.
It would be great to not publish the draft presets and only ship the used ones. The best way to do so, is to implement a presets cleaner, that is triggered just before publishing. Until implementing this cleaner, the workaround would be to clean them manually (but it is risky, as @Andre said in this post). In this case, it would be better to have a tutorial that helps us to do so, until the implementation of the cleaner.
In my humble opinion, having presets cleaner is a must. Using tools like SiteJet are created to ship website rapidly and not waste our time in cleaning code (and here is where I refer to “clean code”).
In your screenshot, you referred to preset CSS code, but of course the same applies to the JavaScript code that comes with the presets (if any).
The goal is to only ship what we use.
And regarding your comment:
⇒ Even if when we only ship what we use, there will be still some hints (“Reduce unused JavaScript” or “Reduce unused CSS”), but it will be reduced compared to shipping with draft presets.
And it is normal to have these hints, as you said (which is common, as not all JS or CSS code are executed on page load), but just keep them reduced to the maximum.
Hope this clarifies my point, and thank you again for your reply.
Please point me to the SEO features that you mentioned, so I can upvote them.
Hi @AJ_Joe ,
Thanks for the details. Indeed having a presets cleaner would really streamline the entire process. This would be a feature request that I would definitely vote for.
Here are some SEO-related feature requests that I’ve opened.
Thank you for the SEO related features requests links. I have already upvoted one of them. I upvote the second right away, which is good for semantic HTML.
