My goal was to get everything green and higher than 95% at Core Web Vitals Assessment with a default page build by BSS.
After some dancing around I’ve managed it. I want to share this experience, because I would like to see some steps and workflows in BSS used by community.
BSS should imo get 100% of Core Web Vitals out of the box - it is a static page builder. But the default page, without any changes and exported with following settings:
got 86-89 points.
I’ve got reliable 96-98 points after following improvements:
- Image compression and converting to .webp,
- Server-side text compression, for Apache with
script.min.js at the body’s bottom,
baguetteBox.min.css inline as
<style> at the body’s bottom,
styles.min.css locally saved as link in the head,
bootstrap.min.css inline as
<style> in the head
I would be absolutely happy to see these options in BSS:
For every CSS and JS file to make decision:
– host at CDN
– host locally
– insert as link in the head or in the body’s bottom
– insert inline as style/script in the head or in body’s bottom
srcset and generate images for every breakpoint - to fix the last issue I didn’t fixed - “properly size images”. The issue exists becaus the same (big) image is used for all breakpoints.
Image compression and converting in webp at adding an image to project.
Thank you for the suggestions!
This is a good idea. We will think of a way to let users generate small versions of images in their project for this purpose. If small versions are present, the app will generate srcset automatically.
Converting images automatically on export will make things a lot slower, but if we extend the above idea, we can have some kind of tool which converts to webp or avif when the user requests it.
Our export is already quite complex and this would complicate things further. We have an update coming which makes all built-in libraries respect the
Use CDN export option, so it will at least help in that regard.
It’s worth pointing out that Google exaggerates the need for page optimization mainly because it benefits THEM. On a 4G connection, it’s hard to notice the difference between a Lighthouse speed score of 85 and 95. On 5G, it’s impossible.
Indeed, for me, staying in the middle of Berlin and using 4G, the main bottleneck are mutiple network latencies rather that slow sites. But from the SEO point of view, where I’m come from, as long Google values passing of Core Web Vitals assessment as ranking factor I must turn the speed of my client’s sites as high as possible. And, finally, maybe caused by my professional bias I’m not familiar with people who make websites and don’t want to rank high at Google.
I dont think any suggestion should be implemented as forced and mandatory. Those who dont want to make their routines more complicated just dont make use of. Those who knows about the value can use them as options.
Specially about image compression and conversion im absolutely with you - there are multiple people who manages all imaging workflows outside of CMS - those dont need this inside BSS.
According to most of the stuff I’ve read, the value of page speed in terms of page rank is marginal at best.
I’m not saying you should ignore page speed, but if your page is already 80 or higher, I would not obsess about getting it above 95. The user won’t notice the difference and it’s unlikely your rank will go up as a result.
In this test, improving page speed from 28 to 100 did nothing for the page rank.