Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Use Lighthouse to find page-level performance, accessibility, best-practices, and SEO issues, then inspect font loading and test accessibility with a person. A Lighthouse score is a diagnostic snapshot—not proof that a site is accessible or that every visitor sees every font correctly. For useful comparisons, keep the browser, device, throttling, and test conditions consistent.

What an automated web audit can—and cannot—tell you

Lighthouse audits an individual page and reports potential issues across performance, accessibility, best practices, and SEO. You can run it in Chrome DevTools, PageSpeed Insights, from the command line, or through Node.js. Choose the interface that fits the job: DevTools works well for a focused page review, while the CLI is suited to repeatable automated runs.

Read each failed audit as a lead to investigate, not an automatic diagnosis. Open the finding’s reference documentation, inspect the page and its implementation, and decide whether the suggested change fits your site. Automated accessibility checks can identify some programmatically detectable markup and contrast problems, but they cannot establish that keyboard and screen-reader interactions work for people.

Run a repeatable Lighthouse audit

Use Chrome DevTools for a focused page review

  1. Open the page you want to review in Chrome.
  2. Open DevTools and select the Lighthouse panel. The exact location can vary with Chrome’s interface; use the DevTools panel menu if Lighthouse is not visible.
  3. Select the device mode and audit categories relevant to the question. Lighthouse covers performance, accessibility, best practices, and SEO.
  4. Choose the available throttling and other run settings, then run the audit.
  5. Save or record the report and note the tested URL, date, browser, device mode, categories, throttling, and other material setup details.
  6. For each finding, follow its reference documentation and inspect the affected page behavior before changing code.

For the same page, avoid comparing scores from unlike setups. Chrome notes that local device load, extensions, and stored device settings influence Lighthouse results; results from different machines cannot be directly compared. If you need a trend, keep the test environment and settings as stable as possible and record any differences.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Choose the right interface for the job

Route Useful for Consideration
Chrome DevTools Interactive review of a page while you inspect it Local conditions such as extensions and device load can influence results.
PageSpeed Insights Running Lighthouse through a web interface Record the conditions and report details you need when comparing runs.
Lighthouse CLI or Node.js Flexible, repeatable automated runs Keep configuration and execution environment consistent for comparisons.
Chrome DevTools Performance panel Detailed performance debugging Chrome currently recommends this panel over Lighthouse when the task requires more performance detail. Lighthouse remains useful for its other audit categories and familiar report.

Official workflow and tool guidance: Chrome for Developers: Lighthouse: Optimize your website.

Investigate invisible text and web-font loading

A custom web font can take time to download. Some browsers may hide text while waiting for the font, producing a flash of invisible text (FOIT). When the custom font replaces a visible fallback, the change is a flash of unstyled text (FOUT). The right behavior is a design and performance tradeoff: text appearing sooner can help users, while a later font swap can still shift content.

Find the font-display insight

Inspect Lighthouse’s font-related finding and the page’s font-face declarations. In Lighthouse 13, the audit moved to the Font display insight; use the insight and its linked guidance rather than relying on older descriptions of the audit name. Verify which font files the affected text uses and whether the page’s observed loading behavior matches the issue being reported.

Chrome’s guidance describes font-display: swap, fallback, and optional as options that tell the browser to use a system font if the custom font is not ready. For example, a font-face rule can be written as:

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
@font-face {
  font-family: "Site Sans";
  src: url("/fonts/site-sans.woff2") format("woff2");
  font-display: swap;
}

This is an implementation example, not a universal setting. Confirm that the font URL and format match your site, then test the rendered result and layout. A fallback font may have different metrics, so text can reflow when the custom font arrives.

Decide whether to preload

Preloading a font alongside font-display: optional may help mitigate layout shifts in some cases, but preloading is not a blanket fix. Too many preloads can negatively affect loading metrics by competing for resources. Measure the actual page, make a focused change, and A/B test for regressions before applying it widely. Chrome’s font guidance explains the tradeoffs: Ensure text remains visible during webfont load.

Compare before and after fairly

  • Use the same page, browser, device mode, categories, and throttling for both runs.
  • Keep extensions and other local conditions consistent where possible; record unavoidable differences.
  • Inspect whether text is hidden before the font arrives, whether the fallback is legible, and whether the font swap changes layout.
  • Compare more than the score: consider the relevant loading metrics, visible content, and any regressions introduced by the change.
  • Do not treat one run as proof of behavior for every device, browser, network, or visitor.

Complete accessibility checks with human review

Automated findings are useful for detectable issues, but they do not prove that a page can be operated or understood by people using assistive technology. Chrome’s accessibility reference says keyboard and screen-reader navigation must be tried by a person.

  • Keyboard: navigate the page without a mouse. Check that interactive controls can be reached and operated, and that focus behavior makes sense.
  • Screen reader: try the page with a screen reader. Check whether content and controls are understandable in the order and manner they are presented.
  • Reflow: resize or rotate the viewport and check that content remains usable rather than relying on a desktop screenshot or score alone.
  • Automated findings: investigate reported markup and contrast issues, then verify the relevant user experience rather than assuming a clean report certifies accessibility.

See Chrome DevTools Accessibility features reference. The W3C WAI directory also lists accessibility evaluation tools, including tools that support automated, semi-automated, and manual in-browser testing; it is a directory, not a font-analysis guide: Web Accessibility Evaluation Tools List.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Troubleshoot common audit and font issues

Scores change between runs

Likely cause: differences in local device load, extensions, stored settings, throttling, or test environment. What to do: record the setup, standardize the conditions you control, and compare like with like. Do not interpret results from different machines as directly comparable.

A font audit reports a problem but text looks fine

Likely cause: the issue may appear only during loading or under conditions not obvious in a normal visit. What to do: inspect the Font display insight, the font-face declaration, and the actual loading behavior. Check whether the font is delayed and whether the fallback is visible before it arrives.

Text appears sooner, but the layout shifts

Likely cause: the fallback and custom font have different text metrics. What to do: assess the visible fallback and resulting layout, then measure possible font-display or preload changes. Avoid adding preloads indiscriminately, and test for regressions.

A clean accessibility report misses a usability problem

Likely cause: automated checks cannot verify every keyboard or screen-reader interaction. What to do: test with a keyboard and screen reader, and check viewport reflow manually.

Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Performance work needs more detail than Lighthouse provides

What to do: use Chrome DevTools’ Performance panel for detailed performance debugging. Use Lighthouse when you need its broader category coverage or familiar audit report.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Capture a page image for visual review

A screenshot can help you document a page’s visible state while reviewing a change, but it does not replace Lighthouse metrics, font-loading inspection, or hands-on accessibility checks. For repeatable comparison, capture the same URL at the same viewport and state, and note that a static image cannot show a loading sequence or prove keyboard and screen-reader behavior.

Or skip the browser setup

For a screenshot image of a page, ScreenshotNeo offers a one-request API. It accepts cookie or consent banners as a visitor would and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, with the outcome reported in response headers. It also provides an MCP server for AI agents, including Claude, Cursor, and other MCP clients.

Example cURL request for a WebP screenshot (replace the example URL with the page you want to capture):

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.
curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for setup and options. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000. Sign up for free ScreenshotNeo access.

Use screenshots as supporting evidence, not an audit result

ScreenshotNeo is a website screenshot API and MCP server from Yorker Media, not a replacement for Lighthouse or a manual accessibility review. Its screenshot options include full-page capture with lazy images loaded, element capture by CSS selector, dark mode, device presets and custom viewports, and PDF output. A captured image can help with visual documentation, but use browser auditing and human checks to evaluate performance, font behavior, and accessibility. Learn more at ScreenshotNeo.

Frequently Asked Questions

Does a Lighthouse score certify that my website is accessible?

No. It reports automated findings for the audited page and setup; keyboard, screen-reader, and reflow checks still need human review.

Is font preloading always a good idea?

No. Preloads compete for resources, so measure the specific page and test any change for regressions.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.