Audit results help you understand how a tested page performs and which improvements can have the biggest effect on user experience.

Use this guide to read a Lighthouse-based performance report, understand the main metrics, and decide what to fix first.

A performance audit is not just a score. It is a snapshot of how a page loads under specific test conditions. To make good decisions, review the metrics, opportunities, diagnostics, and cache behavior together.

When to use this guide

Use this guide when you want to:

  • Understand the results of a performance audit
  • Read a Lighthouse report without guessing what each metric means
  • Prioritize performance recommendations
  • Compare audit results before and after optimization
  • Understand whether an issue is related to caching, assets, layout, or JavaScript
  • Decide which EDGE dashboard screen or related guide to use next

If you have not run an audit yet, start with Running a performance audit.

What a Lighthouse report shows

A Lighthouse report gives you a structured view of page performance.

It usually includes:

  • An overall performance score
  • Core Web Vitals and related loading metrics
  • Opportunities for improvement
  • Diagnostics
  • Passed audits
  • Network and request information
  • Page weight and resource breakdown
  • Recommendations for images, CSS, JavaScript, fonts, and caching

Use the report to identify patterns. Do not treat one score as the full performance story.

Important: Lighthouse results are based on a controlled test. Real visitors may experience different results depending on device, network, location, browser cache, and whether they are logged in.

Start with the overall score, but do not stop there

The performance score gives you a quick summary of the audit result.

A higher score usually means the tested page performed better under the audit conditions. A lower score means one or more metrics need attention.

Use the score as a starting point, then review the metrics that caused the score.

The same score can come from different problems. One page may score poorly because the main image loads too slowly. Another may score poorly because JavaScript blocks interaction. Another may have layout shifts caused by missing image dimensions or late-loading content.

Review the main metrics

Start by reviewing the key metrics in the report.

Largest Contentful Paint

Largest Contentful Paint, or LCP, measures how long it takes for the largest visible content element to appear in the viewport.

The LCP element is often:

  • A hero image
  • A featured image
  • A large heading
  • A banner
  • A product image
  • A large content block

If LCP is poor, check:

  • Whether the LCP element is an oversized image
  • Whether the image is compressed
  • Whether WebP or AVIF output is available
  • Whether the request is served from cache
  • Whether CSS or JavaScript delays rendering
  • Whether the origin response is slow
  • Whether the image is being lazy-loaded when it should load early

Related docs:

Interaction to Next Paint

Interaction to Next Paint, or INP, measures how responsive a page feels when users interact with it.

If INP is poor, the page may feel delayed when users click, tap, type, or interact with menus and controls.

Common causes include:

  • Heavy JavaScript
  • Long main-thread tasks
  • Too many third-party scripts
  • Page builders loading large script bundles
  • Tracking scripts
  • Complex front-end interactions
  • Unoptimized plugin assets

If INP is poor, review JavaScript size, execution time, and third-party scripts.

Related docs:

Cumulative Layout Shift

Cumulative Layout Shift, or CLS, measures visual stability.

A poor CLS score means elements move unexpectedly while the page loads.

Common causes include:

  • Images without fixed dimensions
  • Ads or embeds loading late
  • Fonts changing after load
  • Banners inserted above existing content
  • Cookie notices or popups shifting layout
  • Sliders or dynamic blocks changing size

If CLS is poor, look for elements that move during loading and reserve space for them.

First Contentful Paint

First Contentful Paint, or FCP, measures when the browser first renders visible content.

If FCP is slow, the page may be blocked before anything useful appears.

Common causes include:

  • Slow server or edge response
  • Render-blocking CSS
  • Large CSS files
  • Heavy JavaScript
  • Slow font loading
  • Too many early requests

If FCP is slow, check both server response and front-end blocking resources.

Time to First Byte

Time to First Byte, or TTFB, measures how long it takes for the first byte of the response to arrive.

If TTFB is high, check whether the request was served from EDGE cache.

A cached response should usually be faster than an uncached response that must reach the origin.

If TTFB is high, review:

  • Cache HIT, MISS, or BYPASS behavior
  • Cache exclusions
  • Origin response time
  • Traffic spikes
  • WordPress backend performance
  • Whether the tested request is logged-in or logged-out

Related docs:

Speed Index

Speed Index estimates how quickly visible parts of the page are displayed.

If Speed Index is poor, the page may appear visually slow even if some individual metrics look acceptable.

Common causes include:

  • Large above-the-fold images
  • Render-blocking CSS
  • Slow font loading
  • Heavy JavaScript
  • Too many third-party resources
  • Slow initial response

Use Speed Index as a visual loading signal, then review the detailed opportunities and waterfall.

Review opportunities

The Opportunities section suggests improvements that may reduce load time or page weight.

Common opportunities include:

  • Properly size images
  • Serve images in next-gen formats
  • Defer unused JavaScript
  • Remove unused CSS
  • Eliminate render-blocking resources
  • Reduce unused JavaScript
  • Minify CSS
  • Minify JavaScript
  • Use efficient cache lifetimes
  • Reduce third-party impact
  • Avoid enormous network payloads

Treat opportunities as investigation prompts, not automatic instructions.

Some recommendations may require theme changes, plugin changes, exclusions, or careful testing before applying them to a live site.

Review diagnostics

The Diagnostics section gives more technical context about what happened during the audit.

Diagnostics may point to:

  • Main-thread work
  • JavaScript execution time
  • Long tasks
  • DOM size
  • Request chains
  • Font loading behavior
  • Image dimensions
  • Layout shifts
  • Third-party scripts
  • Cache policy issues

Diagnostics help you understand why a metric is poor.

For example, a poor INP-related result may be connected to long JavaScript tasks. A poor LCP result may be connected to a large hero image or slow initial response.

Check the waterfall or request list

The request waterfall shows how the page loaded each file.

Use it to identify:

  • Slow first document response
  • Large images
  • Render-blocking CSS
  • Heavy JavaScript files
  • Third-party scripts
  • Fonts loading late
  • Requests that start too late
  • Long chains of dependent resources

If the first HTML request is slow, check cache behavior and origin response.

If the first response is fast but the page still loads slowly, the problem is more likely related to front-end assets, JavaScript, images, fonts, or third-party scripts.

Compare cache behavior with audit results

Audit results should be reviewed together with EDGE cache behavior.

A page may perform differently depending on whether the request is a cache HIT, MISS, or BYPASS.

Check Cache Analytics and, when needed, inspect HTTP headers.

The X-Cache header can help confirm whether the response was served from cache.

Use this interpretation:

  • HIT – EDGE served the response from cache.
  • MISS – EDGE requested the response from origin because a valid cached response was not available.
  • BYPASS – EDGE intentionally did not cache the request.

If an audit result looks worse than expected, confirm whether the test ran against a warm cached page or an uncached response.

Understand cold cache and warm cache

A cold cache means EDGE does not yet have a valid cached response for the request.

A warm cache means EDGE already has a valid cached response and can serve it directly.

The first test after a purge may show a MISS. A repeated test may show a HIT if the response is eligible for caching.

When comparing before-and-after results, avoid comparing a cold-cache test with a warm-cache test unless that is the specific behavior you want to measure.

For caching context, see How EDGE caching works.

Prioritize fixes by impact

Do not try to fix every recommendation at once.

Start with issues that affect the largest number of visitors or the most important pages.

Recommended priority order:

  1. Fix server or cache issues affecting TTFB.
  2. Fix the LCP element on key pages.
  3. Reduce large images and page weight.
  4. Reduce render-blocking CSS and heavy JavaScript.
  5. Investigate third-party scripts.
  6. Fix layout shifts.
  7. Review lower-impact diagnostics after the main issues are resolved.

Focus first on the homepage, landing pages, product pages, checkout flows, and high-traffic URLs.

How to read image recommendations

Image-related recommendations usually mean the page transfers more image data than needed.

Common image recommendations include:

  • Serve images in next-gen formats
  • Properly size images
  • Efficiently encode images
  • Defer offscreen images
  • Avoid enormous network payloads

Use image optimization when images are too large, using older formats, or not compressed enough.

Related docs:

How to read CSS and JavaScript recommendations

CSS and JavaScript recommendations usually mean the browser is spending too much time downloading, parsing, or executing front-end assets.

Common recommendations include:

  • Minify CSS
  • Minify JavaScript
  • Reduce unused CSS
  • Reduce unused JavaScript
  • Eliminate render-blocking resources
  • Reduce main-thread work
  • Reduce JavaScript execution time
  • Avoid long main-thread tasks

Start with safer optimizations such as minification. Treat concatenation carefully because it can affect load order or script behavior.

Related docs:

How to read caching recommendations

Caching recommendations usually point to resources that could be reused more efficiently.

Review caching recommendations together with:

  • EDGE cache behavior
  • Browser caching settings
  • Cache rules
  • Cache exclusions
  • The type of resource being tested
  • Whether the request is public or user-specific

Do not force caching on private, dynamic, or session-specific pages just to satisfy a report recommendation.

Related docs:

How to compare two audit reports

When comparing reports, keep the test conditions as consistent as possible.

Compare:

  • Same URL
  • Same device type
  • Same test location, if available
  • Same logged-in or logged-out state
  • Same cache state, where possible
  • Same tool
  • Similar time period

Then review:

  • Did TTFB improve?
  • Did LCP improve?
  • Did page weight decrease?
  • Did request count decrease?
  • Did JavaScript execution time decrease?
  • Did CLS improve?
  • Did cache behavior change?
  • Did any new issue appear?

A better score is useful, but the goal is better real user experience on important pages.

Common questions

Is the Lighthouse score the most important result?

No. The score is useful, but the individual metrics and recommendations matter more.

Use the score as a summary, then review the metrics that caused it.

Why did my score change without any site changes?

Audit results can vary because of test conditions, network differences, cache state, third-party scripts, and background activity.

Run more than one test and compare the pattern.

Why is the first audit slower than the second?

The first audit may warm the cache.

If the first request was a MISS and the second was a HIT, the second test can be faster.

Should I fix every Lighthouse recommendation?

No. Prioritize recommendations that affect key pages, important metrics, and real user experience.

Some recommendations may have low impact or require changes that are not worth the risk.

Can EDGE fix all Lighthouse issues?

No. EDGE can improve caching, response time, delivery, and origin load, but front-end issues may still need work.

Images, JavaScript, CSS, fonts, layout shifts, and third-party scripts can still affect audit results.

Common issues and solutions

The audit shows high TTFB

Check whether the request was a cache HIT, MISS, or BYPASS.

If the page is public and should be cacheable, review cache rules and exclusions. If the page is uncached by design, investigate origin performance.

The audit shows poor LCP

Identify the LCP element.

If it is an image, review image size, compression, format, and loading behavior. If it is text or layout-based, review CSS, fonts, and render-blocking resources.

The audit shows too much JavaScript

Review active plugins, theme scripts, page builder assets, and third-party scripts.

Consider minification and exclusions through the Performance Plugin, then test important interactions.

The audit shows layout shifts

Look for images, embeds, ads, banners, fonts, or dynamic elements that change size after loading.

Reserve space for these elements and test the page again.

The audit looks good, but users still report slowness

Check real traffic patterns, logged-in behavior, geographic location, device type, and third-party services.

Use Traffic Analytics and Cache Analytics to compare the audit result with live behavior.

Best practices

  • Test the same URL more than once.
  • Keep test conditions consistent when comparing results.
  • Record baseline results before major changes.
  • Review metrics, not only the score.
  • Check cache behavior alongside audit results.
  • Prioritize key pages and conversion paths.
  • Fix high-impact issues first.
  • Change one optimization area at a time.
  • Re-test after each major change.
  • Keep notes of what changed between audits.

Need help?

If audit results are unclear or performance remains poor after optimization, contact Support and include:

  • Site URL
  • Tested URL
  • Audit date and time
  • Screenshot or link to the audit result
  • Device type used in the test
  • Whether the test was logged-in or logged-out
  • X-Cache header value, if available
  • Recent plugin, theme, cache, image, or DNS changes
  • Relevant screenshots from Cache Analytics, Traffic Analytics, or Site Audit Details

Where to go next