> [!CAUTION]
> **Caution:** PWA testing in Lighthouse is deprecated. For more information on its deprecation see [Chrome's updated Installability Criteria](https://developer.chrome.com/blog/update-install-criteria.md.txt). For guidance on testing, refer to the [PWA documentation.](https://developer.chrome.com/docs/devtools/progressive-web-apps.md.txt)

Many users of your page visit on a slow cellular network connection.
Making your page load quickly on a mobile network
helps to ensure a positive experience for your mobile users.

> [!NOTE]
> **Note:** A fast page load on a mobile network is a baseline requirement for a site to be considered a Progressive Web App. See the [Core Progressive Web App checklist](https://web.dev/pwa-checklist#core).

## How the Lighthouse page load speed audit fails

[Lighthouse](https://developer.chrome.com/docs/lighthouse/overview.md.txt)
flags pages that don't load fast enough on mobile:
![Lighthouse audit showing page doesn't load fast enough on mobile](https://developer.chrome.com/static/docs/lighthouse/pwa/load-fast-enough-for-pwa/image/lighthouse-audit-showing-9a93a82df94ee.png)

Two main metrics affect how users perceive load time:

- [First Meaningful Paint (FMP)](https://developer.chrome.com/docs/lighthouse/performance/first-meaningful-paint.md.txt), which measures when the primary content of the page appears visually complete
- [Time to Interactive (TTI)](https://web.dev/articles/tti), which measures when the page is fully interactive

For example, if a page appears visually complete after 1 second,
but the user can't interact with it for 10 seconds,
users will likely perceive the page load time as 10 seconds.

Lighthouse computes what the TTI would be on a slow 4G network connection.
If the time to interactive is more than 10 seconds, the audit fails.

> [!NOTE]
> **Note:** In the Lighthouse report UI the full PWA badge is given when you pass all of the audits in all of the PWA subcategories (**Fast and reliable** , **Installable** , and **PWA optimized**).

## How to improve your overall Performance score

Unless you have a specific reason for focusing on a particular metric, it's
usually better to focus on improving your overall Performance score.

Use the **Diagnostics** section of your Lighthouse report to determine which improvements will have the most value for your page. The more significant the opportunity, the greater the effect it will have on your Performance score. For example, the following Lighthouse screenshot shows that [eliminating render-blocking resources](https://developer.chrome.com/docs/lighthouse/performance/render-blocking-resources.md.txt) will yield the biggest improvement:
![Lighthouse: Diagnostics section showing a number of audits and their impact](https://developer.chrome.com/static/docs/lighthouse/images/lighthouse-diagnostics.png) Lighthouse: Diagnostics section

See the [Performance audits](https://developer.chrome.com/docs/lighthouse/performance)
to learn how to address the opportunities identified in your Lighthouse report.

## Resources

- [Source code for **Page load is not fast enough on mobile networks** audit](https://github.com/GoogleChrome/lighthouse/blob/master/lighthouse-core/audits/load-fast-enough-for-pwa.js)
- [Baseline Progressive Web App Checklist](https://web.dev/pwa-checklist#core)
- [Critical Rendering Path](https://web.dev/articles/critical-rendering-path)
- [Get Started With Analyzing Runtime Performance](https://developer.chrome.com/docs/devtools/evaluate-performance)
- [Record load performance](https://developer.chrome.com/docs/devtools/evaluate-performance/reference#record-load)
- [Optimizing Content Efficiency](https://web.dev/articles/performance-optimizing-content-efficiency)
- [Rendering Performance](https://web.dev/articles/rendering-performance)