All websites should be protected with HTTPS, even ones that don't handle sensitive data. HTTPS prevents intruders from tampering with or passively listening in on the communications between your site and your users. Lighthouse flags any pages that aren't on HTTPS:
How this audit fails
Lighthouse waits for an event from the Chrome Debugger Protocol indicating that the page is running on a secure connection. If the event is not heard within 10 seconds, the audit fails.
Each PWA audit is weighted equally in the Lighthouse PWA Score, with the exception of three manual audits: Site works cross-browser, Page transitions don't feel like they block on the network, Each page has a URL. Learn more in The Progressive Web App score.
If you're running your own servers and need a cheap and easy way to generate certificates, check out Let's Encrypt. For more help on enabling HTTPS on your servers, see the following set of docs: Encrypting data in transit.
If your page is already running on HTTPS but you're failing this audit, then you may have problems with mixed content. Mixed content is when a secure site requests an unprotected (HTTP) resource. Check out the following doc on the Chrome DevTools Security panel to learn how to debug these situations: Understand security issues.
Why all sites should be on HTTPS
HTTPS is a prerequisite for many new, powerful web platform features, such as taking pictures or recording audio.
By definition, an app cannot qualify as a progressive web app if it does not run on HTTPS. This is because many core progressive web app technologies, such as service workers, require HTTPS.
For more information on why all sites should be protected with HTTPS, see Why You Should Always Use HTTPS.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.