Lighthouse Best Practices: Console Errors and Old APIs
Lighthouse’s Best Practices category is a list of hygiene checks for modern web pages: is the page served over HTTPS, does it load without errors, does it avoid browser features that are being removed, and does it treat visitors politely. Each audit is pass/fail, and the category score is the weighted share that pass.
None of these audits is a direct ranking factor. They matter because each one usually points at something real: a script that fails, a feature that will break in a future browser, or a prompt that makes people leave.
The audits we show separately
Console errors. Lighthouse records everything logged as an error in the browser console while the page loads: failed network requests (404s for scripts, images or fonts), uncaught JavaScript exceptions, and blocked requests. Each one is often a feature that silently does not work.
To fix: open the page, open DevTools (F12), go to the Console tab and reload. Work through the red entries. Remove references to files that no longer exist, update or remove plugins that throw, and check that third-party scripts are still needed.
Deprecated APIs. The page uses browser features that are scheduled for removal, such as
synchronous XMLHttpRequest on the main thread or unload event handlers. They work today and
break later. Most come from old libraries and plugins, not your own code. Lighthouse names the
source file; update that library or plugin to a current version.
Chrome DevTools issues. Chrome’s Issues panel collects problems the browser detected while
loading: mixed content it blocked, cookies rejected because of missing SameSite or Secure
attributes, CORS failures and Content Security Policy violations. Open DevTools, go to the Issues
tab and reload; each entry explains the problem and links to documentation.
UX blockers. We combine three audits:
- Paste blocked in inputs. Preventing paste, usually on password or confirmation fields,
breaks password managers and pushes people towards weaker passwords. Remove the
pasteevent handlers oronpaste="return false"attributes. - Geolocation requested on load.
- Notification permission requested on load.
Permission prompts that appear before the visitor has done anything are usually dismissed or denied, and browsers may start hiding prompts from sites that are often declined. Ask only after a user action that needs the permission:
document.querySelector('#find-stores').addEventListener('click', () => {
navigator.geolocation.getCurrentPosition(showNearestStores);
});
In WordPress, push-notification and “store locator” plugins are the usual source; check their settings for an option to prompt on click instead of on load.
Other audits in the category
The score also includes audits covered by other checks in our report, such as HTTPS, image aspect ratio and resolution (see responsive images), third-party cookies (see third-party cookies), the doctype and the character set. Fixing those raises this score too.
How PerfoMetrix checks this
We read the Best Practices category score and the individual audits (errors-in-console,
deprecations, inspector-issues, paste-preventing-inputs, geolocation-on-start,
notification-on-start) from the PageSpeed Insights run the scan already makes. Google loads the
page once in a mobile lab browser; we send no extra requests to your site.
| Check | Pass | Needs attention | Fail |
|---|---|---|---|
| Best Practices score | 90–100 | 50–89 | below 50 |
| Each individual audit | Lighthouse passes it | Lighthouse flags items | n/a |
The report lists the first few items Lighthouse found for each audit. Because the run happens in Google’s lab, an error that only appears for logged-in visitors or after interaction will not show up here; check those in your own browser.
Further reading: Lighthouse Best Practices audits and Permission UX on web.dev.