The Impact of Cumulative Layout Shift on Bootstrap 4 Grid System

Question

The Impact of Cumulative Layout Shift on Bootstrap 4 Grid System

Experiencing an issue with high CLS (Content Layout Shift) using Bootstrap (4.5) grid for a two-column layout with column order change.

CLS is a crucial Core Web Vital metric that Google monitors to ensure webpage elements do not shift during loading, potentially impacting SEO rankings.

My layout features two columns on higher resolutions - main content on the right and sidebar on the left. However, on smaller screens, the sidebar content is pushed down below the main content.

<div class="container-fluid">
    <div class="row">
        <div class="col-lg-8 order-lg-2">
        </div>
        <div class="col-lg-4 order-lg-1">
        </div> 
    </div> 
</div>

The issue arises when, upon page render on desktops, the main content momentarily appears on the left side before shifting to its correct position on the right. This shift is subtle on simple pages but becomes noticeable with more complex layouts or external resources.

For reference, here's an example page I've prepared. To evaluate CLS, I use Chrome Lighthouse, which indicates a value of 0.326 for the shifting columns. Results may vary depending on rendering resources, but Google Page Insight typically offers similar findings:

https://i.sstatic.net/OowJx.png

Is there a way to prevent this shift during page load?

css bootstrap-4 flexbox lighthouse pagespeed-insights

Answer 1

Answer №1

It appears that the issue is more closely linked to Chrome than either flexbox or bootstrap. Upon closer examination, it seems that the root cause lies in premature rendering. Specifically, Chrome's parser initiates rendering:

after analyzing 65536 bytes of data,
upon encountering a <script> tag after reading 50 "tokens" (which are essentially HTML tags).

The provided example illustrates the first scenario (though my actual website encounters CLS due to the second scenario). Both situations have associated "bugs" reported: 1130290 and 1041006.

Therefore, the solution hinges on resolving these "bugs". In the interim, depending on the specific cause, you may consider limiting file sizes or removing <script> tags.

Answer 2

It appears that the issue is more closely linked to Chrome than either flexbox or bootstrap. Upon closer examination, it seems that the root cause lies in premature rendering. Specifically, Chrome's parser initiates rendering:

after analyzing 65536 bytes of data,
upon encountering a <script> tag after reading 50 "tokens" (which are essentially HTML tags).

The provided example illustrates the first scenario (though my actual website encounters CLS due to the second scenario). Both situations have associated "bugs" reported: 1130290 and 1041006.

Therefore, the solution hinges on resolving these "bugs". In the interim, depending on the specific cause, you may consider limiting file sizes or removing <script> tags.

Answer 3

Answer №2

Insightful Answer

Simplify the HTML structure to resolve the issue effortlessly.

In-Depth Explanation

Upon investigation, while I may not have a definitive answer, I have formulated a feasible solution and provided some rationale behind it. I am open to further insights from others.

The Epiphany

During an analysis of the page load process, I observed that there were two separate tasks for parsing the HTML document.

One task handled lines 1-770, while the other focused on lines 771 onwards.

This caused the initial rendering of the first 770 lines followed by a layout recalculation during the second parsing task, due to the rearranged order that placed the .col-lg-4 column in the later part of the HTML.

This behavior is not typically noticeable on a "regular" page since rendering in DOM sequence usually results in correct layouts, with the additional parsing pass contributing to finer details.

It seemed consistent where the page cut off, prompting me to eliminate line breaks and whitespace. My hypothesis was that the algorithm determining the split points in the HTML factored in line numbers.

By reducing the effective lines to around 15, my aim was to force the algorithm to parse the HTML within a single pass.

While it still utilized two passes, the final one consisted only of processing the closing </html> tag, which proved inconsequential. This allowed for accurate layout calculations when combining the parsed HTML with the CSSOM.

Although somewhat unconventional, this workaround should suffice up to a certain depth of page complexity.

Note: Doubling the DOM node count rendered this workaround ineffective. Similarly, altering the content length of list items without changing the structure had no impact. Therefore, the stopping point of the HTML parser seems to be influenced by a combination of DOM element count and line numbering.

A Potential Remedy

Consider reverting to traditional layout models involving float:left and float:right, as opposed to utilizing flexbox. The issue at hand appears to stem from the intricate design of the webpage (high number of DOM nodes) combined with the use of flexbox.

Given that flexbox tends to be slower than older layout methods and may require multiple passes (unlike the single pass nature of older models), making this adjustment could likely resolve the persisting problem.

Further insight on multiple layout passes in specific scenarios

Answer 4