1. Home
  2. Blog
  3. Mastering Google Lighthouse

Google Lighthouse:
How to Master the Google Lighthouse Audit

Jul 25, 2019

As of July 2018, Google has been using page speed in their algorithm to determine how to rank web pages. Along with page speed analysis, Google also provides insights into other important aspects of your site. In this article, I will teach you how to master these insights so you can provide your users a better experience.

Google released v5 of the PageSpeed Insights API in November of 2018. It now uses Lighthouse as its analysis engine and also incorporates field data provided by the Chrome User Experience Report (CrUX).

Let's break down the Google Lighthouse report into 4 major sections. There are currently 5 audits that you can utilize in Lighthouse. The Progressive Web App (PWA) audit is meant more for web applications (not your typical website), so we will not worry about that for now. That leaves the Performance, Best Practices, Accessibility & SEO audits. All you will need is 1 day of time, your favorite text editor & Google Chrome.

  1. Performance audit:
    Not just your typical page speed report anymore.

    This might be the most important audit from Lighthouse. Since Google has decided to start using page speed as means of ranking sites, performance has become more important. Note: Since implementing Lighthouse, Google has decided to use different metrics for page speed ‐ a good score last year, does not mean a good score this year.

    In my opinion, you just can't settle for anything less than a score of 90/100 on this audit. So, let me explain the parts of this audit that can easily be addressed and give you some pointers on how to get a higher score.

    Time to first interactive

    The most important metric that Google uses. This basically means ‐ The time it takes for the browser to render the above the fold content and allow interactions. The longer this takes, the lower your score will be.

    Address the following issues on your site, and this metric will skyrocket.

    Prioritize critical CSS

    Unlike previous versions of the page speed reports from Google ‐ where they would recommend combining all CSS, that is just not the case anymore. Now, you should worry about the critical CSS. Critical CSS is the CSS that is required for the design/layout of the page. Mostly, anything above the fold should be rendered using the critical CSS … and the rest should be deferred until after the "Time to first interactive".

    This is done by identifying the critical CSS and inlining (placing the CSS inside of a style tag instead of referencing via a link tag) it in the head of the HTML. It is important to note that Google considers link tags with rel="stylesheet" and a media attribute that applies to the current scenario as render-blocking, because it requires an http request to complete before knowing how things should look.

    What do we do with non-critical CSS?

    For all non-critical CSS, we still use link tags. But, instead of rel="stylesheet", we will use rel="preload". This tells the browser that this resource is important and it should be downloaded. It will not be treated as a stylesheet, because of the new rel attribute … and thus, it will not be considered render-blocking. Now, the trick is telling the browser what to do with it once it is downloaded ‐ and for that, we add onload="this.rel='stylesheet';". This tells the browser to switch the rel attribute when it is done loading so that it can be treated as a stylesheet. A quick Google will tell you how to use a fallback for browsers that do not support the preload rel attribute.

    Note: Hover styles, transitions & animations can all be deferred, because they are not crucial to the rendering of the page. In fact, there are conditions where adding transitions in the critical CSS can increase your time to first interactive (because the browser will have to wait until the transition is complete).

    Defer all Javascript

    Let's just keep this one simple. Your javascript should be as far down the page as possible and should include defer or async attributes. You should not rely on javascript for the rendering of your page.

    Defer all offscreen images

    Lazyloading, lazyloading, lazyloading. Repetitive … I know … but it is important. Why make the user wait for images to load that aren't even on the screen? Instead, use lazyloading to defer them. Wait until they are close to being in-view before sending an http request to load them.

    Note: display: none; on an image will prevent the browser from sending a request. The browser will wait until it is inline-block, block or inline before it attempts to load the image.

    Cover the basics

    We can group the basics together. These all carry over from previous page speed reports. Some of these will require your webmaster to perform.

    There are many more pieces of the performance audit, but these will increase your score drastically if done right.

  2. Best practices audit:
    Find common security problems & and make some technology decisions.

    Best practices? What does that even mean? Well, it covers a range of things. Most importantly, it covers some security issues.

    Follow the steps below to nail this audit.

    1. Use https not http. Google has preferred https for a long time now, and if you haven't switched … then you have bigger problems on your hands.

    2. Add rel="noopener" to all external links on your pages. This tells the browser that the page you are linking to does not have access to the window.opener property. Additionally, adding "nofollow" to the rel attribute will indicate to crawlers that you do not wish to pass along any SEO juice to the linked page.

      Note: You should use target="_blank" on all links that point to an external domain.

    3. Do not ask your users for permissions (Location, camera, microphone, etc) on page load. Instead, wait until you need access.

    4. Never display images with an incorrect aspect ratio.

    5. Never use document.write in your javascript.

    6. Use http2 if possible. This doesn't prevent a 100/100 score, but it does help the browser load resources more efficiently.

  3. Accessibility audit:
    Make sure your web page is accessible by everyone on the web.

    Your pages need to be accessible by your users. But, did you ever consider that your users may not be able to consume your content in the way that you intended?

    Accessibility is a very complicated matter ‐ and the Accessibility audit does not cover a lot if it. It does, however, cover the basics.

    1. All buttons and navigational elements should have an aria-label attribute that indicates what this element does.

    2. Every page should have an appropriate title element.

    3. Every form element should have a label.

    4. Every image should have an alt attribute.

    5. Don't set the "tab order" for any element. Let the browser decide how the user will navigate with the keyboard.

    6. All text should have a good contrast with it's underlying background color. Text whose color is too close to it's background-color will be too hard to read for some users.

  4. SEO audit:
    Cover all your bases with page and information structure.

    While SEO is a very complicated thing, there are some basics that you just cannot do without. SEO is an ongoing process and changes based on your needs. Below is what the SEO audit is looking at.

    Note: Items in red indicate UX decisions

    • Make sure all pages have a title and a meta description.

    • Make sure you are using lang and hreflang where appropriate.

    • Ensure all pages have a rel="canonical" link in the head. This tells Google which url to use in the SERPs

    • Use legible font size and never, never, never hide text on a page. Did I mention that you should never hide text?

    • Never use plugins (embed, object, applet).

    • Include descriptive text in your links. Avoid the dreaded "click here" link, and instead use text that describes the content you are linking to.

    • All pages should return a 200 status code.

    • Make sure you have a valid robots.txt file. Previously, it may have been best practice to exclude CSS & Javascript from being crawled … however, it is now recommended that you allow that via your robots.txt file. Google's crawlers cannot determine what your site looks like without also crawling the CSS & Javascript.

    • Size all your tap targets appropriately. On mobile especially, it is important that your links (buttons, navigational elements) are sized big enough to avoid users clicking or touching the wrong thing. Give your site a check … 10 to 1 you have elements in your navigational sub-menu that are too close together.

Ready to see if it works?

Check if your hard work payed off by running your site through the Lighthouse Audit.

Share this page