Skip to main content

Using Google Pagespeed Insights to Optimize Web Experience

A Playbook for how to use PageSpeed as part of a larger approach for improving web performance and user experience.


The purpose of this e-Book is to help readers understand Google PageSpeed Insights and how to use PageSpeed as part of a larger approach for improving web performance and user experience. We’ll cover:

  • What is PageSpeed Insights?
  • How to review PageSpeed results as part of your web performance strategy
  • How to address 10 performance optimizations that can improve your PageSpeed score and help you deliver a better user experience overall


Chapter 1: What is PageSpeed Insights?

PageSpeed Insights is a free web performance tool from Google that measures a site’s front-end performance on desktop and mobile against 15 rules for speed and usability. PageSpeed Insights assigns a graded score to a site and also offers some high-level recommendations about how a developer or site owner might improve the site to earn a higher score.

If you haven’t used PageSpeed Insights before, now is a great time to try it out. Here’s how to get started:

1. Navigate to

2. Enter any website URL into the field with the placeholder text “Enter a web page URL”

3. Hit the “Analyze” button

4. Review scores and results on both Mobile and Desktop

Reviewing PageSpeed Results

When you review your PageSpeed Insights results, you’ll see a few things:

  • You can easily tab between results for Mobile and Desktop
  • For both Mobile and Desktop, you receive scores for both Speed and User Experience; scores are graded out of 100 where 85 and above are considered “good”
  • Green check marks highlight the rules that the site passed with no significant errors found
  • Yellow exclamation marks highlight failed rules that Google identifies as having a moderate impact on performance, indicating that developers should consider fixing these errors
  • Red exclamation marks highlight failed rules that Google identifies as having a considerable impact on performance, indicating that developers should fix these errors
  • Click “Show Details” to learn more about any passed or failed rules
  • Results pages for both Mobile and Desktop show contextual screenshots of what the page looked like at the time of the test

Results from PageSpeed Insights are pretty intuitive and straightforward. Google also provides some great resources to help you understand your results. For the purposes of this e-Book, we’re going to focus on the 10 rules and optimizations that affect the Speed category in the PageSpeed Results.

Why Does PageSpeed Score Matter?

Surprisingly, PageSpeed Score is not a great indicator of speed. If you care about speed, metrics for render time and load time from proactive monitoring tools may be more helpful measurements.

PageSpeed Score has become popular because of SEO and interest in how it affects Google search results. Google has announced that it uses performance as a factor in search rankings. Additionally, PageSpeed can offer some valuable recommendations that your team can incorporate to improve speed and UX.

Ultimately, you’ll need to determine whether it’s worth it to implement a specific recommendation from PageSpeed. Is it worth the cost for your team? Are there any potential gains other than improving the PageSpeed Score?

In the next section of this eBook we’ll walk through all of the rules and recommendations from PageSpeed Insights. We’ll look at what they mean, why they’re important, and how to implement the recommendation.


Chapter 2: Minify Resources

What is Minification?

Minification is the process of removing unnecessary characters from source code without changing the functionality of that code.

PageSpeed Insights recommendations you should minify the following types of resources:

  • HTML
  • CSS
  • JavaScript

Note: It’s also possible to minify SVG resources, although unminified SVGs may not directly affect your PageSpeed score.

Why Minification Matters

When you write HTML, CSS, JavaScript or other text-based code, you typically include characters and spaces for legibility. White spaces and line breaks help separate chunks of code into similar, related sections. But, those same spaces and characters that make code easy to read in text editors create unneeded bloat in page size for the browser. Unlike a human being with eyes, the browser doesn’t need or benefit from extra whitespace or characters in the code.

When you minify a resource, you’re simply removing those spaces and characters in the file. The code becomes one long, continuous string. The file containing the code becomes smaller, and the browser can load that code faster.

But, it doesn’t stop there. Beyond removing whitespace and characters, you can also:

  • Remove comments and annotations from HTML and CSS
  • Consolidate CSS declarations
  • Shorten JavaScript variable names
  • Remove any unused code

How Minification Works

A Minification Example

To help you understand how minification is used, let’s look at a bit of HTML:

<!–- This is the content that shows in the browser tab -–>

<!–- This is a comment. -–>

Hello, World!



After minification, your file would contain the following:


Hello, World!

Size-wise, the original resource contains 190 bytes of data, whereas the minified resource contains 85 bytes of data. Minification reduces the file size by over 50%.

To help you minify resources, Google recommends the following free tools:

Each of these tools can be used in your build process. You can keep an unminified copy of the resource for your team to work. Then, make minified copies of your files to push to production.

Next Steps

When minifying your files, your primary goal is to remove redundant or unnecessary data.

  • Comments: While comments are useful for a developer, they are unnecessary to the browser. Remove all comments.
  • Whitespace (spaces, tabs, and line breaks): Whitespace is also useful to a developer, but they are a convenience that the browser does not need. Remove all unnecessary spaces, tabs, and line breaks.
  • JavaScript and CSS: To minify you can do additional optimizations such as shortening variable names or using CSS shortcodes. Modern minifiers, such as Google’s Closure compiler, can do this for you automatically.

Granted, the minified resource is not very readable, but one way to work around this is to keep both versions of the resource. The larger, more human-readable form of the file is the version developers work with, while the minified version is the one deployed to the server.


Chapter 3: Enable Compression

What is HTTP Compression?

When PageSpeed Insights recommends that you “enable compression” they’re referring to HTTP compression, specifically using the gzip compression scheme.

Compression is the process of encoding information using fewer bits. GZIP is a generic compressor that can be applied to any stream of byte and it’s supported by most modern browsers. Developers must only ensure that the server is configured correctly to serve the compressed resource when it’s requested by the client.

Why Enabling Compression Matters

Enabling GZIP compression can reduce response size by up to 90%. The only trick is that you must ensure that the server is properly configured to serve the compressed resource when the client requests it.

GZIP compression works best for resources that are not natively compressed. These types of resources are typically text-based files, such as:

  • HTML
  • CSS
  • JavaScript
  • SVG
  • XML
  • JSON
  • HTML Components (HTC)
  • Plain Text files, like README or LICENSE files
  • Robots.txt

That said – GZIP isn’t exclusively helpful for text-based resources. There are some exceptions of types of files that are not natively compressed and also not text-based.

For example, many web fonts like TTF, EOT, WOFF version 1 files, as well as ICO files used with Favicons, are all examples of files that are not natively compressed. Be sure to configure your web server to serve these non-text, yet not-natively-compressed files with HTTP compression.

How HTTP Compression Works

The way HTTP compression works is that you compress the document on the server side so that it’s smaller, send it across the wire, and then count on the client to unzip that file. This method is faster than transmitting the entire file because the network is fairly slow. This optimization essentially leverages the fact that the CPU and your server or device is faster than the network itself.

Despite being a surprisingly simple feature of HTTP, you should make some considerations when using compression. Be sure to:

  • Compress only compressible content
  • Select the correct compression scheme for your visitors
  • Configure the web server properly so compressed content is sent to capable clients

Remember: running GZIP on files that are already compressed won’t yield improvements. An optimized image or video file won’t become smaller with compression, so there’s no benefit to compressing those types of resources.

Also note: if applicable, you should minify your text-based files before compressing them. This will ensure that you generate the leanest possible file size.

Next Steps


First, enable compression on your web server. Then, test to confirm that compression was implemented properly.

To learn how to enable compression on your web server, you can read your server’s documentation or start with a boilerplate of sample configuration files. For some servers, enabling compression is available in settings or with an easy update to an .htaccess file.

When enabling compression, consider the following:

  • How is your web server configured to map MIME types to content or file extensions?
  • How is your web server configured to compress content relative to those MIME types or extensions?
  • How are your application’s filenames and extensions structured?
  • How does your application change or override a response’s MIME type?
  • What third party libraries use MIME types?

Make sure that your configuration files are properly implemented across all of your hosts. Then, verify that compression is enabled. In your browser’s dev tools, you can look for the header:

Content-encoding: gzip

There are also a number of free tools available to help you verify that HTTP Compression is enabled properly such as GIDZipTest. Meanwhile checkout our website to learn more.


Chapter 4: Optimize Images

What is Image Optimization?

According to Google, image optimization is compressing an individual image to improve web performance by reducing the number of bytes the browser has to download. The less work there is for your user’s bandwidth, the faster the browser can download and present useful content.

Why Image Optimization Matters

According to the HTTP Archive, images are the dominant form of content on the web today. They account for the largest number of requests when loading a webpage.

Loading faster, especially on mobile devices, is becoming increasingly important, which is why Google Pagespeed Insights finds image optimization a necessity for a better user experience on both desktop and mobile platforms. Google also uses its mobile-friendly algorithm for their search engine ranking. This makes your web app’s performance even more important as the world moves further towards mobile only devices and development.

Snapshot of Google’s easy to use Mobile-Friendly Test.

How Image Optimization Works

There are two primary categorizations of image performance optimizations: lossless optimizations and lossy. The visual differences are negligible and very few humans can tell the difference with the naked eye. However, the size differences are big, significant, and important to the performance of each page of your web site. When you are optimizing images for web performance, remember the goal is to make images smaller so they download to the user’s device faster.

Let’s have a quick look at the basics of each type of image optimization.


As its name reflects, lossless image optimizations are optimizations that make an image smaller in size while preserving the fidelity of the content. In other words, the original and losslessly optimized images are pixel-perfect copies of each other, the file is just smaller. This happens because lossless optimizations remove the cruft inside the image file that has nothing to do with rendering the image. This includes things like timestamps, GPS coordinates, shutter and aperture settings, unused color palette entries, embedded thumbnails, or other meta data. You can see in the image below a hex dump of an unoptimized JPEG image, with contains unnecessarily plain text meta data. Lossless optimization would remove this data:

This data is not needed to present a beautiful image to your web or mobile user, so the data is stripped off of the image and can be removed, giving you a 15 – 20% reduction in the size of each image, on average. If your website is image heavy, that 15% on each image can add up quickly.


Lossy optimizations, by contrast, do actually modify or discard some of the non-critical pixel data contained in an image file to reduce it size. This can lead to significant reductions in size, usually in the range of 70-80% reduction. But how can we discard or change the graphics data in the image and still have an image that looks good? After all, your designer worked hard to create those images!

Because of the way the human eye works, especially when viewing millions of pixels on a backlit screen, there are tricks we can do to create smaller images without anyone noticing. Another optimization is to make sure you are using the correct file format for the image (for example, using JPEG for photographic data instead of PNG). By doing this your web site or web app will load faster, and the difference in the quality of the images will rarely be noticeable. Let’s see an example:

Can you tell the difference between these two images above? The image on the left is 984 KB. The image on the right is 48 KB, a 95% difference in size on the server. Obviously, the image on the right will load much faster on your web or mobile app. Lossy image optimization has a lot of nuance, so see our presentation with tips and guidelines for optimizing images intelligently.

Next Steps

Since images account for most of the downloaded bytes on a web page, image optimization is vital to your web performance. Usually, lossless image optimizers tend to be a no brainer since they don’t impact visual quality. Below you will find the performance tools Splunk uses when detecting unoptimized content and providing optimized versions for our customers to download.


  • Lossless PNG Optimization: pngcrush
  • Lossless JPEG Optimization: jpegtran
  • Lossless SVG Optimization: scour
  • Lossless Animated GIF Optimization: gifsicle


The only true way to see a significant reduction of file size for images is to use lossy optimizations. Applied intelligently, you can see tremendous results with little perceivable change to image quality.


Keep in mind these tools will not necessarily create the smallest possible optimized content. Performance tools often have a trade off between time, CPU, and resource usage, and how small the output file is. Some tools (or options for a tool) may let you squeeze a few more bytes out of a file, but can take exponentially more time to do it.


Chapter 5: Leverage Browser Caching

What is Browser Caching?

Every browser has a cache which is a place to store local copies of resources. When the browser downloads a resource and stores it in the cache we call this HTTP caching, or just simply caching. Caching allows the browser to keep copies of files, such as the logo or a style sheet, and reuse those copies the next time we visit the website.

“Caching” is a general term in computer science for “storing something temporarily to use later because that’s faster than fetching it again.” CPUs, disks, and even Wifi cards all use their own types of caching. For the purposes of this post, when we say “caching” we mean HTTP caching.

Why Caching Matters

Caching is important because retrieving a file from a server can be slow and expensive, depending on the size of the file and the geographical distance between the visitor and the server hosting that file.

As a visitor, caching lets you use an already downloaded copy of a resource, which helps reduce bandwidth consumption, data consumption, and page load times.

As a web developer, caching lets you deliver faster page loads to your visitors while reducing the load on the web server. You should work to decide what elements should be cached and what elements shouldn’t be cached in order to deliver the most efficient and performance experiences to our visitors.

How Caching Works

Example of the Effect of HTTP Caching on Web Performance is a popular website that we often reference for helpful information about general definitions or histories of web performance topics.

Imagine that a visitor has a topic that they want to read about on Wikipedia. The visitor types into the browser’s navigation bar and loads the page, but then that visitor gets distracted and navigates away to work on some other task. Then that visitor goes back to to search for the topic again. When they visit for the second time in the same browser they may see that the page loads much more quickly than it did before.

In the above example we’re looking at two page loads for that happened within a single browser session. The first time we hit the page it took 1.2 seconds to render and 1.3 seconds to load. When we hit the page again it rendered in a snappy 965 ms and only took 979 ms to load.

The page loaded more quickly on the second visit because some of the elements from the page had already been downloaded and were stored in the browser’s cache.

Next Steps

Caching is a fundamental optimization that can significantly improve the performance of a website on subsequent visits. Since caching involves setting HTTP response headers, this optimization is accomplished by properly configuring your web server or CDN.


Web developers or site owners may want to develop a Caching Policy, or a set of guidelines for what and how to cache resources on a site. When considering a caching policy it’s important to consider:

  • How many pages will an average visitor hit during a single session on the site? Are there common elements between these pages that should be cached?
  • How often does a typical visitor come back to the site? Is a typical visitor expected to return to the site several times within a single day or week?

Generally, assets like images, scripts, and stylesheets can be cached heavily, while it might not make sense to cache elements that will be dynamically updated throughout the day.

Specifying a Caching Policy

Once you’ve determined which resources you’d like to cache and for how long you can use the Expires Headers or Cache-Control Headers to update the rules for how visitors can cache resources in their browsers.


Chapter 6: Avoid Landing Page Redirects

What are Landing Page Redirects?

PageSpeed Insights recommends you “Avoid Landing Page Redirects.”  Redirection occurs anytime a visitor attempts to load a page with a given URL but is sent instead to a different address.

Why Landing Page Redirects Matter

There are many reasons why you might consider redirection:

  • The original site has moved, and you want to send the user to where the site is now located
  • You want to track clicks and log pages that refer users to your site/sites to which you refer your users
  • You want to reserve multiple domains
  • You want to secure the information your are sending and receiving, so you switch your users over from using HTTP to HTTPs

However, there may be cases where you have unnecessary redirection on your site:

  • Using device-specific versions of your site; for example, a mobile user navigating to might be redirected to
  • Hyperlinking inconsistently on your site: instead of consistently using URLs with the “www” prefix (such as or URLs without the ”www” prefix (such as, you mix and match the two, leading to unnecessary redirects


As an example, we see that the preferred address to access the online edition of the New York Times is (we received an HTTP response code of 200 when requesting the site). Splunk’s waterfall chart shows that our request took 365 ms to complete.

However, suppose we attempt to load the same site using a slightly different URL: Splunk's waterfall chart indicates that this address has been permanently moved (given that we received an HTTP response code of 301).

Our request for the initial HTML required two steps. The first call was for the resource that we thought was located at This step required 156 ms. We are then redirected to, which took 365 ms. Because of the redirection, our total HTML request, download, and render time took an additional 156 ms for a total of 521 ms. Additionally, notice how, on the waterfall chart, all of the site’s resources further down on the list are pushed to the right, indicating that the browser handled them at a point of time later than it otherwise would have.

How Landing Page Redirects Work

When implementing site redirection, you can do so using one of two implementations:

  • HTTP redirects
  • JavaScript redirects

We will cover optimization strategies for both implementations.

Using HTTP Redirection

HTTP redirection is typically used to send users to device-specific sites, and this is done by setting the user-agent in the HTTP request headers. The response code for this redirection is either 301 (indicating the redirection is permanent, such as moving users from the address prefixed with “www” to the one that isn’t) or 302 (indicating the redirection is temporary), though you should generally use the latter if it is at all possible.


Identify any other uses of URL redirection on your pages. For example, one type of redirect sends users from the “www” version of the URL to the one without (that is, redirects to This is similar to the type of redirect used if you’ve registered multiple domains, and you want to direct all of your traffic to your primary URL.

In all of these instances, you should identify which URL garners the most traffic and then configure an HTTP 301-type redirect for all of the lesser-used URLs to the most-trafficked. Implementing this requires access to your server’s .htaccess file. You can find more information about modifying this file within your server’s documentation.

Using JavaScript Redirection

When HTTP redirection is difficult or impossible to do, you can use JavaScript redirection. There are many approaches to implement this, including sending users to the link indicated by the rel=”alternate” tag or setting any of the properties associated with window.location.

Keep in mind, however, that all of these methods add time to your page loads. By adding the need for additional JavaScript resources to your page, you increase the latency caused by the need to first download the webpage, then the need to parse and execute the JavaScript before the browser can execute the redirect.

However, prior to implementing JavaScript redirection, carefully consider whether this is necessary. Google sometimes refers to such practices as sneaky redirects, and if your page engages in what search engines deem inappropriate, your page will be penalized in the results rankings. In addition, such redirections can be a frustrating occurrence for your users, especially if it is unexpected or leads to a page different from the one requested.

Next Steps

In the best-case scenario, redirection triggers one additional HTTP request-response cycle, which delays page rendering. In the worst-case scenario, it may result in multiple, round-trip request-response cycles including, but not just limited to, DNS lookup, TCP handshake, and TLS negotiation.

Either way, redirection increases the amount of time it takes for your site to render, and you should minimize its use to optimize page performance. If, however, your site requires redirection, you should make sure to implement this so that your users see as little delay as possible.

Notes and Caveats

  • When setting up server-side redirection, be sure to keep the redirect URL consistent with the alternate URL specified in the page’s link rel=”alternate” tag or in the Sitemap.
  • Because HTTP redirection is handled server-side, it is typically faster than client-side redirection, especially if the browser can cache the new location of the requested file.


Chapter 7: Leverage HTTP/2

What is HTTP/2?

Instead of reducing the number of requests made by the browser to improve performance, a more effective (and longer lasting improvement) would be to implement HTTP/2 to boost your Google PageSpeed Insights score. HTTP/2 is the first new version of the HTTP protocol (which governs the connection between your servers and your visitor’s browsers) since 1999.

In short, the goal of HTTP/2 is to create a protocol for the web, that better aligns with how modern browsers and networks work, ultimately creating faster websites for everybody.

Some sites will weigh the benefits of adoption against the costs of implementation (primarily due to changes in web server configuration) and conclude that delaying the move to HTTP/2 would be a good idea. For your site, however, it’s clear that moving sooner rather than later is crucial for business success.

Why Leveraging HTTP/2 Matters


While more and more browsers are supporting HTTP/2, they will still support HTTP/1.1. As such, you could choose to change nothing to your existing site. However, if you do not implement HTTP/2, your website, even if it were once well-optimized, will begin to lag when compared to those that have made the transition. In addition, your site will display to users as unsecure and be penalized with regards to search engine rankings.


Generally speaking, all websites would benefit from using HTTP/2, especially in terms of page load speeds, but resource intensive sites are especially good candidates for taking advantage of the strengths of HTTP/2.

How HTTP/2 Works


Your website is probably resource and image-heavy, which contributes to its slower load times. In addition to displaying lots of media rich product, design, or ad content, your site most likely contains lots of pages for product descriptions, or user transactions such as a login portal, or checkout process and so on.

With HTTP/1.1, the best practice was to consolidate files as much as possible (for example, consolidating your style sheets or minimizing the number of scripts your site calls), since each resource required its own call, and multiple requests stacked up behind each other. However, with the multiplexing ability of HTTP/2 (which is the practice of sending and receiving multiple HTTP requests asynchronously via a single TCP connection), having a queue build up is no longer an issue. With HTTP/1.1, all resources must wait for the current request to complete before any further action can be taken, but with HTTP/2, multiple requests can be handled simultaneously. In the end, it takes much less time for the browser to receive all resources it needs build the site.

Multiplexing isn’t just a boon for pages loading lots of images–it can also assist with faster downloads of any of your site’s resources, including render-blocking assets such as Cascading Style Sheets and JavaScript files. Rather than creating large files that apply to multiple pages of your site (which is the current best practice, since this minimizes the number of HTTP calls your site needs to make), you can create style sheets and scripts that are more specialized. For example, you might have a set of resources that are called only when a user navigates to product pages and a separate set of resources that are called when a user navigates to content pages such as shipping policies, privacy notices, and so on.

Modern Web Trends Align with HTTP/2 Requirements

Possibly the most difficult aspect of the transition to HTTP/2 for a lot of websites will be complying with the requirement to run the site over a connection secured via Transport Layer Security (TLS). However, many sites, such as eCommerce retailers, have probably implemented  SSL/TLS on some of their pages to comply with things like the Payment Card Industry Data Security Standard (PCI DSS), a set of requirements imposed on businesses that handle major branded credit cards (such as Visa, MasterCard, American Express, and Discover). As such, moving to TLS for all pages of your site, as required by browsers currently supporting HTTP/2, would not be as drastic a change as it otherwise would be.

Next Steps

To Implement or Not?

The time involved and cost of implementing HTTP/2 could be high, especially if your site is hosted by a vendor that has not yet implemented complete support for HTTP/2. However, given the relative impatience of users with regards to page load times, and the resulting loss in revenue due to slow page load times and reduced user engagement, you should seriously consider transitioning as soon as possible.

You can find up-to-date information on how to implement HTTP/2 by referencing the appropriate documentation for your particular servers, but here are some guides that will give you an idea of what is required:

  • HTTP/2 Support and Implementation in Open-Source NGINX and NGINX Plus
  • The Complete Guide to HTTP/2 with HAProxy and NGINX
  • Enabling HTTP/2 on Apache

Typically the most difficult aspect of implementing HTTP2 is to run the website over a connection secured via Transport Layer Security (TLS). A good resource detailing how to implement TLS can be found here.


Chapter 8: Optimize CSS Delivery in Above-the-Fold Content

What is Delivering Above-the-Fold Content?

Google Pagespeed Insights test all critical resources, including CSS, that may block the initial rendering of the page. The fewer critical resources the browser has to download, the faster it can move on to processing any received content and render the site.

Why Optimizing CSS Delivery Matters


Your site might have one main CSS file and several supporting CSS files. Depending on how large each of the files are, you might consider consolidating these files. While combining CSS files results in the browser fetching an overall larger file, it reduces the number of calls the browser must make to fetch each individual file. Reducing the overall number of calls (and thus the amount of time it takes for the browser to fetch the files) will reduce the load time of your site due to latency.

How Delivering Above-the-Fold Content Works

One area where you might consolidate is instances where the @import method is used. The @import method allows you to import style rules from one style sheet into another.

@import url (“stylesheet.css”);

The issue with using the @import method is that files must be loaded sequentially, not simultaneously. This means that a given file that needs to import a secondary file will need to wait for the secondary file to load before it can do so. This waiting period adds time to your overall page rendering time.

Rather that calling a CSS file that uses the @import method, you might consider copying and pasting the necessary CSS from the secondary file into the original file, which would eliminate the need to download two files that can only be done sequentially.

If moving the CSS from the secondary file to the primary file isn’t possible, you can include the secondary file as you would any other CSS file in the HTML:

Using Conditional CSS

You might have CSS that is only required in some, not all, instances. For example, you might have CSS that applies only when the site is viewed in a browser below a certain size. While the browser will fetch all CSS files, you can mark certain resources as non-render blocking to improve your site load times. Note the browser does place a lower priority in downloading non-blocking resources.

Typically, CSS files are called from the HTML as follows:

However, you can use CSS media queries to address conditional cases and mark a given file as non-render blocking.

You can use media queries to check the conditions of one or more media features. For example, the above CSS declaration indicates that the browser should block rendering only if the condition is met. As such, you can tailor the presentation of your site such that only the necessary CSS, especially for your above-the-fold content, is render-blocking.


The browser can get the content processed and displayed to the user faster if there are fewer critical bytes it has to download. In addition to reducing the number of required resources (discussed in the previous section), you can also minimize the transfer size by optimizing and compressing the files fetched by the browser.

Next Steps

To minimize the delivery delay of content to your users, you may choose to implement one or more of the following techniques to prioritize the loading of CSS for your above-the-fold content and defer the CSS for content that is below-the-fold:

  • Using Inline CSS
  • Combining CSS files
  • Using Conditional CSS


Chapter 9: Eliminate Render-Blocking JavaScript

What is Render-Blocking JavaScript?

Prior to rendering a page, the browser has to build the Document Object Model (DOM) tree, a structural representation of the HTML that the browser understands, by parsing the HTML markup. During this process, the browser’s parser must stop every time it encounters a script to execute its content. Because this prevents further parsing and construction of the DOM, it is described as render-blocking.

As you can imagine, each and every stop adds to the amount of time it takes for a page to load, which is why it’s important to Google Pagespeed Insights you eliminate render-blocking JavaScript.

Why Render-Blocking JavaScript Matters

Depending on how the JavaScript is called from your HTML, the amount of time required to execute the required actions varies. If the script is inline with the HTML, the parser simply works through the script from top to bottom. If the script is an external file, the parser must make the appropriate request, either in-network or not, and wait for the file to download prior to executing its contents.

How to Manage Render-Blocking JavaScript


There are three main ways you can reduce the amount of time caused by render-blocking JavaScript:

  • using inline JavaScript
  • declaring a script asynchronous
  • deferring a script


Inline JavaScript is advantageous because it eliminates the time required for the browser to make a request for and download the external file.

The disadvantage of this method, however, is that the size of your HTML files increases (all the more so if same script contents must be included across multiple pages). As such, you should only use inline scripts for small amounts of content, such as the content required only for your above-the-fold content.


Because the browser does not halt DOM parsing and construction or the fetching/execution of other scripts required by the site during the download process, it can perform multiple actions simultaneously and render your site faster. There is, however, no guarantee as to the order in which asynchronous scripts execute, so this method works best for scripts that are not dependent on or depended upon by other scripts.


By indicating to the browser that a certain portion of scripts are not required for initial rendering, you can reduce the amount of time it takes for the page to load for your user. For example, you can separate out any JavaScript that does not impact your above-the-fold content and defer it to a later point. Additionally, deferred scripts are guaranteed to execute in the order they appear.

Next Steps

Because JavaScript is considered to be render-blocking, you can speed up the loading of your site by executing only the scripts required for your above-the-fold content and delaying all others. You can do this by including relevant snippets inline, marking an external script as asynchronous, or marking an external script as deferred. When deciding which method is most appropriate for your needs, you might consider the following:

  • If the script stands by itself and does not rely on any other scripts, use async
  • If the script relies on, or is relied upon, by another script, use defer
  • If the script is small, use inline JavaScript
  • If you have an async script that relies on your inline JavaScript, be sure that the inline script is
  • Placed above the async scrip
  • Contains no attributes (such as async or defer)


Chapter 10: Prioritize Visual Content

What is Prioritizing Visual Content?

Google PageSpeed Insights suggests that you prioritize visual content. Any time that 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 are handled first, and anything that is not immediately seen is handled later.

Why Prioritizing Visual Content Matters

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. If the resource is a JavaScript file, it must execute its contents.

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.

Consider the sample site pictured below. 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. Load the content window load prior to loading the navigation bar.

How to Prioritize Visual Content


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. You can gain critical improvements in page load time just by rearranging the order of snippets of code.


You can also use a Content Delivery Network (CDN) to bring visual content closer to the user for faster delivery. CDNs are networks of servers all over the globe that can host a website’s content and deliver that content to visitors. Each server that belongs to the CDN can have its own copy of the website’s content ready to go for when the next visitor makes a request. Then, based on the visitor’s location, the CDN can decide which server should deliver the content for optimal speed or cost.

CDNs make copies of content, store it on their servers and deliver to the closest user.


  • Faster performance because content is closer to end users.
  • Optimization because some CDNs can help store and serve different types of content in the most efficient ways.
  • Scalability because CDNs can help absorb spikes in web traffic.

Next Steps

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 using CDNs for faster performance, you can shave off time it takes to render your site.


Chapter 11: Reduce Server Response Time

What is Server Response Time?

Server response time is how long it takes to hear back from your server (also referred to as time to first byte, or TTFB); this is an important metric since nothing else can happen until your HTML is received. According to Google’s PageSpeed Insights, a good rule of thumb is to ensure that your server response time falls below 200 ms.

Why Service Response Time Matters

While server response times are usually not the primary bottleneck when it comes to slow page response and load times (slow server response times typically account for only 10% of the total delay time), there are still ways you can optimize your response times to improve your page’s performance.

The server’s response time to a request is determined as follows:



While there are many factors that influence how quickly your server responds, the following are are some of the primary factors in how fast your server responds:

  • Databases: How optimized is your database? How fast are your queries? Generally, the primary bottleneck when it comes to your server response time involves your database.
  • Traffic and Hosting: How many requests are made to your server? How good is your web host? Have you purchased enough resources to handle the traffic you are getting?
  • Resource Usage: How many and how resource-intensive are the files required to render your webpage? Are you caching your resources effectively?
  • Server Software: How efficiently configured is your server’s software? Are you using your server’s default settings, or have you configured your settings so that they are appropriate for your needs?

How to Reduce Server Response Time


There are two basic ways to reduce the amount of time it takes your server to respond to a request:

1. Use your existing resources more efficiently, or

2. Upgrade your resources.

In the next sections we’ll look at resources that could be upgraded or used more efficiently.


If your site relies on retrieving data from a database, make sure you have it optimized to perform as well as possible. In addition to speeding up the overall performance of your queries, a well-run database prevents even parts of your site that don’t use the database from slowing down. Slow queries are generally the number one reason why a server responds to a request slowly.

You should definitely prioritize analysis of your database response times if you’re trying to decrease your server’s response time. There are essentially four ways to optimize the performance of your queries:

  • Rewrite the queries. Do your queries return only what is necessary? How many queries are you running? Are they written with performance in mind (for example, are you using joins instead of looping through data repeatedly?)?
  • Use the appropriate indexes. Do your tables have the appropriate indexes?
  • Change your schema. Is there a better way to group objects such as tables, views, and stored procedures?
  • Use external caches. Can you move some of the load from your back-end to your front-end?

Traffic and Hosting

The first thing to check with regards to your web host is whether you have sufficient resources for the amount of traffic your site receives. More traffic to your site results in a longer wait time for your server to respond, which results in fewer users being served during a given period of time.

In addition, you should consider the amount of resources required per user. For example, if your site requires 20 resources to render for each user, one user will be making at least that many calls to your web server.

As the amount of traffic you receive increases, you’ll need to upgrade your hosting. The following are options available to you, listed in order from most economic (and therefore best for lower amounts of traffic) to those where you can maximize performance.


Regardless of which web server you opt to use for your web page, you can improve your server’s response time by configuring its settings to better suit your needs. For example, Apache, a free option that is one of the most used web servers on the web, is not the best performer if you install and use its out-of-the-box configuration, but it can be customized for high performance. Nginx, is another a free web server option, typically performs much better than Apache, even using its out-of-the-box settings.) Alternatively, you can certainly select a paid option that comes with custom support and configuration.

Next Steps

While server response times account for only 10% of the total delay time in delivering your site to your users, there are still ways for you to maximize your server’s performance and reduce any lags. By considering the amount of traffic you receive, your database and its optimization, your hosting and server software solutions, and the resources required to generate your site and optimizing these factors, you can work to reduce the amount of time it takes for your server to respond to a request.


Key Takeaways

Google PageSpeed Insights is a free tool that measures your site’s front-end performance on desktop and mobile devices against rules for speed and usability.  When you enter your website into PageSpeed Insights your site will receive a graded score out of 100 followed by green, yellow or red indicators that explains your site’s strengths and weaknesses.

To learn more about optimizing your webpage performance, visit our site. Meanwhile, here’s a brief recap of this e-Book’s 10 PageSpeed Insights that can affect site delivery:

1. Minify Resources

It’s important to remove unnecessary characters such as comments and whitespace from the source code to reduce HTML, CSS or JavaScript files. Removing redundant and unnecessary characters can create a smaller code that allows browsers to load faster.

2. Enable Compression?

Remember, when Google suggests you “enable compression,” they’re referring to HTTP compression, specifically the gzip compression scheme. HTTP compression works by compressing a document on the server side then sending it across the wire so a visitor can then unzip the file. Be sure to test your compression to make sure it was implemented properly.

3. Image Optimization

Image optimization plays a critical role in web performance since images are typically responsible for most of the downloaded bytes on a web page. When optimizing images, there are two common ways to compress the file. Lossless image optimization allows you to keep the quality of your image, but does not significantly reduce file size. Lossy image optimization, however, allows can reduce the file size greatly,* but you may see a loss in image quality. You should optimize your images based on how your images will be used on your website and the file type you’re optimizing.

4. Leveraging Browser Caching

Browser caching stores copies of files into a user’s browser. Storing data into a user’s browser eliminates retrieving files from a server and can reduce bandwidth and data consumption and decrease page load times. It’s important to determine and specify a caching policy so web developers can set guidelines and rules on what information to cache on a site.

5. Avoid Landing Page Redirects

Although there are legitimate reasons to use landing page redirects, there may also be cases where you have unnecessary redirects. Using redirection can cause multiple request cycles that can slow down your site. If you must use a redirect, make sure to minimize the delays in the redirection and refrain from using sneaky redirects.

6. Leveraging HTTP/2

HTTP protocol hasn’t released a new version in nearly 20 years. HTTP/2 works well with modern browsers and networks to produce faster websites because it can handle multiple requests simultaneously. Although it may cost quite of bit of time and money, implementing HTTP/2 reduces page load times and in turn increases user engagement.

7. Optimize CSS Delivery in Above-the-Fold Content

When loading CSS, prioritize the above-the-fold content first to minimize the delay of content delivery to your visitors. Implement inline CSS, combine CSS files and/or use conditional CSS to increase site speed.

8. Eliminate Render-Blocking JavaScript

Since JavaScript is considered render-blocking, you can increase site speed by executing only the scripts required for above-the-fold content and delaying the others. You can reduce the amount of time caused by render-blocking JavaScript by using inline JavaScript, declaring a script as asynchronous or by deferring a script.

9. Prioritizing Visual Content

When creating web pages, it’s important to place your most important content at the top of the HTML file because HTML parses starting at the top. Restructuring your HTML our using CDNs can increase site speed and boost web performance.

10. Reduce Server Response Time

Databases, traffic amount, server hosting, resource usage, and server software are some of the main factors that influence server response times. The two basic ways to reduce the amount of time it takes for your server to respond to a request is to either use your existing resources more efficiently or to upgrade your resources. Although server response times typically account for only 10% of your site’s delivery delay, PageSpeed Insights considers this to be a key component of determining your PageSpeed Score.

Google PageSpeed Insights is an informative tool that provides a general overview of how your site is performing on the web. If you’re interested in a more in-depth evaluation of your site and analysis of your overall web performance, contact us to try Rigor for free. We identify and fix performance problems before they impact your users, so you can focus on building your business.



SRE and the Four Golden Signals of Monitoring

Learn More


Faster, Smarter Resolution: The Incident Response Guide for Kubernetes

Read Now


Why DevOps Matters: A Guide for Collaborative Transparency in Incident Management

Learn More
Get started with a free trial of Splunk Infrastructure Monitoring today.