Optimize Page Loading by Eliminating Performance Bottlenecks

Website and web-app users expect a captivating and efficient experience. No matter how good your content, you’ve got to keep visitors and users engaged with fast rendering performance, or they’ll switch to another webpage and perhaps never return. This is the primary reason that it’s vitally important to monitor and optimize key webpage performance metrics.

Network metrics have a long history, while webpage-rendering metrics remain unfamiliar to many people. Such metrics include start render, speed index, time to first paint, time to first interactive, time to interactive, and time to consistently interactive. While there are many metrics, the ones that matter most to your team depend on your industry or business goals. Here in this article, we’ll touch on the page-loading metrics that boost performance—foremost from the user perspective. We’ll also explain how to optimize the critical rendering path and point you in the right direction for testing. 

Dissecting the page-load process

Total page load time is a popular metric for webpage performance measurement and analysis. This is the average elapsed time necessary to load a page —including all of its supporting assets. But the user doesn’t care about that metric very much. Typically, the most important thing for user experience is responsiveness. From that perspective, other metrics are much more important, such as the time necessary to render the primary content, or how soon some page elements become interactive.

Some general usability metrics—originally defined by Nielsen—indicate that after only one second of unresponsiveness, the human brain typically induces a context switch. That is the point at which a user begins to switch focus and think about the alternatives to waiting for a page to load. Nielsen reports what happens typically in a very short timeframe:

• < 100 milliseconds — Perception of instantaneous response
• < 300 milliseconds — Perception of a slight delay
• < 1,000 milliseconds — Fully perceptible delay, focus fades to next best alternative
• > 1 seconds — Change of focus is fully considered
• > 10 seconds — User abandons original task for something else

To some, loading a complex webpage within one second may seem like a daunting and task, since it’s the browser has to load HTML, Javascript, and CSS—among other elements.

It’s important to realize that it’s unnecessary to load everything on the page within this short interval of time. Modern web browsers accommodate asynchronous asset loading, and it’s also possible to load the essential elements only—those that appear above the fold at the top of the entire webpage. To accomplish this, it’s essential to capture the minimum initial user requirements, and then configure the page load such that it gives top priority to the elements that correspond to those basic requirements.

Browser rendering sequence

To render most content, a browser will proceed through these steps:

1. Acquire the Document Object Model (DOM)
2. Acquire the CSS object model (CSSOM)
3. Combine the DOM and CSSOM trees into the render tree.
4. The render tree contains only those nodes necessary to render the page.
5. Next, the layout step computes the exact position and size of each object.
6. The last step is painting, which ingests the final render tree and renders the pixels to the screen.

Focus on metrics that are important to your website visitors

The onLoad is a browser event that users barely notice, since it triggers after all web page resources have been loaded, including the potentially large number of resources below the fold. As such, the onLoad event isn’t suitable to measure website speed, since it doesn’t represent the user perception of performance.

To measure performance from the vantage of your users, it makes much more sense to measure metrics such as time to first paint (TTFP) and the time to DOM interactive (TTDI).  TTFP is a measure of the elapsed time from the moment a user enters a URL in the address bar to the point at which the browser paints the first pixels onto the page. Very simply, this is the amount of time that a typical user will wait until some content replaces the empty browser screen. While important, TTFP is insufficient as you seek to improve user experience, since it only indicates the point at which the first pixels are visible. The point at which the page becomes interactive will occur later—sometimes way too much later! 

Another page load event is TTDI, known otherwise as PerformanceTiming.domInteractive—or simply domInteractive. This is a measurement of the time from the moment the user enters a URL into the address bar up to the point at which the page is ready for at least one user interaction. It’s very important to realize that this event typically happens much earlier than onLoad. TTDI usually occurs well before the entire page loads completely. It’s easy enough to design a webpage on which a user can click links, enter text, and press some buttons while page content is still loading. 

These and a few other metrics are reliable indicators of website speed measurement from the user perspective, but the next question is: How do you proceed to optimize the loading and rendering processes so that you reduce the value for your webpage metrics?

Critical Rendering Path

Displaying web pages fast enough to meet user expectations is remains a stiff challenge for many development teams. Techniques such as image optimization, low-latency web hosting, content caching can contribute to a significant reduction in page load time, but often this isn’t enough. To seriously tackle page-load performance, it’s necessary to focus on the critical rendering path. Specifically, it’s vital to get the webpage instantly usable above the fold—and then manage the remainder of the page load process.

How it works

The critical rendering path (CRP) is the sequence of actions that the browser performs to receive HTML, CSS, and JavaScript, together with the techniques for rendering the initial webpage view. The rendering includes building the object model, arranging the layout, painting the layout, and enabling the initial interactions with JavaScript.

Configuring the critical rendering path involves:

1. Analyzing the website and determining which critical resources are necessary for the initial view.
2. Defer the loading of any elements that are unnecessary for above-the-fold content.
3. Compress the resources to reduce overall page size.
4. If possible, stuff all optimized HTML/CSS for the initial page view into the first data packet.

Typically, the content in the first data packet can download and render in much less than one second—though some environments may be slower because of various security measures such as proxies and firewalls. This data and content should be optimized for above-the-fold presentation. The deferred elements can continue downloading immediately and render before the user moves to scroll down the webpage.

Give your CRP a haircut

First, take an inventory of only those assets that are necessary for supporting content that is above-the-fold. Then, begin optimizing the CRP:

1. Reduce the number of resources on the CRP — Critical resources are those that may inhibit or block initial page rendering-such as excessive or bloated HTML/CSS. By reducing the critical resources that are queued up to load onto a page, the browser can work faster to display content. You can minimize a critical resource by deferring its download until the above-the-fold content is ready, configuring it to load asynchronously, or eliminating it altogether.
2. Reduce the number of bytes — Minimize the amount of bytes that are on the CRP by shrinking each resource—wherever feasible. If you’re ready to tackle it, you can optimize these resources further by employing HTML and CSS obfuscation.
3. Reduce the critical path length — The length of the CRP is the total number of round trips involving the browser and the computer that is hosting the assets. A round trip includes the browser request, the server response, and retrieval of the assets. To shorten the CRP by eliminating some round trips, you must plan to minimize resources so that you can maximize the number of resource retrievals on each round trip.

Examples of CRP optimization

Images — If a webpage is to contain 15 images in total, it’s likely that only a some of these will appear above the fold. By prioritizing those images in the first roundtrip, you can significantly improve performance. By deferring the other images until the initial rendering is complete, user experience will significantly improve because the page load appears much faster.

JavaScript — If a webpage depends on six JS files, but only one JS file is critical for interactivity above the fold, then arrange for the critical file to load first and defer the other JS files. One simple example of JavaScript optimization is that you can defer resources such as analytics and social app buttons—since these are not typically a priority above-the-fold.