AEO NIUEXA

Performance

10% Weight Check reference Priorities vary by result

Performance measures how fast the page loads in a Google PageSpeed lab test: one test load that Google runs from its own servers, not data from your real visitors. Speed matters for visitors and for reliable fetching; it is not an AI citation threshold.

How Performance is scored. The score is the importance-weighted average of the six checks below: Time to First Byte (weight 1.5), First Contentful Paint (1.0), Total Blocking Time (1.5), Speed Index (1.0), Critical Resource Count (0.75) and JavaScript Execution Time (1.0). Time to First Byte counts at half its listed weight because its evidence is practitioner advice that the engines have not confirmed; the other five count in full. Each check gives a score from 0 to 100, as listed under it, and a check below its pass line is listed as something to fix. Scores from other dimensions are not mixed in.
No PageSpeed data, no Performance score. When PageSpeed returns no data for a page, its speed checks are marked "Not measured" and the whole dimension is left out: the report shows "Performance: not measured (no PageSpeed data)" and the other five dimensions are re-weighted to fill its 10%. It is never scored as 0 or as a default 50. A single figure PageSpeed did not return is "Not measured" on its own and left out the same way. Critical Resource Count is read from the HTML, so on its own it never produces a Performance score; without PageSpeed data it is shown for information only.
How the figures are measured. Time to First Byte is the wait for this page's HTML that PageSpeed observed during its test load. First Contentful Paint, Total Blocking Time and Speed Index are simulated for a throttled load, and JavaScript Execution Time is measured with a throttled CPU. Because the methods differ, the LCP shown elsewhere in the same report can be lower than the Time to First Byte; that is not an error. Critical Resource Count is counted in the HTML we fetched and is not a timing. Lab figures describe a browser loading the page under test conditions; they say nothing about how AI systems process it.

Speed Metrics

PageSpeed lab metrics. Each is "Not measured" when PageSpeed has no value for it.

Time to First Byte (TTFB)

High
What it checks
How long PageSpeed's test load waited for this page's HTML after sending the request (Lighthouse "server response time"), measured once from Google's servers.
Why it matters
Nothing on the page can start before the HTML arrives, so a slow server response delays everything after it, for visitors and for crawlers.
How it is scored
100 under 200 ms, 85 under 500 ms and 70 under 800 ms: all pass. From 800 ms to 1.5 s it scores 50 and fails; above 1.5 s it loses 1 point for every further 100 ms and reaches 0 at 6.5 s. It counts at half weight (practitioner evidence).
Good: under 500 ms Passes but slow: 500-800 ms Fail: 800 ms or more Not measured: no PageSpeed value
How To Improve
Use server-side caching or a CDN, speed up slow database queries and backend code, and upgrade the hosting if it is overloaded.

First Contentful Paint (FCP)

High
What it checks
How long, in PageSpeed's simulated load, before the first text or image appears on screen.
Why it matters
It is how long visitors look at a blank screen. Google treats 1.8 seconds or less as good.
How it is scored
100 under 1.8 s and 75 under 3 s: both pass. From 3 s to 4.5 s it scores 50 and fails; above 4.5 s it loses 10 points per extra second and reaches 0 at 9.5 s.
Good: under 1.8 s Passes but slow: 1.8-3 s Fail: 3 s or more Not measured: no PageSpeed value
How To Improve
Reduce render-blocking resources, inline the critical CSS, defer non-critical JavaScript and speed up the server response.

Total Blocking Time (TBT)

High
What it checks
How long, in PageSpeed's simulated load, long-running scripts keep the page frozen and unable to respond to clicks and taps.
Why it matters
It is the lab measure that tracks how responsive the page feels while it loads. How responsive it is for real visitors is not measured here.
How it is scored
100 under 200 ms and 75 under 600 ms: both pass. From 600 ms to 1 s it scores 50 and fails; above 1 s it loses 1 point per extra 50 ms and reaches 0 at 3.5 s.
Good: under 200 ms Passes but slow: 200-600 ms Fail: 600 ms or more Not measured: no PageSpeed value
How To Improve
Break up long JavaScript tasks, defer non-essential scripts, reduce third-party code and move heavy computation to web workers.

Speed Index

High
What it checks
How quickly the visible part of the page fills in during PageSpeed's simulated load.
Why it matters
A low Speed Index means visitors see the page take shape quickly instead of waiting for it all at once.
How it is scored
100 under 3.4 s and 75 under 5.8 s: both pass. From 5.8 s to 8 s it scores 50 and fails; above 8 s it loses 5 points per extra second and reaches 0 at 18 s.
Good: under 3.4 s Passes but slow: 3.4-5.8 s Fail: 5.8 s or more Not measured: no PageSpeed value
How To Improve
Load what is visible first, lazy load images further down the page, and cut the CSS and scripts the first view has to wait for.

Resource Metrics

What the page's code asks the browser to load and run before it can be used

Critical Resource Count

High
What it checks
Counts, in the <head> of the HTML we fetched, the stylesheets (<link rel="stylesheet">, except media="print") and external scripts (<script src> without async or defer) that the browser must load before it can show the page. Inline styles and scripts are not counted.
Why it matters
Every file the browser must download before it can show the page delays the first view.
How it is scored
100 for 0-2 files and 75 for 3-5: both pass. 6-10 files score 50 and fail; above 10 it loses 5 points per extra file and reaches 0 at 20. Without PageSpeed data the count is shown for information only and not scored.
Good: 0-2 Passes: 3-5 Fail: 6 or more Information only: no PageSpeed data
How To Improve
Inline the critical CSS, add async or defer to scripts in the <head>, combine small CSS files and remove stylesheets the page does not use.

JavaScript Execution Time

High
What it checks
How long the browser spends parsing, compiling and running the page's scripts in PageSpeed's test, with a throttled CPU (Lighthouse "bootup time"). When that figure is missing or zero, the total main-thread work time is used instead.
Why it matters
Heavy scripts delay interaction, especially on slower devices, and crawlers that do not run scripts never see content that only scripts build.
How it is scored
100 under 2 s and 75 under 3.5 s: both pass. From 3.5 s to 5 s it scores 50 and fails; above 5 s it loses 10 points per extra second and reaches 0 at 10 s.
Good: under 2 s Passes but slow: 2-3.5 s Fail: 3.5 s or more Not measured: no PageSpeed value
How To Improve
Remove unused code, split large bundles, drop polyfills modern browsers do not need, and replace heavy libraries with lighter ones. Render the main content on the server if scripts build it.