×

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 Rigor’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.

pic1

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 Rigor’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.
pic2

If you’re unfamiliar with waterfall charts, you can review Rigor’s blog post on how to read a waterfall chart.

The waterfall chart lists the elements requested and received by the browser in chronological order. At the bottom, we see the following summary statistics:
pic3

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 Rigor’s Page Performance tool, which indicates that the page rendered 5.7 seconds prior to fully loading.
pic4

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.

  1. 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
    • the browser was executing JavaScript.

    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?

There are two main ways you can render your page’s visual content quicker:

  1. Structure your HTML so that critical, above-the-fold content loads first, and
  2. 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:

  1. 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.
  2. Stop parsing the HTML in the event it encounters an external resource that must be loaded (CSS, JavaScript, images, etc.) to download the external resource.
  3. Parse the acquired resource (if necessary). If the resource is a CSS file, it must build the CSS Object Model (CSSOM), a structural representation of CSS that the browser understands, and if the resource is a JavaScript file, it must execute its contents.
  4. 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.
pic5

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.

pic6

You can verify this via Rigor’s Page Performance monitoring tool, which confirms the render occurred 4.6 seconds before the page fully loaded.
pic7

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.

pic8

We will now discuss ways you can implement similar page-loading behavior on your page by examining changes you can make to your HTML, CSS, and JavaScript.

Restructure HTML

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.

Optimize CSS

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.

Please refer to Eliminating Render-Blocking JavaScript and CSS In Above-the-Fold Content for additional tips on handling render-blocking CSS.

Optimize JavaScript

Probably the biggest improvement you can make in terms of optimizing your page speeds with regards to JavaScript is to delay (either by deferring a script or marking it as asynchronous) its loading. This requires careful consideration, especially if any of these resources are used in your primary, above-the-fold content, but if you are using external widgets, such as those for social media, libraries (jQuery, React, etc.), and so on, you can reduce the loading time of your page quite a bit. These are things that are, generally speaking, secondary to the actual content of your page, so this is a good place to delay scripts.

 

As an example, examining the HTML file for the Wired homepage (shown above) reveals that the second file request, which is to a JavaScript file, includes the parameter indicating it can be treated as asynchronous.

<script async=“”

src=http://www.wired.com/wp-content/themes/Phoenix/assets/js/vendor/picturefill.min.js></script>

Please refer to Eliminating Render-Blocking JavaScript and CSS In Above-the-Fold Content  for additional tips on handling render-blocking JavaScript.

Reducing the Amount of Data Used by Page Resources

Minify 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.

Enable Compression

Because all modern browsers support (and will automatically request) GZIP compression, a generic compressor that can be applied to any stream of bytes, for HTTP requests, you should enable compression to reduce file transfer sizes by up to 90%. GZIP works best on text-based assets such as CSS, HTML, and JavaScript.

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.

pic9

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.”

Summary

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.

Suggested Blog Posts

Mobile Banking a Top Priority for Financials

As mobile devices continue to play a more prominent role in our 21st century society, their usefulness has spread beyond the casual activities of technological enthusiasts. According to research conducted by FUNDtech, a rapidly growing number of ba...

Read More

The Perception Gap for Poor Web Performance

E-commerce is a growing source of revenue for many companies and businesses, as it continues to capture market-share from brick-and-mortar stores over recent years. However, many businesses are not prepared for this growth of online business becau...

Read More

Measuring Cross-Browser Performance

In recent years, client-side browsers have been more involved with processing code before it reaches the user's desktop, shifting away from a reliance on servers handling the bulk of this burden. Websites and applications now rely more on a user's br...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design for an...

Read More