While working on a project, we implemented code splitting with the aim of improving website performance and a better Google Lighthouse audit report.
One metric however, proved continuously difficult to manage - Cumulative Layout Shift.
This partly has to do with splitting the code in combination with the placeholder structure. After some investigating and testing different page structures we found that tweaking the placeholder layout yielded positive results.
This is undesirable as it could potentially cause other Lighthouse reports to perform poorly. But it can be avoided by implementing code splitting.
However, we noticed an issue occurs with nested placeholders and the way component chunks are rendered on the page - specifically the order of appearance. For example, let’s look at typical a page structure of:
Because “header”, “main”, and “footer” are root placeholders, they would load first. They will bring with them any component chunks, and then the nested placeholders (“content”) will do the same.
In the following scenario the header and footer components would load first, followed by all the content, creating a large layout shift as the footer gets pushed down.
When reviewing the stack trace, it looks like this:
One way to minimise the layout shift and preserve component chunking is to eliminate the nested “content” placeholder and limit the use of other nested placeholders above the fold.
Any components that can be placed directly onto the “main” placeholder will be rendered in the expected sequence (for example any hero components).
The stack trace now looks like this:
Below is a Google Lighthouse Performance example of a page using a nested “content” placeholder:
And this a Google Lighthouse example of a page using a root “main” placeholder:
Our development team is constantly looking at ways to improve the development process and user experience.
We work on exciting design and build projects often on CMS like Sitecore. Get in touch to find out more.