Mobile app version of vmapp.org
Login or Join
RJPawlick198

: Prioritise Visible Content - Google PageSpeed Insights Wondering if anyone can help me. I'm having issues with prioritizing visible content (PVC). I've read all the Google documentation and understand

@RJPawlick198

Posted in: #GooglePagespeed #PageSpeed #Performance #Seo

Wondering if anyone can help me. I'm having issues with prioritizing visible content (PVC).

I've read all the Google documentation and understand the above-the-fold content is the top 500px but can't understand what Google detects outside or inside of these 500px to trigger it. I have tried everything I can think of to find a solution.

I am able to make pages and get the PVC warning when the whole page is above the fold, pages that have no sidebars, pages with no images or small images, pages using CSS to load the images, pages with no external files, no js, etc etc.

I am also able to make pages with many images and background images above the fold that avoid it.

I cannot seem to find any consistent pattern or solution that sheds light on how Google decides what triggers a PVC warning.

For example a page that uses no external files at all, no fonts, above the fold has:

Header of around 150px height with a single small image
Nav bar
No hero image / big image
Div containing no sidebar, just the h1 and h2 tags with some key text

And below the fold has some images and text.

How is this page getting flagged as not prioritising visible content?

Also I can make a page prioritising the above the fold content and be happy with it as a template, save it as a new file name and make minor changes to the text / images with the core code the exact same and it will be fine on one and not the other.

It is the only thing coming up time and time again on page speed insights - so my pages are plagued with tones of speed issues that may be causing it.

Here is the error for anyone wondering:


Prioritize visible content
Your page requires additional network round
trips to render the above-the-fold content. For best performance,
reduce the amount of HTML needed to render above-the-fold content. The
entire HTML response was not sufficient to render the above-the-fold
content. This usually indicates that additional resources, loaded
after HTML parsing, were required to render above-the-fold content.
Prioritize visible content that is needed for rendering above-the-fold
by including it directly in the HTML response. None of the final
above-the-fold content could be rendered even with the full HTML
response.

10.02% popularity Vote Up Vote Down


Login to follow query

More posts by @RJPawlick198

2 Comments

Sorted by latest first Latest Oldest Best

 

@Jessie594

Before the browser can render the page, it needs to construct the DOM and CSSOM trees. As a result, we need to ensure that we deliver both the HTML and CSS to the browser as quickly as possible.

The final output of this entire process is the Document Object Model (DOM) of our simple page, which the browser uses for all further processing of the page.

Every time the browser processes HTML markup, it goes through all of the steps following: convert bytes to characters, identify tokens, convert tokens to nodes, and build the DOM tree. This entire process can take some time, especially if we have a large amount of HTML to process.

The CSSOM and DOM trees are combined into a render tree, which is then used to compute the layout of each visible element and serves as an input to the paint process that renders the pixels to screen. Optimizing each of these steps is critical to achieving optimal rendering performance.

The render tree construction shows that the critical rendering path requires both the DOM and the CSSOM to construct the render tree. This creates an important performance implication: both HTML and CSS are render blocking resources. The HTML is obvious, since without the DOM we would not have anything to render, but the CSS requirement may be less obvious.

By default, CSS is treated as a render blocking resource, which means that the browser won't render any processed content until the CSSOM is constructed. Get it to the client as soon and as quickly as possible to optimize the time to first render.

JavaScript allows us to modify just about every aspect of the page: content, styling, and its response to user interaction. However, JavaScript can also block DOM construction and delay when the page is rendered. Executing our inline script blocks DOM construction, which also delays the initial render.

Another property of introducing scripts into webpage is that they can read and modify not just the DOM, but also the CSSOM properties. It may change the display of all or some properties of styles. In this way the browser delays script execution and DOM construction until it has finished downloading and constructing the CSSOM.

By default, JavaScript execution is "parser blocking": when the browser encounters a script in the document it must pause DOM construction, hand over control to the JavaScript runtime, and let the script execute before proceeding with DOM construction. Because the browser does not know what the script is planning to do on the page, it assumes the worst case scenario and blocks the parser. Inline scripts are always parser blocking unless you write additional code to defer their execution.

To deliver optimal performance, make your JavaScript async and eliminate any unnecessary JavaScript from the critical rendering path.

To deliver the fastest possible time to first render, we need to minimize three variables:

The number of critical resources.
The critical path length.
The number of critical bytes.

A critical resource is a resource that could block initial rendering of the page. The fewer of these resources, the less work for the browser, the CPU, and other resources.

Similarly, the critical path length is a function of the dependency graph between the critical resources and their bytesize: some resource downloads can only be initiated after a previous resource has been processed, and the larger the resource the more roundtrips it takes to download.

Finally, the fewer critical bytes the browser has to download, the faster it can process content and render it visible on the screen. To reduce the number of bytes, we can reduce the number of resources (eliminate them or make them non-critical) and ensure that we minimize the transfer size by compressing and optimizing each resource.

The general sequence of steps to optimize the critical rendering path is:

Analyze and characterize your critical path: number of resources, bytes, length.
Minimize number of critical resources: eliminate them, defer their download, mark them as async, and so on.

Optimize the number of critical bytes to reduce the download time (number of roundtrips).
Optimize the order in which the remaining critical resources are loaded: download all critical assets as early as possible to shorten the critical path length.

Summary - approximate chain of dependence of creating visible content: Visible conten => DOM => critical resources (eg. css, javascript).

Possible solution: applying styles within an element head, but without embedding them in the code HTML and using asynchronous as async / deferred downloads for all scripts. All this is applied in AMP - Accelerated Mobile Pages.

Source: Critical Rendering Path of Google Web Fundamentals and Optimizing the critical rendering path of Google Patners Help.

10% popularity Vote Up Vote Down


 

@YK1175434

This warning is likely the result of css or javascript at the bottom of the page or below the above the fold content. If something in those files is needed to render your page's appearance, then the entire page loads, the css file at the bottom of the page loads, and then the above the fold content is displayed.

This is too slow. You need to put render blocking css and js above your above the fold content so that is loads before the rest of your page. This will allow your above the fold content to be displayed before .js and css at the bottom of your page is loaded. It will make your page much faster.

10% popularity Vote Up Vote Down


Back to top | Use Dark Theme