There is actually a way to test if a web page performs slower than it should – and as you might have guessed, Google developers hold the key to quantifying page performance. A score is assigned to the page and this is used as a measure of site performance. Many remember the PageRank from the past and how every SEO company tried to optimize this number solely because it existed. Well, the PageSpeed Insights score is the new “it” number and you should get in the game.

A perfect PageSpeed score will be difficult to achieve for most sites. There are three things to keep in mind around this topic:

• Prioritization, mapping out a plan and measuring what you’ve put in place will lead to improved stats
• PageSpeed Insights score is more complex than you may think
• Bandwidth is a smaller issue than latency in load times

This article is written taking into consideration that SEO practitioners are reviewing it. The objective is for you to absorb the critical points enough to understand the right questions to ask and thus provide better recommendations.

Note: It is important to point out that HTTP2 will improve some problems mentioned in this article. Precisely – multiple requests to the same server are less difficult. It is not a cure-all.

Bandwidth is a Smaller Issue than Latency in Load Times

An initial review of PageSpeed Insights’ rules could have one surmise that the entire point is to serve fewer bytes to the user. Decrease, enhance, compact – but size only provides half of what is needed and no matter what, the server needs time to respond.

A typical request – a user type in an URL into the address bar and initiates the search or request that is made. Many things are triggered when this happens. The largest part is the transfer of solicited content and it’s this part that is indeed affected by the size of that content and the bandwidth.

Fulfilling a request initiates several procedures including:

1. Locating the server
2. Connecting to the server
3. Idling until a response is received
4. Accepting response

Each procedure requires a certain amount of time to be realized. One, two and three are independent of file size as they occur with all responses, regardless of size.

Receiving a Response Is a Requirement (For Now)

For now, it is an accepted fact that network signals cannot travel faster than the speed of light. In theory, that is our known maximum. In terms of real standards, it really does take longer than that for a data transfer. For example, scientists have calculated it takes 40ms for light to travel round trip from New York to Paris. Hypothetically, for data to cross the Atlantic it should take twice that amount of time meaning it will take 80ms to receive a response from a server.

For this reason, CDNs (A content delivery network (CDN) is a system of distributed servers (network) that deliver webpages and other Web content to a user based on the geographic locations of the user, the origin of the webpage and a content delivery server.) are in use. They physically place servers closer to users which is literally the only way to minimize the time it takes to ping a server.

How much does speed really matter:

This chart is from Chrome’s Development Tools:

The entirety of the values in the pink box is what we are considering “latency”. The total is about 220ms. The real transfer of the content duration was 0.7ms. Even if the file size was reduced or compressed, it would not have had an impact on speed. Reducing latency is the only way to reduce request time.

Does loading a page take many requests?

In order to load the content required to render a page, it demands more than a single request. The browser normally learns the number of resources necessary to render a page if the URL corresponds to a particular webpage. They could include font files, CSS or JavaScript. It must repeat the steps listed above iteratively to load every file.

 

Rule	Skeptical reading
Optimize images	Unless you have huge images, this might not be a big deal. This is only measuring whether images could be further compressed — not whether you’re loading too many.
Enable compression	Compression is easy. You should use it. It also may not make much of a difference unless you have (for instance) huge JavaScript files loading.
Minify HTML	Will likely reduce overhead only by tens of KB. Latency will have a bigger impact than response size.
Minify CSS	Will likely reduce overhead only by tens of KB. Latency will have a bigger impact than response size.
Minify JS	Probably not as important as consolidating JS into a single file to reduce the number of requests that have to be made.

Luckily, the browser doesn’t have to look up a server once it’s been found (“DNS Lookup” above). Waiting for a response once it connects still occurs.

A cynical review of tests for PageSpeed Insights

Tests for PageSpeed Insight encompass things that affect speed. Implementations for large sites are not easy and site design will determine their impact. No excuse not to perform the evaluations – following best-practices is a good practice. Believing they represent the entire site speed is just wrong.

Keeping that in mind, below is the cynical review of every PageSpeed Insight rule.

 

Tests concentrating on reducing bandwidth use

 

Rule	Cynical reading
Optimize images	Size matters. If you do not have huge images, no worries. This only measures if image compression could be increased – nothing to do with how many loaded.
Enable compression	Compression isn’t hard. You should utilize it. Having huge JavaScript files load also matters – compression won’t make a big impact if you don’t have this.
Minify HTML	Will probably only minimize overhead by tens of KB. The size of the response will have less impact than latency.
Minify CSS	Will probably only minimize overhead by tens of KB. The size of the response will have less impact than latency.
Minify JS	Consolidating JS into 1 file to minimize requests made is usually more important.

 

Tests concentrating on reducing latency

Rule	Cynical reading
Leverage browser caching	Absolutely cache your own files. Many files enhanced by caching are most likely hosted on 3rd-party servers. To effect those cache times, you’d have to host them on your own server.
Reduce server response time	Threshold on PSI is too high. The physical latency of the server is lessened by only measuring the amount of time for the server to respond after a request is received.
Avoid landing page redirects	Absolutely.
In above-the-fold content abolish render-blocking JavaScript and CSS	A legitimate issue that can be irritatingly problematic. Most performance goals do not require maintaining zero requests on top of the initial page load to render above-the-fold content.
Prioritize visible content	This actually matters.

 

This is not the be-all, end-all on site performance. Outside of these assessments, here are some things to ponder. Some things are not within the realm of PageSpeed Insights and some are only included halfway:

• Caching content is in your hands.
• Decrease 3rd-party content loads.
• Decrease server response time past the minimum mandatory to pass PageSpeed Insight’s test.
• Locate the server closer to the end user – use a CDN.
• Ensure using HTTP2 will help decrease blocking requests.

 

How to advance

Chrome DevTools was used for the screenshots in this post. It’s built into the browser and permits the user to analyze exactly what occurs when a page loads.

In place of relying on the PageSpeed Insights tool, load it in Chrome. Review the performance. Analyze which requests actually use more time. More times than not, what you find out will be easily apparent: too much time to load ads, an obvious example.

Setting Goals

In terms of PageSpeed, if perfection is not your goal, define one. It is imperative to have a point to compare with current performance. Decreasing bandwidth requirements will enable you to see if this helps with that goal. You might find you also need help to reduce latency (manage fewer requests, high-priority content loads first, utilize a CDN).

Organize

Organize page speed updates – this is important. More importantly, figure out what actually needs to load. PageSpeed Insights will attempt to surmise whether you are prioritizing above-the-fold content. This is a great goal. It may not be a perfect calculation and it could possibly benefit you more to split content into noncritical and critical paths regardless of what is supposedly above the fold.

For example: If your site is dependent upon ad revenue, you could load all content first and then load ads. Deciding how to provide less is trial and error for your team. PageSpeed Insights is a one-size-fits-all solution… you just have to learn how to wiggle in.

It’s a wrap

What we know: PageSpeed Insight can be helpful. The assessment and improvement of site speed can be handled in better ways as a perfect score does not automatically lead to a fast site.