And yes, this is the blocs site. Got 94 on Perfomance half an hour ago, but still. Adding an image size via the attributes worked. Bit cumbersome, but hey, I can live with that. Quite a few things BSS does better in terms of UX though.
The only thing that rather annoys me, is that I have to manally edit the styles.css to add font-display: swap to every font-face. And I have to do that after every upload .Wish there would be an easier way.
Your Lighthouse / Pagespeed reports are very similar and it seems that your large logo is the issue in the Blocs report. That logo would be better served as a much smaller SVG.
FYI you don’t have a working webP fallback, so your images don’t appear on most browsers, and as a result, your results are better than they would be if you had the webP fallback images.
It is a testament to how well Blocs has been imlemented and all of the important stuff is available within Blocs to build a 100% site. Looks like Bloc5 has everything that’s needed to keep Google happy.
Im not sure when this requirement was rolled out, however, I’m guna look to add an automated way to do this to images when you export. So those tags are added when required.
Yeah Blocs 5 has WebP generation (with fall back), but only for jpegs and png images. When a WebP image is used by default Blocs just leaves this and does not currently do the reverse and generate jpgs etc.
Fantastic feature too that provides the tools to use webP with fallback. The way Blocs5 works is fine, but users need to understand the issues and implement it with the tools provided. No matter how you build a web site there is a tendancy to add just a webP image, and be done with it. Hopefully Lighthouse / Pagespeed will start to check for it because it can really have a negative effect on the user experience if the images are missing.
The CanIuse picture painted is that there is 97% browser native support for browsers, but this is hugely skewed by the high number of Android mobile using Chrome. You can see this if you set the CanIuse view to Usage Relative. The Mac picture is pretty grim with only a small proportion of Mac users being able to view webP images and CanIuse don’t accurately reflect the fact that the macOS is also a factor and not just Safari version.
I’ll try that (again). Tried before, using single elements, didn’t work.
Update: Tried, but does not work (for me). Maybe it’s because the class editor automatically adss a . to the first item I enter, so it says .p, h1, h2, h3, h4, h5 in the class editor.
I also tried to add it to the code editor. No success. I even tried to add @font-face with a general font-display:swap to the code editor, and it - magically - improved the perfomance score a bit, but it still got me the google warning concerning the font-display.
The only way for me to get rid of that, is to add font-display: swap to the two font-face settings in the styles.css file.
Why is it in the class editor anyway? Why not a general project setting? @Norm
Thanks Gary, that’s interesting. The url you used is the version I made with BootstrapStudio 6.2, not Blocs (add /blocs to the url for the Blocs version).
What Browser did you use? I tried in Safari, Brave and Firefox and it shows on those. Fun fact: The background image (my logo) is a png file, not even a webp.
I used Safari 15.6, one of the many browsers that doesn’t display webP images. Although the issue is not just browser related, it is related to the macOS and Safari version combination in the Mac world. You need to test in a browser that doesn’t support webP for the testing to be effective.
I tested both of your URL’s and the png logo was one of the main differences that I could see that Lighthouse / Pagespeed flagged up. This is nothing to do with webP.
The webP images not displaying is a totally and big different issue and most likely due to there not being a fallback image. Google doesn’t check for this.
The key difference between Safari and other browsers is that Apple set format compatibility as part of the OS, whereas Chrome and Firefox install it at a browser level. That means you need a recent Mac OS to avoid problems if you only use WebP.
I think the Blocs solution for WebP is quite clever and simplifies the process for users. It enables you to work normally with Jpg and Blocs will then create WebP on export. If the browser is capable of showing WebP that is loaded, otherwise it presents the Jpg.
One word of advice on the setup here. If you already have web optimised Jpg images there is a chance they will look a little soft following a second conversion to WebP, so you may not achieve the results you wish on existing projects. This is simply because multiple file saves with compression damages quality.
Most web browsers these days are fine with WebP, so I would be inclined to save the Jpg for web, but at very high quality. It will be a little heavy like that for some, however almost everybody will be seeing a good quality WebP.
I migrated one of my projects, and I can see a slight difference in image quality. It’s not bad, I think most visitors will not see the difference. The image file size savings are very apparent. Going forward, I’ll keep an eye on .jpg quality. Migrating projects will be a lot harder to track down original images and a lot of work to redo. I guess I’ll have to experiment with some.
It will largely depend on the subject matter and also how they were saved as Jpgs originally. I have also found that some subjects just don’t convert at all well to WebP, though cases are rare. I have some images of 3D models exported from Maya and in some cases WebP produces very odd jagged lines, which doesn’t happen with Jpg or AVIF. This was evident with a couple conversion apps, before Blocs even offered this.
So does this mean if we have WebP as primary, if the Browser cannot display that format, and yet we have jpeg, jpg, png or even avif in the same Folder the Browser will call for the compatible format?
I can’t wait for @Eldar, The Blocs Master, to deliver his new tutorials on Blocs 5.
