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.
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, improving the perception of performance.
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 critical and 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, it’s key to 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.
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. Ensuring that your CSS is optimized and basic layout styling exists on your site will ensure the content shows early, and improve 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 wouldn’t be able to see any words, not leading to an ideal experience for them.
Balancing Performance with Experience
In short, it’s always important for web developers to provide the fastest page, while not starling 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.
By understanding the technical reasons behind these delayed appearances, developers can make better decisions about how they want to load their content - and improve the experience for their users.