Auditing a website with Google PageSpeed | SEO Tutorials
What is Google PageSpeed
Google PageSpeed is an open-source web development tool to audit webpages. It’s run online or within your Chrome Browser’s development tools panel. If you’re running it within your browser it can also go by the name Google Lighthouse.
The online half, PageSpeed, is found here.
The Chrome half, Lighthouse, is built into Chrome Browser. Hit CTRL-SHIFT-I (if you’re on a PC). This will load ‘DevTools’ and take you directly to the ‘Audit’ tool tab. You can also use F12 to load Dev Tools and manually navigate to the ‘Audit’ panel.
Is there a difference between Lighthouse and PageSpeed?
Yes … and no. The data you’ll get back is the same. But I lean on the built-in-browser version more because PageSpeed’s online results are different every time I run it, even when it’s run back to back, even when I make zero changes to the site I’m auditing.
I’ve looked up why on various forum boards and haven’t found an official (i.e., Google Rep.) answer despite other users noticing the same thing.
There are five categories to audit.
- Progressive Web App
- Best Practices
Two ‘devices’ are audit-able.
- Some recommendations
I suggest you pay careful attention to your mobile performance scores. Google prioritizes mobile performance, and your organic rank will improve if your website is snappy on mobile devices.
They include an SEO audit tab, but it’s minimal. It covers almost nothing, and what it does cover isn’t SEO.
Here’s what I mean: This SEO portion of this auditing tool has very little to do with actual SEO. SEO is about understanding keywords, writing SEO optimized content and conducting competitor research. This tool covers none of that.
If you are interested in learning about what keywords are and how you can identify them, I’ve written an article titled How To Do Organic Keyword Research. That said, this auditing tool is still extremely valuable because it includes a relatively detailed performance report that you’ll use as a part of your SEO efforts.
Categories have a performance score from zero to one-hundred. While it’s wonderful to see all green when you finish an audit, you’ll often see a mix of green and orange.
What do the performance score colors mean?
- 0 to 44 (poor): Red
- 45 to 74 (average): Orange
- 75 to 100 (good): Green
Scores are compared against other top-performing websites that Google has cached as historical data. They’ve seen that top-performing websites load in around 1.5 seconds. You’ll see green if your site loads in less than 2s, orange is between 2s-4s, red is over 4s.
Note: some websites will never see all green. Not every website needs to be all green, either. However, optimize it as best as you can.
Performance looks at six metrics to calculate page load speed. It’s scored by time. A good target is a score below two seconds. However, some web pages might not be capable of having a below two-second score for some of these values.
- First Contentful Paint
- Speed Index
- Time to Interactive
- First Meaningful Paint
- First CPU Idle
- Max Potential First Input Delay
First Contentful Paint (FCP) marks when the first block of text or image is visible to the person loading the site.
Improving your FCP score depends on what’s slowing it down. This requires understanding how the DOM works. And that is a little too in-depth of a topic for this. I’ll come to it at a later time in a later article.
Side Note: There are plugins available that improve your speed time by managing other plugins. And that’s the go-to solution for many people. My opinion’s to use as few plugins as possible and write as much code as possible. Many of the features plugins provide end up being much easier to code than you think.
Another performance killer are render blocking resources. Lighthouse splits them into three main kinds:
- HTML imports
Each time you load a script, stylesheet or import something, the browser needs to download and process another file.
WordPress, as impressive as it is, slows down very quickly with all its fancy themes and plugins people download into it because each adds another set of scripts, style-sheets and imports.
Time to interactive (TTI) is how long it takes for your web page to load and be fully interactive fully. The delay between when it’s displayed and when it’s functional is important to minimize because it might mistakenly think your website’s broken and leave.
Asset cleaning plugins try to ‘minify’ or condense all of the files you’re loading into one large load. Some will also allow you to avoid loading certain assets. This sometimes breaks things, so it won’t be usable in every case, but many do a good job for the most part.
First CPU Idle is being skipped because while it’s still displayed as a metric, Google hasn’t used this since Lighthouse 6.0.
Instead, they recommend focusing your efforts on TTI in place of this. Max Potential First Input Delay (FID) measures what the longest time a user needs to wait before the website acts on their action.
For example, your website’s loading and the user immediately clicks your catchy button. If the server is still loading the website, there will be a time-delay after they click it (before the clicked action happens). That annoys people. This metric helps you avoid that.
Accessibility audits thirty-one metrics.
- aria-* attributes match their roles
- aria-* attributes have valid values
- aria-* attributes are valid and not misspelled
- The page contains a heading, skip link, or landmark region
- Document has a title element
- html element has a lang attribute
- html element has a valid value for its lang attribute
- Image elements have alt attributes
- Lists contain only li elements and script supporting elements (script and template tags)
- List items (li) are contained within parent elements
- user-scalable=”no” is not used in the meta name=”viewport” element and the maximum-scale attributed is not less than 5.
- accesskey values are unique
- Access keys let users quickly focus a part of the page. For proper navigation, each access key must be unique. Learn more.
- roles have all required aria-* attributes
- Elements with an ARIA role that require children to contain a specific role have all required children.
- roles are contained by their required parent element
- role values are valid
- audio elements contain a track element with kind=”captions”
- dl‘s contain only properly-ordered dt and dd groups, script or template elements.
- Definition list items are wrapped in dl elements
- frame or iframe elements have a title
- input type=”image” elements have alt text
- Form elements have associated labels
- Presentational table elements avoid using th, caption or the summary attribute.
- The document does not use meta http-equiv=”refresh”
- object elements have alt text
- No element has a tabindex value greater than 0
- Cells in a table element that use the headers attribute refer to table cells within the same table
- the elements and elements with role=”columnheader” / ”rowheader” have data cells they describe.
- lang attributes have a valid value
- video elements contain a track element with kind=”captions”
- video elements contain a track element with kind=”description”
- Most of these measurements help people who sometimes fall outside of our considerations when we buit websites. Specifically, it refers to users experiencing temporary or permanent impairment or disability, physical or non-physical.
Assistive technology relies on the many conditions in the above list to make sure users who use assistive tech can access the content.
This also covers content blocking issues, like a website’s content not being loaded because of a geographical location (looking at you, Youtube).
It also covers the navigation menu’s not loading properly on tablets or mobile phones.
An interesting, often over-looked design element is contrast problems. This happens when someone selects a background color that’s too close to the font being displayed. Think of a dark grey background with black font.
If you’re interested into deep-diving this feature, check out the Web Content Accessibility Guidelines.
There are fifteen audits within this metric.
- Browser errors were logged to the console
- Avoids Application Cache
- Application Cache is deprecated
- Uses HTTPS
- Uses HTTP/2 for its own resources
- Uses passive listeners to improve scrolling performance
- Avoids document.write()
- Links to cross-origin destinations are safe
- Avoids requesting the geolocation permission on page load
- Page has the HTML doctype
- Avoids requesting the notification permission on page load
- Avoids deprecated APIs
- Allows users to paste into password fields
Best practices is an attempt to get a certain standard to web development. I’m not going to expand on many of these, however, their’s one worth pointing out.
It’s important to use HTTPS on every website. This includes websites that aren’t E-comm.
HTTPS encrypts the data transfer between you and your users. Contact and quote forms are a fantastic example of why you want HTTPS on your site. There’s no reason to allow a hacker to see the contact details being provided by your customers.
This is important enough that Google Chrome flags non-secure sites (standard HTTP-only sites), asking if users want to be directed back to search results just in case it’s a scam site.
- Document has a title element
- Document has a meta description
- Page has successful HTTP status code
- Links have descriptive text
- Page isn’t blocked from indexing
- robots.txt is valid
- Image elements have alt attributes
- Document has a valid hreflang
- Document has a valid rel=canonical
- Document uses legible font sizes 100% legible text
Title’s show up in search results. If you don’t set a manual title, you will end up with whatever default or blank title came with your website. For example, WordPpress defaults the page title to the one you typed in when creating a page or post.
Meta descriptions are the summaries provided in search results so users can decide if they want to click your link. WordPress does it’s best to capture the text from the first paragraph of your page, but I prefer to manually type it out myself.
HTTP status codes errors point to resources being inaccessible to Google’s robots. Pages with these errors might not get indexed by Google (depending on the error).
Links have an area to create a title in them. These tags are used by assistive technology and are standard practice to include.
Pages can be blocked from being indexed through the robots.txt has denied permissions. There are times when you want to block certain pages from being indexed, but the audit won’t know if it’s an intentional block.
Robots.txt tells search engines which parts of your website they should crawl and which to avoid. It also controls whether they should be indexed for search or not. There are times when you want a few webpages to not show up in results.
Image elements that are informational need to have descriptive texts. The robots won’t know whether an image is informative or decorative, so deal with it on a case by case basis.
Hreflang tells search engines which version of a webpage they should include within search results for a given language or region.
Canonical tags are important. If you need to have duplicate content on your website, this tag tells the search engine that this page is the one that should receive credit. Without it, Google might penalize you for having duplicate content.
Font sizes need to be 12px or larger for most people to read. This is here so people won’t have to zoom in or pinch to zoom to read your text.
Progressive Web App
The platform you're reading this blog on right now is a Progressive Web App. It probably doesn't look any different than most other websites you've been on, however, the way this is coded makes it one.
Progressive Web Apps (PWA) are built and enhanced with modern APIs to deliver native-like capabilities, reliability, and installability while reaching anyone, anywhere, on any device with a single codebase. To help you create the best possible experience, use the core and optimal checklists and recommendations to guide you.
From Web.Dev, What Makes A Good Progressive Web App
The take-aways are installability, speed and security. This is beyond a responsive website. It’s a website that really feels like a fully installed application. LinkedIn is a fantastic example of one. When you load it in a mobile browser it looks and acts exactly as a download application would.
It sounds odd. I know.
That covers it!
Interested in having your website audited? Give me a call!