Metrics

Why these metrics matter

turbometrics does not only show a score, but the metrics behind it. It is exactly these values that help you spot real causes instead of just judging a result.

The most important metrics show up again in the scan report, in comparisons and in part also in alerts.

TTFB

Time to First Byte shows how quickly the server responds to the first request.

High TTFB values often point to:

• slow hosting
• slow backend logic
• caching problems
• external dependencies ahead of the response

A good TTFB does not solve every problem, but a poor TTFB slows down almost everything that follows.

Reference values (turbometrics scan assessment):

These thresholds refer to the internal scan assessment. Google's CrUX reference values (≤ 800 ms / ≤ 1,800 ms) are aimed at real user data and deliberately differ from them – both are documented further down this page.

FCP

First Contentful Paint shows when visible content first appears. It matters for the first impression while loading.

Reference values (turbometrics scan assessment):

A late FCP can mean that:

• CSS or JS is blocking early rendering
• the server responds late
• large resources are loaded ahead of visible content

LCP

Largest Contentful Paint measures when the most important visible main content has loaded. LCP is especially important in the product, because it is closely tied to the perceived loading experience.

A poor LCP is often caused by:

• large images
• heavy above-the-fold content
• a slow server response
• blocking resources

TBT

Total Blocking Time measures how long the browser main thread was blocked while the page was rendering. Blocked means: JavaScript runs for so long that the browser can neither respond to input nor update the screen.

TBT is made up of the blocking portions of all long tasks – that is, the time each one spends beyond 50 ms.

Reference values:

High TBT values usually point to:

• heavy or poorly loaded JavaScript
• third-party scripts (tracking, chat, consent)
• missing prioritisation when loading scripts

CLS

Cumulative Layout Shift shows whether content jumps while loading. A low CLS matters for a stable user experience.

A poor CLS is often caused by:

• images without fixed dimensions
• fonts or banners that shift the layout afterwards
• components that are displayed dynamically

Requests and data volume

Besides runtime values, the structure and weight of the page matter too:

• many requests add coordination and loading overhead
• large data volumes slow down mobile connections in particular
• large fonts, images and scripts often show up again among the biggest slowdowns

Resource breakdown

In the developer tab, turbometrics shows a breakdown of the loaded resources by type:

The breakdown is based on browser runtime data. If JS data is not available (e.g. for cached resources), the static analysis value is used and marked accordingly.

Long tasks

Long tasks are tasks that block the browser main thread for longer than 50 ms. The blocking time is the portion beyond 50 ms – this time feeds directly into TBT.

turbometrics shows for each long task:

• the start time (measured from page load)
• the total duration
• the blocking time (colour-coded by severity)
• the likely cause (script URL, as far as it can be determined)

The likely cause is determined by overlap with the resource timings and is an approximation, not a proven fact.

DOM size

The number of all DOM elements on the page. From around 1,500 elements onwards, the browser becomes noticeably slower at rendering and at JavaScript operations.

Reference values:

A typical cause: page builders such as Elementor or Divi often produce a great many nested wrapper elements.

Blocking scripts

The number of external JavaScript files that are included without async or defer. These scripts block the browser while it parses the HTML, until they have been fully loaded and executed.

Reference values:

The affected script URLs are listed in the report.

Images without explicit dimensions

Images without width and height attributes can cause layout shifts while loading (CLS), because the browser cannot reserve space for them.

turbometrics shows the number of affected images as well as the total number of images detected on the page.

Browser runtime

turbometrics looks not only at static preflight data, but also at the browser runtime. That gives you a better view of what actually happens while the page renders.

This matters for:

• differences between mobile and desktop
• third parties that stand out
• late runtime requests
• heavy front-end JavaScript

Reading metrics correctly

No metric stands on its own. Good interpretation combines:

• the measured value
• the score breakdown
• the biggest slowdowns
• problems and recommendations
• the history or the baseline

That turns a number into a usable technical assessment.

Real user data (CrUX)

In addition to its own measurements, turbometrics shows – where available – CrUX data (Chrome User Experience Report). This is anonymised field data that Google aggregates from real Chrome sessions.

What CrUX measures:

Important limitations:

• Only Chrome users are included – Firefox, Safari and other browsers are not covered
• The data covers the last 28 days and updates weekly
• Desktop data requires a minimum number of Chrome users on that domain – if there is not enough data, no desktop value is shown
• CrUX data reflects real user behaviour, not a lab measurement – depending on the audience, region and device, it can differ considerably from your own scan values

Reference values (according to Google):

CrUX data complements your own scan values – it shows how the page performs for real users, not just in the lab.

Further reading

→ Technical signals in the developer tab → Scoring & methodology → Problems & recommendations → Baselines & comparison