Cumulative Layout Shift (CLS) Challenge

[pixelfabs]

I'm having a hard time solving one specific challenge. For this, I installed a new Hugo and clean PaperMod theme. It works as is, Google Lighthouse = 100% on everything.

However, as soon as I add 1 image as cover to a post, CLS changes to 0.136 in list pages (which suppose to be under 0.1).

When adding a second cover, CLS changes to 0.253.

And so fort. At some point, it stops at 0.7xx. Only CLS changes, nothing else!

One solution I found so far is adding min-height to .post-entry in post-entry.css, but that didn't do anything. It is already added to .first-entry in post-entry.css by default.

The second solution I tried was adding image height/width to cover.html, but either I don't understand what I'm doing or it just didn't work.

Lighthouse reports that the shifting elements are:

• article.post-entry
• header.entry-header
• section.entry-content
• footer.entry-footer

Basically, the rounded white box on list pages. NOTE: it starts to shift at the second box, the first box seems not to be the problem.

My question: where should I be looking to solve this issue?

[igruenig]

My pull request #519 should solve your issue. Can you confirm this?

[pixelfabs]

I re-tested everything again with a clean installation. I have 2 dummy post + covers. CLS is 0.219 (everything else is 100%).

Then I added your pull request #519 and CLS is still the same. Which is odd. I figure I must be doing something wrong. So I remember something about Leaf Bundles and Image Processing feature of Hugo. My images were in /static folder.

I changed the 2 dummy posts + covers into leaf bundles and tested again.

Pull request #519 + leaf bundles = CLS of 0!

Sidenote for anyone reading this: My images were in /static folder, which are unaffected by Hugo's Image Processing. (or PaperMod for that matter) (Image Processing in Hugo Docs). PaperMod uses Hugo's image processing feature and therefore your images need to be either leaf, page, branch or headless bundle (Page Bundle in Hugo Docs)

[igruenig]

Thank you for testing! Great you could figure out the reason why it wasn't working.

Just to confirm what you are saying: The code I implemented relies on image processing. As far as I can tell, there is no easy way to get the width and height of an image if it's inside the /static folder. For cover images this should not be a problem, as you can save them somewhere inside the content/ directory.

[pixelfabs]

Just to confirm what you are saying: The code I implemented relies on image processing. For cover images this should not be a problem, as you can save them somewhere inside the content/ directory.

Confirmed. You're on point.

As far as I can tell, there is no easy way to get the width and height of an image if it's inside the /static folder.

Confirmed. You're on point. Hugo's docs: The image is a Page Resource, and the processing methods do not work on images inside your /static folder. At the very top

@igruenig BUT! Apparently, there's a way to access /static images. You simply mount the folder /static to /content (no need to move it). See this post by Hugo dev

And obviously, 9 out of 10 times I'm an idiot for applying old fashion directory structures while the world got itself in a damn hurry ;-)

So, next big plan: move /static/img folder to /content and enjoy CLS 0 :-D

[pixelfabs]

Just a little update: I have moved all images and covers from /static and made page bundles. And OMG! The speed gain is staggering!

I already managed, before using page bundle, to gain speed by using QuickLinks library, lazy load library (on top of what PaperMod already has) and converting images to webp. But with page bundles and Hugo's image processing, it's a completely different level.

You cannot actually measure this speed gain technically with Lighthouse, but you can definitely "feel" it. It falls under Chrome User Experience Report.

One thing to keep in mind, you will end up with 3-4x more images, since for each resolution a new image is generated. This will bloat your git repo. I solved this (or trying at the moment) by using Git LFS.

But again, the speed gain is staggering! It's definitely worth it if you intend to serve a lot of images to mobile users.

I have also thought about where this idea of using static/images comes from, and it's a remnant of WordPress mindset or any other traditional CMS. In those cases, the database connects everything together. But since Hugo doesn't have a database in the traditional sense, the static page is what holds everything together, hence Page Bundles.