Google Lighthouse: The errors that the scoring doesn't show you

Imagine you've had your website live for months. The traffic is coming in, business is good, and no one is complaining. But one day you run Google Lighthouse and discover that your homepage takes 4 seconds to render the main content on mobile. That 12 elements don't meet the minimum contrast requirements. That a JavaScript library has known vulnerabilities.

None of this generates a visible error. There's no red screen or alert message. These are problems that have been there for months, affecting performance, accessibility, and security without anyone noticing.

Google Lighthouse is probably the most accessible tool for uncovering them. It's free, takes two minutes to run, and can reveal things you haven't seen in months.

What Lighthouse is (and what it isn't)

Lighthouse is an open-source tool from Google that audits websites in five categories: performance, accessibility, best practices, SEO, and Progressive Web App (PWA) compatibility. You can run it directly from Chrome DevTools, from the command line, or through PageSpeed ​​Insights.

What it does is simulate a user's visit to your page, collect loading and behavior metrics, and generate a report with a score from 0 to 100 in each category along with specific recommendations.

What it doesn't do is give you a complete picture of your website. Lighthouse analyzes one page at a time, not an entire site. It's not a substitute for a real load test, a professional security audit, or usability testing with real users. It's a starting point, not a final diagnosis.

But as a starting point, few offer so much information for so little effort.

The most common mistake: getting stuck on the score

Most people run Lighthouse, look at the four numbers at the top—90, 85, 100, 92—and close the tab. If the numbers are green, everything's fine. If any are orange, we'll look into it. If any are red, we might need to worry.

This approach wastes almost everything that Lighthouse has to offer.

The score is a summary. Below it are dozens of individual audits, each with a specific diagnosis and, in many cases, with the exact indication of the resource, element, or line of code causing the problem. It's the difference between knowing you have a fever and knowing what's causing it.

Let's see what you can find if you go beyond the number.

Performance: what your users feel but don't tell you

The performance category doesn't just measure "whether the website is fast." It measures the loading experience as perceived by a real user on a real device with a real connection.

The key metrics that Lighthouse has been evaluating since its update to version 13 are:

Largest Contentful Paint (LCP). This measures how long it takes for the largest visual element on the page to appear. If your LCP exceeds 2.5 seconds, the user perceives the website as slow to load, even though it has technically already begun rendering. Lighthouse tells you exactly which element is taking the longest and why.

Cumulative Layout Shift (CLS). This measures how much the content shifts while the page loads. Have you ever tried to click a button and the page shifted at that exact moment? That's layout shift. A high CLS is not only frustrating; it can cause a user to click where they don't intend, with real consequences for forms or checkout processes.

Interaction to Next Paint (INP). This measures how long it takes for the page to respond when the user interacts with it. A button that takes 400 milliseconds to react feels broken, even if it technically works.

The interesting thing about Lighthouse isn't that it tells you your LCP is 3.8 seconds. The interesting thing is that it tells you the problem is a 2.4 MB hero image served without lazy loading or a modern format. That's information you can actually act on.

What to look for in the performance section

Open the full report and go to the "Opportunities" and "Diagnostics" sections. There you'll find the specific problems. Some of the most common ones are:

Unoptimized images. Lighthouse detects images that could significantly reduce their size if served in WebP or AVIF format, resized to the actual display size, or loaded using lazy loading.

Render-blocking JavaScript. Scripts that load in the `<head>` section without `defer` or `async` prevent the page from rendering until they finish executing. On mobile devices with slow processors, this can add several seconds to the load time.

Heavy third-party resources. Chat widgets, analytics scripts, remarketing pixels, external web feeds. Lighthouse identifies which third-party resources are hurting your performance and how much time they add.

Accessibility: errors that exclude users

Lighthouse's accessibility audit is based on the rules of axe-core, one of the most widely used web accessibility analysis engines. It doesn't cover 100% of the WCAG (Web Content Accessibility Guidelines) criteria, but it detects the most common and easiest-to-fix problems.

And they are more common than you think.

Insufficient contrast. Light gray text on a white background might look elegant in the mockup, but if the contrast ratio doesn't meet WCAG minimums, a person with low vision won't be able to read it. Lighthouse highlights each element that doesn't comply.

Images without alt text. Any image that lacks an alt attribute is invisible to a screen reader. Lighthouse lists all the missing ones.

Forms without labels. Form fields that are not associated with a <label> are unusable with a keyboard or assistive technology. This is one of the most common and easiest errors to fix.

Broken heading order. Jumping from an H1 to an H4 without going through H2 and H3 is not only bad for SEO: it breaks navigation for users who use screen readers to move around the page structure.

Interactive elements that are too small. Buttons or links with a touch area smaller than 48x48 pixels are difficult to tap on touchscreens. This isn't just a problem for people with motor disabilities; it affects anyone who uses a mobile phone.

Each of these problems represents a user who cannot complete an action on your website. Depending on your industry and market, it can also be a legal issue: web accessibility regulations are becoming increasingly strict in the EU.

Best practices: security and invisible errors

The "Best Practices" category receives the least attention and, paradoxically, contains some of the most critical findings.

Mixed content. Your website is served over HTTPS, but some resources—an image, a script, a font—are loaded over HTTP. This not only generates a warning in the browser, but it can also prevent the resource from loading at all in strict browsers, exposing your users to man-in-the-middle attacks.

Browser console errors. Lighthouse reports any JavaScript errors logged in the console during loading. These errors can indicate broken functionality that has gone undetected because it's not immediately visible: a form that fails to validate, an event that doesn't fire, or a component that silently crashes.

Libraries with known vulnerabilities. If your website uses a version of jQuery, Lodash, or another library with documented security vulnerabilities, Lighthouse detects it. It doesn't tell you that your website has been hacked, but it does warn you that you're using a dependency with known security holes.

Geolocation permissions or notifications on page load. If your website requests location access or permission to send notifications immediately upon loading, before the user has even interacted, Lighthouse flags it as a bad practice. And they're right: it's one of the fastest ways for a user to close the tab.

SEO: What Google Can't Read

Lighthouse's SEO audit is not a substitute for a ranking analysis tool. It doesn't tell you which keywords you rank for or what your backlink profile looks like. What it does is verify that your website doesn't have technical errors that prevent search engines from indexing and understanding it correctly.

Missing meta tags. Pages without a title, without a meta description, or with duplicate meta descriptions. It's basic, but it remains one of the most frequent errors, especially on dynamic websites where meta tags are generated automatically and no one checks the result.

A robots.txt file that blocks resources. If your robots.txt file is preventing Google from accessing critical CSS or JavaScript, the search engine cannot render your page correctly and may misinterpret it.

Links without descriptive text. Links that say "click here" or "read more" without context. This isn't just bad for SEO: a user with a screen reader browsing the page's list of links will only see "click here" repeated ten times.

Viewport not configured. Without the `<meta name="viewport">` tag, your website won't adapt properly to mobile devices. Google prioritizes mobile experience in its indexing, and a website without a configured viewport starts at a disadvantage.

How to get the most out of Google Lighthouse

Running Lighthouse once and looking at the numbers isn't very useful. To really get the most out of it, you need to change your approach.

Audit the pages that matter, not just the homepage

The homepage is usually the most optimized because it's the one everyone looks at. But your product pages, contact form, checkout process, and campaign landing pages are what generate business. Audit them.

Run in mobile mode

Lighthouse has two modes: desktop and mobile. Mobile mode simulates a Moto G Power device with a slow 4G connection. It's more demanding, but more representative of how most users access the internet. If your performance is good in mobile mode, it will be excellent in desktop mode.

Prioritize by impact, not by score

A contrast error in decorative text matters less than a contrast error on the "Buy" button. Lighthouse doesn't know which is more important to your business. You do.

Automate audits

Lighthouse can be run from the command line and integrates with CI/CD pipelines. This allows you to detect performance or accessibility issues before they reach production. If a deployment causes the LCP to increase from 2 to 4 seconds, you'll know before your users experience the consequences.

Don't chase 100

A score of 100 in all categories is possible on a static page without JavaScript. However, in a real digital product with analytics, chat, and dynamic content, a score of 100 is neither realistic nor necessary. What matters is that there are no critical errors and that the metrics are within the recommended thresholds.

What Lighthouse Doesn't See

Lighthouse is an automated auditing tool, and as such, it has limitations. It doesn't detect business logic errors, doesn't test complete user flows, doesn't evaluate content quality, and isn't a substitute for actual usability testing.

It also doesn't measure performance under real-world load. Lighthouse simulates a single user under controlled conditions. If you need to know how your website performs with 500 simultaneous users, you need load testing tools.

But within its scope, the ratio between the cost of running it—free, two minutes—and what it can reveal is hard to beat. A single Lighthouse report can uncover accessibility issues that exclude users, security problems that expose data, and performance bottlenecks that are costing conversions.

The tool is there. The question is whether you use it to see a number or to find out what that number hides.