Website Speed Test — real-browser load times and Core Web Vitals

A real visit, timed by the browser itself

This speed test loads your page in a real browser on Monity's servers — the same engine that runs Monity's website monitoring — at a desktop window size, and reads the timings the browser records for that visit: when the first content appeared, when the largest element finished painting, how long the server took to answer, how many requests the page made and how many bytes they weighed. Largest contentful paint is frozen before anything scrolls the page, so it describes the visit a reader would have had rather than our own scrolling.

At the same time, the test asks Google's PageSpeed Insights for field data: how real Chrome users experienced the page over the last 28 days. The two sit side by side, clearly labelled, because they answer different questions — and seeing both is the quickest way to tell a slow server from a slow page.

The metrics, and what "good" means

• Largest Contentful Paint (LCP) — when the biggest image or text block above the fold finished rendering. Good at 2.5 s or less, poor above 4 s. A Core Web Vital.
• Interaction to Next Paint (INP) — how quickly the page responds to taps, clicks and typing. Good at 200 ms or less, poor above 500 ms. A Core Web Vital that only field data can measure.
• Cumulative Layout Shift (CLS) — how much the layout jumps while loading. Good at 0.1 or less, poor above 0.25. A Core Web Vital; on this test it comes from Google's field data, because the browser our checks run in does not report it.
• First Contentful Paint (FCP) — when anything first appeared. Good at 1.8 s or less, poor above 3 s.
• Server response (time to first byte) — from the start of navigation, redirects included, until the first byte of HTML arrived. Good at 0.8 s or less, poor above 1.8 s.
• Page weight and requests — what the visit transferred and how many requests it took, with the slowest files listed by name.

Lab data, field data and why they disagree

There are three kinds of number on a page like this, and each is right about something different. Our visit is one real page load from a data centre on a fast connection: the best tool for spotting a slow server, a heavy hero image or a render-blocking script, and for comparing a page with itself over time. Lighthouse, the lab score in PageSpeed Insights, simulates a mid-range phone on a throttled mobile network, so it is usually harsher. Field data from the Chrome UX Report is weeks of real visits on real devices, reported at the 75th percentile — the number Google uses for its page experience signals.

When the three disagree, read them together. A good lab result with poor field data usually means your visitors' devices or networks are slower than ours, or that heavy content appears after interaction. Poor results everywhere point at the page itself. And when Google has no field data — a page or site without enough Chrome traffic — our real visit is still a measurement you can act on and track.

What the speed score means

The speed score is Monity's summary of this visit, built from Google's published thresholds: largest contentful paint weighs 35%, first contentful paint and layout shift 20% each, server response 15% and full page load 10%. Each metric scores 100 at the "good" boundary and 50 at the "poor" one; metrics that could not be measured are left out of the average rather than counted as zero. Delivery problems found on the page — uncompressed HTML or scripts, render-blocking files in the <head> — then take points off, so a page cannot score 100 above a list of things to fix. It is not a Lighthouse score and is not meant to match one.

Common fixes

Slow largest contentful paint

Find the largest element above the fold — usually a hero image or headline. Serve the image at the size it is displayed, in a modern format, and do not lazy-load it; give it fetchpriority="high" if it is discovered late. If it is text, check whether a web font or a render-blocking stylesheet is holding it back.

Slow server response

Cache whole pages where you can, remove redirect hops (http to https to www costs a round trip each), and put a CDN in front of the origin. If only uncached, personalised pages are slow, the time is being spent in your application or database.

Heavy pages and slow files

Check the slowest-resources table: large images, unminified or uncompressed scripts and third-party tags are the usual suspects. Turn on Brotli or gzip for HTML, CSS and JavaScript, and defer scripts that are not needed for the first paint.

Layout shift

Give images, embeds and ad slots explicit dimensions, and avoid inserting banners above content that has already rendered — cookie notices and promo bars are frequent culprits.

Know when the page gets slower

Speed rarely collapses in one go; it erodes with a new tag here and a larger image there. Monity measures the page on every check and, by default, alerts you in Slack, Teams or email when largest contentful paint stays above 2.5 s for two checks in a row or the speed score drops by more than 10 points — and you can add your own limits for server response, page weight or request count.

Related free checks: the SEO audit reviews render-blocking resources and compression alongside on-page SEO, the accessibility checker tests the same page against WCAG, and the full-page screenshot tool shows the whole page as our browser rendered it.