Users are aware of how long they have to wait before they see a loaded website, but even a large page that utilizes a lot of resources can be seen as fast and responsive if you give priority to loading your most important content first.
In this article, we will analyze several live sites using Splunk’s monitoring tools. Then, using the information gained, we will cover techniques you can use to prioritize the rendering of your visual content to give your users the best possible experience.
A Real World Example
One popular website is the New York Times homepage.
There are many elements on this page, including a large header, multiple columns, and assorted widgets for things like advertisements. Many of these are external resources that must be requested when you navigate to the webpage. However, if you navigate to the page in your browser, you’ll see visual content displayed prior to the website loading completely.
Using Splunk’s waterfall chart feature, we can see what is happening under-the-hood as the page loads. We see:
what files were requested
the order in which a file was requested and received
the size of a file requested
how long it took to load.
This will give us an idea of how different elements interact with each other to determine the final page load time.
The waterfall chart lists the elements requested and received by the browser in chronological order. At the bottom, we see the following summary statistics:
Loading this web page required 290 requests that 28.71 seconds elapsed before the end of the final request. However, the user will typically see some rendering of this page long before the full amount of time elapsed, allowing for the rest of the time to be used to load the final resources while the user is reviewing the content that already has been displayed. We can confirm this using Splunk's Page Performance tool, which indicates that the page rendered 5.7 seconds prior to fully loading.
At this point, you are probably wondering where the delays are occurring, so here’s where the waterfall chart can help you decide what actions you need to take to improve your page load times.
Identify Problematic HTTP Responses: Using the third column, which displays the HTTP response code for that particular resource, you can see if there were any resources that received a non-standard response. 4XX and 5XX responses, which the chart highlights in red, are most problematic, but other response codes might indicate areas you could optimize – for example, instead of allowing the browser to follow a redirection (indicated by a 3XX status code), you could provide the updated resource address to minimize the amount of time it takes to fetch the resource.
Identify Resources that Require Long Render Times: In the fifth column of the waterfall chart, you can see a series of bars that is a timeline of what happened as the page loaded. Generally, as you look down the list of resources requested, the bars get longer, indicating that the browser required more time to fully render the resource. You should analyze any bar that is longer than usual, and depending on what the cause of the lengthy render time is, take the appropriate steps to optimize that resource.
For example, notice that, even for the first few resources, quite a bit of the render time was taken up by blocking. These are areas where you might consider optimizing your render-blocking content to reduce the amount of time the browser spends on these resources.
Identify Large Gaps Between Requests: The fifth column of the waterfall chart displays when the browser handled the request, as compared to the other requests associate with the page (resources loaded first have bars that are toward the left, while resources that come later have bars that are located toward the right). If there is a large gap between two consecutive requests, this indicates a time period where no requests happened. Generally, this is due one of two reasons:
the browser was parsing a resource
Either way, this is an area you would want to identify and attempt to reduce or eliminate.
Now that you’ve identified areas you can optimize, what are your options for improving your page’s rendering time?
Structure your HTML so that critical, above-the-fold content loads first, and
Reduce the amount of data used by the resources on your page.
Loading Critical, Above-the-Fold Content First
When the browser renders your page for your user to view, it must:
Obtain and parse the HTML file to build the Document Object Model (DOM) tree, a structural representation of HTML that the browser understands. The browser parses the file line by line, from top to bottom.
Continue parsing the HTML until it encounters another external resource that must be handled. This browser continues doing this until the entire HTML document has been parsed and rendered.
Any time the browser has to stop parsing HTML to download, parse, and render an external resource, the user has to wait to see a rendered webpage. To minimize this, you would ideally structure your resources so that those associated with above-the-fold content is handled first, and anything that is not immediately seen is handled later.
Consider the sample site pictured above. Within the above-the-fold content area, there are two elements: the left-hand navigation bar and the right-hand main content window.
To optimize your page load speeds, you’ll want to prioritize the above-the-fold content. Furthermore, the more important portion is the content window, since it contains the information the user is looking for. While not unimportant, the navigation bar generally contains contact information, ads, a search bar, and so on – features of the site that are of secondary importance to a user. As such, you’ll want to break down your prioritization even further and have the content window load prior to the navigation bar.
A Real World Example: Wired
When loading Wired’s site, the above-the-fold visual content is fully rendered, even while the rest of the page (as indicated by the browser) is still downloading, parsing, and rendering other aspects of the page.
You can verify this via Splunk’s Page Performance monitoring tool, which confirms the render occurred 4.6 seconds before the page fully loaded.
When looking at the waterfall chart for the site, we notice that there is a time gap between the first and second resources. Even so, this is not readily apparent to the end user.
Because the browser parses HTML from top to bottom, the content it encounters first will be rendered first. As such, you should place your most important content at or near the top of the file. In this case, you should place the code used to generate the content window above the code that is used to generate the navigation bar, since we want the former to render first. Just by copying and pasting a couple of snippets to move the most important content to the top gains you critical improvements in page load time.
Because CSS is a render-blocking resource, being mindful of how you call and load your CSS will help reduce the amount of time it takes for your page to load. Notice how, in the example using the New York Times homepage, the CSS file is nearly twice as large as the initial HTML file that calls it. Because the HTML will not render until the CSS file has been parsed, this can impact your page load speeds quite a bit (in the case of the New York Times, it took the browser over three times as long to finish work with the CSS file than the HTML file).
As with your HTML, you should prioritize the loading and parsing of the CSS for your primary content that is located above-the-fold.
One of the easiest ways to do this is to extract the CSS relevant to the primary, above-the-fold content and use it inline in your CSS. All other CSS can be placed in external files (preferably as few as possible) that are called, loaded, and parsed at a later time. By doing this, you will parse only the relevant CSS snippets and eliminate the time you would have needed to acquire an external resource.
Reducing the Amount of Data Used by Page Resources
Minification is the process of removing unnecessary data without affecting how the resource is processed by the browser. For text-based files, some things you might change include removing comments, whitespace, or unused code and using shorter variable/function names. For images, video, and other media types, you can remove embedded information such as camera settings, location, and so on. By doing these things, your files are smaller in size and can be obtained and parsed by the browser quicker.
Here are some tools you might consider using to minify your page resources:
The (rather limited) list of tools above will get you started towards minifying your resources, but you should still review your code for things like long variable/function names, suboptimal code blocks, and so on.
While browsers automatically support and request GZIP compression, you must ensure that your web server is properly configured to serve the compressed resource when requested. How this is done depends on your particular configuration, but the HTML5 Boilerplate project contains sample files for popular servers. These files contain detailed comments for all flags and settings, so you can identify information that is relevant to you by identifying the server you use, navigating to the GZIP section, and confirming that your server configuration is appropriate.
One way of seeing the effect of GZIP is via Google Chrome’s DevTools. By inspecting the “Size/Content” column under the Network panel, you can see that GZIP saved 131.2 KB during the transfer process.
Caveat: In instances where the asset you’re compressing is very small, GZIP can increase the size of the asset. This is usually because the overhead of the GZIP dictionary is higher than the savings garnered by compression or because the resource is already well-compressed. To avoid this problem, some servers allow you to specify a “minimum file size threshold.”
By identifying and delivering the most important content to your users first, you can deliver a fast, responsive experience while being able to include lots of elements on your site. Using techniques such as restructuring your HTML or optimizing your render-blocking external resources via minification or compression, you can shave off time it takes to render your site.
Get started with a free trial of Splunk Observability Cloud today.
Splunk, Splunk>, Turn Data Into Doing, and Data-to-Everything are trademarks or registered trademarks of Splunk Inc. in the United States and other countries. All other brand names, product names, or trademarks belong to their respective owners.