Page weight and TTFB check

What the performance row looks at

The row measures three plain numbers and compares them with fixed thresholds. It reports no composite score and does not simulate a slow phone or a throttled connection.

• Time to first byte (TTFB): how long the server takes to start answering; above 800 ms it warns, above 1.8 s it fails
• Page weight: the total bytes transferred while loading; above 3 MB it warns, above 6 MB it fails
• Number of requests: above 100 it warns, above 200 it fails

Rule ids:perf_ttfbperf_weightperf_requests

Why it matters

A slow first byte delays everything that follows, because the browser cannot start on the page until it has the HTML. A heavy page costs visitors on mobile data real money and costs everyone time. A page that makes hundreds of requests spends much of its load on setup rather than content. These three numbers are not the whole picture of how fast a page feels, but they are the ones a team can act on directly.

What a fix usually looks like

The same few changes account for most improvements.

• Cache the HTML at the edge, or speed up the server response, to bring TTFB down; a static page served from a CDN is usually the quickest win
• Compress and resize images, and serve a modern format
• Drop scripts and stylesheets that nothing uses
• Enable Brotli or gzip compression for text
• Bundle scripts and defer third-party tags to cut the request count
• Re-run the check after each change, so you can see which one moved the numbers

What this check does not do

It is not a full lab report. It does not report Core Web Vitals, layout shift or interaction delay, and it measures one load from one location. Treat the numbers as a quick read on weight and server response, and use a dedicated profiler when you need to dig into rendering.