TL;DR: render delay
- Render delay is the gap between the browser receiving the HTML and the user seeing the finished page. It is dominated by JavaScript execution, not by network transit, on almost every modern site.
- The biggest culprit is synchronous third-party scripts loaded in the head: tag manager, analytics, and chat widgets that block the render tree from committing.
- Web vitals metrics (LCP, FID, INP) measure the observable symptoms, but they do not tell you which specific script is stalling your page. In-session monitoring of script execution timing does.
If you’ve ever visited any modern webpage, you’ll notice that sometimes things on screen (like images, input elements, etc.) will load before other parts of the site. Webpages will often load in stages, with some things only appearing after an initial delay. This staggering can actually be intentional to improve performance of the site, but could also just be a side effect of how your browser is processing the page.
If the slow part is the download itself, check the unit before comparing numbers. A browser showing MB/s and an internet plan sold in Mbps are using different units; Mbps, Mb/s, and MB/s need an 8-to-1 conversion.
Lazy loading
Lazy loading is a technique used by web developers to delay loading non-important things on the page. Things like images, videos, and embedded content usually loads last, or until they’re actually needed by the page. Instead of eagerly loading everything all at once (which can clog your browser with a bunch of requests), your browser will wait to load the content off-screen until the user scrolls near it. By not loading all of this content, every single time, the initial page load is much faster and feels lighter.
For example, this blog post might load our top banner and author icon first, but delay loading the images near the footer of the site until you scroll to it. This speeds up the initial load, since only the first image is loading.
From the user experience side of things, lazy loading is clearly beneficial: you see the important things quicker, and your bandwidth isn’t wasted on images and videos that the user may never see in the first place. This improves the page’s First Contentful Paint, which is a browser metric used to time how quickly the first item appears on screen.
There can be negative implementations of lazy loading, and ultimately depends on the developer of the page to ensure they use it properly. For example, loading anything above the fold (which is any content visible without scrolling down the page) shouldn’t be lazy loaded. Another concern is layout shifting, which is when an image’s space isn’t reserved on the page and loads later, pushing all of the content down.
Client-side rendering and hydration
Modern web apps are primarily JavaScript these days, which means that content is often rendered and then displayed to the user. In client-side rendering (CSR) frameworks like React, Angular, and Vue, the server will send a very barebones HTML page, and then wait until the browser generates the content. This means on the first load of a page, you might just see a blank screen or a loading spinner while the browser is downloading and generating the content.
This implementation can often lead to a negative perception of the performance of your site, as users might think nothing is loading or it’s taking too long to load in the first place. The First Contentful Paint metric we talked about earlier might be significantly pushed back in a pure CSR situation, because nothing meaningful is showing up on the page until far, far later.
Solving this with server-side rendering
To mitigate against some of the waiting delays of client-side rendering, many web frameworks will use Server-Side Rendering (SSR). This means that a server will send a fully developed web page to your browser (so you’ll immediately see content), and then hydrate it later on with more interactive elements.
Hydration still requires generating those client-side browser content, but it just means your users aren’t staring at a blank screen in the meantime. In turn, it improves perceived performance of your page and leads to less thinking about “why is this page so slow?”.
With that being said, SSR and hydration can still introduce issues to a site if not implemented properly. The issue of content flickering is when the server doesn’t know the user or what context they already have (like, if a user is logged in already or not), and as a result will give them a generic version of the site. Once the site is hydrated and realizes that the user is logged in, it might replace parts of the UI with personalized or updated content. While not as bad as a completely blank page, these mid-stream content changes can be distracting and momentarily confuse the user.
From a user experience standpoint, the goal is to minimize the delay before users see useful content. If you’re using CSR, keep your JavaScript lean and include a well-designed loading indicator or skeleton so your users know there is content on the way. Even better, using SSR for the initial view makes sure users see something first, and get their content second.
See it in your own site
Render delay is often blamed on network latency, but the real cause on modern sites is unaudited third-party JavaScript blocking the render path. cside shows exactly which scripts are stalling your page in every real user session. Free tier available.
Resources blocking renders
Not all delays are due to scripts, and instead can also be from how your browser handles critical resources like CSS and fonts. Browsers don’t know to inherently prioritize these, or might not realize the content is styled until later, leading to content flashing on your page with the wrong font or style.
CSS is the most classic of the render blocking issues. Usually, browsers will delay rendering the page’s content until the CSS is downloaded and processed, but if your CSS file is too large or too complex, any elements that are dependent on that CSS file will appear late until loaded. Keeping your CSS optimized and basic layout styling in place makes the content show earlier and improves the user’s perceived load time.
A site’s font can also delay the appearance of text, but often in more subtle ways. When a site uses a custom font (via @font-face, or something like Google Fonts), browsers will handle them carefully to ensure a fallback font doesn’t appear. Browsers implemented “the flash of invisible text”, which means text is hidden until the font file is loaded. Text is essentially there, on the page, you just can’t see it. And if your font takes too long to load, the user won’t see any words at all.
Balancing performance with experience
Web developers should aim to provide the fastest possible page without startling the user with unstyled content, missing text, or long load times. Every delayed element on a page should have a good reason for being delayed, and the delay should be managed in the UI through spinners and placeholders.
