At Ninjible, performance is an important starting point when developing websites and digital platforms. Not to achieve a perfect score of 100 at all costs, but because a fast, stable and responsive website contributes to a better user experience.
What is Google Lighthouse?
Google Lighthouse is an open-source tool that lets you automatically test various aspects of a web page. Lighthouse looks at, among other things:
- performance;
- accessibility;
- best practices;
- SEO.
For each aspect you get a score and recommendations for possible improvements. You can run Lighthouse from Chrome DevTools, among other places. Google PageSpeed Insights also uses Lighthouse for the technical analysis of a page.
What does the Lighthouse Performance score mean?
The well-known Performance score ranges from 0 to 100. According to the Chrome for Developers documentation on Lighthouse scoring the scores are divided as follows:
- 90–100: good;
- 50–89: needs improvement;
- 0–49: poor.
The Performance score is not based on a single measurement. Lighthouse combines several metrics in a weighted average. Some metrics therefore have more influence on the final score than others.
The Performance score is built from five key metrics:
- First Contentful Paint (FCP): 10%;
- Speed Index: 10%;
- Largest Contentful Paint (LCP): 25%;
- Total Blocking Time (TBT): 30%;
- Cumulative Layout Shift (CLS): 25%.
These weightings show why a single technical problem can have relatively large influence on the total score. In particular a high Total Blocking Time, a slow Largest Contentful Paint or many unexpected shifts can weigh heavily.
1. First Contentful Paint (FCP): when does the first content appear?
First Contentful Paint (FCP) measures how long it takes before the browser shows the first piece of content from the Document Object Model, or DOM, on screen. That can be, for example, text, an image, an SVG element or a non-white canvas element.
FCP mainly says something about the first impression of speed. A visitor has opened a page and wants confirmation as soon as possible that something is actually happening. A blank white screen for several seconds feels much slower than a page on which content appears almost immediately.
For mobile Lighthouse tests, an FCP of at most 1.8 seconds counts as good. On desktop, Lighthouse applies stricter limits. When comparing tests, it is therefore wise to always check whether you are looking at the mobile or the desktop measurement.
FCP doesn't tell the whole story. That the first piece of content is visible doesn't mean the most important content of the page has loaded. For that we look at LCP.
2. Largest Contentful Paint (LCP): when is the most important content visible?
Largest Contentful Paint (LCP) measures when the largest visible content element within the viewport is displayed on screen. That can be, for example:
- a large header image;
- a hero image;
- a prominent block of text;
- a large image within the visible part of the page.
LCP therefore often comes closer to the moment at which a user thinks: the page has loaded.
Google considers an LCP of at most 2.5 seconds good. For this and other Core Web Vitals, Google looks at the 75th percentile of measured page views in real-world data. That means at least 75% of visits must fall within the recommended limit.
Is your LCP too high? Then large images, a slow server response, render-blocking stylesheets, web fonts, client-side rendering or inefficiently loaded resources, among other things, may play a role.
3. Speed Index: how quickly does the page become visible?
Speed Index measures how quickly the visible content of a page is displayed during loading. For this, Lighthouse makes a visual recording of the loading process and calculates how quickly the page fills up frame by frame.
Suppose two websites are both fully visible after three seconds. Website A shows more and more usable content during those three seconds. Website B remains almost completely empty and then appears all at once. Although the total load time may be comparable, website A will probably feel faster to a user.
Speed Index helps make that difference visible. The lower the Speed Index, the faster the visible content of the page is built up. For a mobile Lighthouse test, a Speed Index up to 3.4 seconds counts as good. For desktop tests a stricter limit applies.
4. Total Blocking Time (TBT): how long can't the page respond properly?
A website can look fully loaded and still respond slowly. For example, you click a button, but nothing happens for a moment. Total Blocking Time (TBT) measures how much time the main thread is blocked during loading.
Lighthouse looks at long tasks between First Contentful Paint and Time to Interactive. A task counts as long when it takes longer than 50 milliseconds. Only the portion above those 50 milliseconds counts as blocking time.
A task of 70 milliseconds therefore yields 20 milliseconds of blocking time. Lighthouse adds up the blocking time of all long tasks to calculate the TBT.
These blocks are often caused by JavaScript. While the browser is busy with a heavy task, it cannot respond immediately to clicks, taps or keyboard input. A high TBT can therefore make a website feel slow or sluggish, even when the content is already visible.
For mobile Lighthouse tests, a TBT of at most 200 milliseconds is considered good. Within the Performance score, TBT has a lot of influence on the final result with a weighting of 30%.
5. Cumulative Layout Shift (CLS): does the page stay stable?
Know this? You want to click a button, but at exactly that moment an image appears above the button and everything shifts down. You then accidentally click something else. That is an example of a layout shift.
Cumulative Layout Shift (CLS) measures unexpected shifts of visible elements. Many or large shifts cause a restless and frustrating user experience.
According to Google, a good CLS score is 0.1 or lower. Possible causes of a poor CLS score are:
- images and videos without predefined dimensions;
- ads or embeds that take up space later;
- web fonts that visibly change size;
- content that is dynamically placed above existing content;
- third-party widgets that change size while loading.
CLS can be measured both in a controlled test environment and with real users. A lab test, however, usually only sees the shifts that occur during loading. Field data can also register shifts that occur later during the visit.
Lighthouse score and Core Web Vitals are not the same thing
This is where confusion regularly arises. A Lighthouse Performance score of 100 does not automatically mean your website performs perfectly for every user in practice.
Lighthouse runs a lab test. The page is loaded under controlled and simulated conditions and analyzed on that basis. That makes Lighthouse especially suitable for detecting technical problems and comparing different measurements with each other.
Core Web Vitals are metrics that assess the user experience around loading speed, responsiveness and visual stability. They can be investigated with lab tools, but for a representative picture Google also uses field data from real Chrome users.
The three current Core Web Vitals are:
- Largest Contentful Paint (LCP): measures loading performance;
- Interaction to Next Paint (INP): measures responsiveness during interactions;
- Cumulative Layout Shift (CLS): measures visual stability.
For a good user experience, the following guidelines apply:
- LCP: at most 2.5 seconds;
- INP: at most 200 milliseconds;
- CLS: at most 0.1.
Google assesses these values based on the 75th percentile of page views, separately for mobile devices and desktops. That way a good score must be representative of the majority of users and not only of visitors with a fast device and a fast internet connection.
Why isn't INP among the Lighthouse metrics?
Interaction to Next Paint is an important Core Web Vital, but is not a separate metric in the standard Lighthouse Performance score. That is because INP assesses responsiveness based on interactions that take place throughout the entire visit.
A standard Lighthouse test mainly analyzes the loading of a page and does not have the same set of real user interactions. Lighthouse therefore reports Total Blocking Time as a lab metric for responsiveness problems during loading.
According to Google's explanation of measuring Core Web Vitals with Google tools , TBT can help identify problems that can also negatively affect INP. Think, for example, of large amounts of JavaScript and long tasks on the main thread.
TBT and INP are not the same, however. A low TBT does not automatically guarantee a good INP. Slow interactions can also occur after the page has fully loaded. For a complete picture you therefore want to examine both lab data and real-world data.
Lighthouse versus PageSpeed Insights: what is the difference?
Lighthouse and PageSpeed Insights are regularly mixed up. Lighthouse is the underlying analysis tool for the technical lab test. Google PageSpeed Insights can combine two kinds of information:
- Field data: real-world data from the Chrome User Experience Report, also known as CrUX. This data is based on real Chrome users and covers the preceding period of 28 days.
- Lab data: a Lighthouse test under simulated conditions with which technical problems can be detected.
Field data is only available when Google has collected sufficient real-world data for a page or website. For websites with little traffic, this information may be missing or only available at domain level.
The distinction between lab and field data is important. A Lighthouse test mainly tells you which technical improvement points come to the fore during the test. Field data shows what real users with different devices, connections and conditions actually experience.
For a good picture of website performance you therefore want to look at both.
Is a Lighthouse score of 100 necessary?
No. A perfect Lighthouse score can be nice, but should not become a goal in itself.
Scores can also vary per measurement. According to Chrome for Developers, different devices, network routes, browser extensions, ads and other changing conditions can influence the outcome, among other things.
A website with a score of 95 is therefore not automatically better than a website with a score of 90. More important is that the website is fast, stable and responsive for real users and that important functionalities keep working well.
Use Lighthouse mainly as a diagnostic aid. It helps developers find technical bottlenecks, test improvements and spot regressions faster during development. Combine those insights with real-world Core Web Vitals and with observations of real users.
A fast website starts with technical choices
You don't achieve a good Lighthouse score only by compressing a few images at the end of a project. Performance is determined much earlier.
Think of choices around:
- technical architecture;
- front-end code;
- JavaScript;
- images and fonts;
- caching;
- hosting and infrastructure;
- external scripts;
- APIs;
- databases;
- the way content is loaded.
That is why at Ninjible we treat performance as part of the full development process. We look not only at a final score, but at the technical choices that determine how a website or digital platform behaves in practice.
The ultimate goal is not a green circle or a score of 100. The goal is a website or digital platform that feels fast to real users, stays stable and responds pleasantly. Lighthouse helps us make technical improvement points visible and measurable.
