Understand PageSpeed results and slow LCP
A page can look simple and still take too long to show its main content. Start with the measured element and where the time went, then choose a change that addresses that delay.
By AEO Test · Documentation checked .
Read your results in context
AEO test displays Google’s mobile Lighthouse lab results for the scanned page. These describe a simulated visit, not every visitor’s experience. Check the analyzed URL and measurement date before comparing reports. Reopening a saved report does not measure it again.
The full PageSpeed Insights tool can also show real-user data from a trailing 28-day period. Check whether it describes this URL or the whole origin, and mobile or desktop visits. Small sites may have too little data. A missing real-user assessment is not a performance failure, and a recent fix does not immediately replace that historical window. See Google’s explanation of lab and field data.
Read the individual findings before chasing the overall score. Largest Contentful Paint (LCP) concerns when the largest visible content appears. For real visits, Google’s good LCP target is at most 2.5 seconds at the 75th percentile, considered separately for mobile and desktop. A single green lab result does not establish that your site passes Core Web Vitals. See the LCP definition and thresholds.
Total Blocking Time (TBT) points to long tasks that can delay input during loading. Unnecessary JavaScript is one common cause. It is a lab diagnostic, so use it to investigate work the browser is doing, rather than as a promise about every interaction. See Chrome’s TBT guidance.
Why can LCP be slow without a large image?
A heading or paragraph can be the largest visible content element. Removing an image does not remove the need to display text. Ask your developer to identify the LCP element in the full PageSpeed or Chrome performance report before changing assets.
If that element is text, investigate its font and styles. A font loading policy can keep text invisible while a font downloads. Consider a suitable fallback font and an appropriate font-display setting, then check whether a later font swap moves the layout. Load only the font variants the page needs. Preloading every font can compete with other resources; prioritize only after measuring. See web.dev’s font guidance.
Find where the time went
Google breaks LCP into four parts. Ask which part dominates before choosing a fix. The labels below match the optional phase evidence in AEO test’s LCP finding.
Time before the HTML begins arriving. Investigate redirects, connection time, caching and server work.
The resource is discovered or requested late. Check whether it is available in the initial HTML and whether lazy loading delays it.
The download itself takes time. Review its size, delivery and competition with other requests.
The browser has what it needs but has not displayed the element. Inspect blocking styles, script work and content that stays hidden until code runs.
Text rendered with a system font may have no separate resource load. Compressing an unrelated image will not necessarily address a render delay. These distinctions come from Google’s LCP optimization guide.
AEO test includes phase timings only when Google returns a supported breakdown. Those observed trace timings can differ from the simulated LCP value; do not add them up to reconstruct that value. Missing phase evidence means this report cannot identify the cause. We do not save Google’s element snippets or resource waterfall.
Can making the page static help?
If a headline, introduction or form label is known in advance, sending it in the initial HTML can avoid waiting for application code to create it. A mostly static landing page can still have an interactive form. Ask your developer to check that the content is visible before the JavaScript runs, not merely present inside a hidden container. Google also recommends considering server rendering or prerendering for users and crawlers.
This is a candidate change to test, not a diagnosis from the score alone. Static delivery does not guarantee fast fonts, styles or server responses. Keep useful content and test the actual loading path instead of removing information just to change the largest element.
What to send your developer
- Share the exact public URL, AEO test report link and measurement date.
- Include the LCP value and any phase evidence. Ask which element was measured and what delayed it.
- Agree on one change tied to that evidence, such as earlier visible HTML or a different font-loading policy.
- Retest the same page and device mode. Keep several runs so ordinary variation is not mistaken for an improvement.
- Check reading, layout and form behavior as well as the metric. Compare real-user data when enough new observations are available.
Use Compare saved reports to review recorded changes without spending another scan. You need a new scan to collect a fresh measurement. Your report’s action-plan download provides a text checklist you can share.
What if Performance is unavailable?
Read the recorded reason first. A Google quota, timeout or unsupported response can leave performance unavailable while other checks work. AEO test excludes unavailable measurements from scoring. Use the performance troubleshooting steps before deciding whether another scan is useful.