What is a Page Speed Audit – In Plain English

8 min read

Note: this is not a Page Speed Audit How-To but more of how to read one and what you should expect.

When you visit a website, did you know that you are actually downloading it? It may seem obvious, but websites are made up of files that tell your browser how it looks, how it functions, and what content is there for you to experience.

The end result is what you see, like the home page of Weather.com.

When you type in a URL, some Internet magic happens and your browser begins to download files from another computer. First, it downloads the HTML: the language that ties the web page together.

How to View a Page’s HTML

Press CTRL + u or right-click in Chrome and “inspect” any part of a web page to see its HTML. Most of the time, things that will need to be downloaded start with src (for source).

Within that HTML code are requests to download more files that will support how the page will look and work. CSS (cascading style sheets) tell the browser a lot about how a page looks, from the size of the page in relation to your browser window to the colors of backgrounds and text.

JavaScript (JS)  files are requested, too. These files tell the browser about special things the web page can do, such as play a video or show ads.

Images are included as well. They can range from beautiful photo-realistic pictures (.JPG) to small icons and logos (.PNG, .GIF). 

All of these files need to be downloaded and processed by your browser before you see the final version of the web page you’re visiting. Like files on your computer, JavaScript, CSS, HTML, and image files all take up space on a hard drive. In the case of the web, the hard drive may be thousands of miles away on another computer.

What you see in your browser is like a Photoshop picture that had a lot of layers but got flattened. The time it takes a browser to do the following is Page Speed:

  1. You type in a URL in your browser and it “magic” happens
  2. The magic is really your browser connecting to web page files on another computer far, far away (a server)
  3. Your browser downloads the HTML file of the page
  4. The HTML file provides further instructions about what else needs to be downloaded
  5. Generally based on the order in the HTML (the line numbers in the source code), CSS, JS, and image files are downloaded
  6. The browser gets instructions from these files to begin “painting” the end result: the web page!
  7. CSS determines the size of the page, fonts, text colors, background colors, navigation elements, and so on. Sometimes, additional images are referenced in CSS files which results in more downloads!
  8. JS files usually determine how a page functions but can also determine how a page looks
  9. Once the browser has downloaded and processed all of the necessary files, the final experience is “flattened” or painted”

Measuring Page Speed

Page Speed is a measured assumption of how long it should take a browser to completely download and render a page from beginning to end.

But what does that actually look like? To the user, it looks something like the image below: a slowed down rendering of Weather.com’s home page on mobile.

The animated image above shows how Weather.com loads visually on a mobile device, like your smartphone.

Behind the scenes, Weather.com’s home page looks like this while it’s loading:

This is a waterfall view of Weather.com’s home page as the browser downloads and renders each file.

Each row in the waterfall image above is an individual file that needs to be downloaded and processed. The extensions (.js, .png, etc.) indicate the file type that I mentioned earlier in this post.

This screenshot comes from the tool WebPageTest.org, a free website performance tool and perhaps the oldest. Like many Page Speed auditing tools, WebPageTest allows you to toggle between mobile and desktop results.

Mobile vs Desktop Page Speed

You most likely experience the web in one of three ways:

  • On your laptop or PC (Desktop)
  • On your phone (Mobile)
  • On your tablet (Tablet)

As an SEO, the differences in experiences are extremely important. In 2018, Google announced that mobile Page Speed would impact organic rankings for searches done on mobile devices.

This means that websites that load slowly were expected to lose rankings or struggle to obtain them. Mobile usage has been on the rise over the last few years and the web is evolving to match the requirements of its users. Page Speed is one of the pillars of this evolution.

What Page Speed audit tools exist?

Either as an SEO, a developer, or a client, you can expect to get Page Speed audits from a few major sources. Again, this isn’t a tutorial on how to perform the audit but I would like you to learn how to read and take action from one.


As mentioned above, WebPageTest is old school but is still one of the best.

The screenshot below shows the main highlights of your Page Speed audit. If you’re having trouble seeing any of the images below or just want to take a peek at the full audit for Weather.com, you can here!

Aside from the Lighthouse and CDN scores, WebPageTest (WPT) uses a letter grade system. This test was done for Weather.com’s home page on mobile. According to the letter grades alone, this page looks pretty optimized for mobile Page Speed.

However, the load time in the table directly below these results tells a different story.

With a median load time of 7.194 seconds on mobile, this should raise some alarms with the Weather.com developers and managers. Weather.com has a lot of competition from other weather websites, local news sites and apps, and Google itself. In order to continue being the weather resource, Weather.com should make improving its Page Speed a priority.

Looking at some of the timings, the first byte doesn’t connect until 1.5 seconds after you type in “weather.com” and hit [enter]. The start render, like the Photoshop analogy of “flattening” the files, doesn’t begin until 4 seconds after that. 

Farther down on the WPT result page (past the screen shots and waterfalls) are breakdowns of the resources on this page. Resources are those file types I mentioned earlier: JavaScript, CSS, images, fonts, etc.

The requests chart shows the percentage of files loaded by Weather.com. Bytes indicates the sizes of those combined files.

This is all great information but not necessarily actionable by itself. On the Performance Review tab you’ll see a clearer picture being painted about what’s really impacting load time.

The image below shows a Full Optimization Checklist by WPT for Weather.com.

This Page Speed checklist includes the following:

  • Keep-Alive
  • GZip
  • Compress Img (Images)
  • Progressive (Images)
  • Cache Static
  • CDN Detected

The definitions of each of these Page Speed factors can be found here. (CTRL + F Glossary to find them fast.)

Though you may not know how to correct the issues, you can share this info with your website’s developers (based on the chart):

  • A few images could be compressed further
  • Some of the images are not progressive
  • Some of the static resources are not being cached

Overall, the WPT report was very positive, with just a few potential optimizations. But there is a second tool we should run, called Web.dev.


Web.dev/measure is a free tool from Google that utilizes Lighthouse, an automated app that analyzes web pages for speed, SEO-friendliness, accessibility, and general web best practices.

Lighthouse is also integrated into Chrome under the developer tools. Like WPT, Web.dev provides a score, this time a numerical scale of 0 to 100.

In Web.dev, Performance is where you’ll see Page Speed issues. In this tool, Weather.com’s home page received a 23/100, much lower comparatively to WPT’s high letter grades.

So what’s going on? To dig deeper, click the Performance tab and scroll down to the issue cards.

This data is probably helpful for developers, but it’s not very clear or actionable alone. Scroll down further and you’ll see actual Page Speed recommendations from Google that you can share with your website team.

Each issue has an associated guide linked within the table in case you or your developers need more information about why the issue matters and how to fix it.

Next Steps

In another post, I’ll write a tutorial on how to actually perform an in-depth Page Speed audit. For now, make sure you look past scores and grades to see the real issues that need to be fixed. Demand actionable next steps in terms of what needs to be fixed in a format you can easily hand off to your IT and website teams.

In the meantime, please check out these Page Speed articles and tutorials.

Bulk Testing PageSpeed Insights with the SEO Spider

How to Conduct Quick & Thorough Page Speed Audits

Stone Temple Page Speed Guide

Moz Page Speed Guide

Leave a Reply

Your email address will not be published. Required fields are marked *


© 2019 Chris Countey