The same page, four very different speeds
Load your own site and it feels instant. That is exactly the problem. You are sitting next to your servers, on a fast line, with every script and image already cached from yesterday. Your visitor is not. They arrive with an empty cache, from another continent, on a mid-range phone, over a mobile connection that keeps dropping packets.
Synthetic tests help, but each one runs from a single data centre with a single device profile. They show how the page behaves under one set of conditions and nothing more. They cannot tell you which of your visitors are waiting, where they are, or what they are using.
nanoseconds.io takes the other route and measures every real visit. One line of HTML, no cookies, and every page load reports its own First Contentful Paint, Largest Contentful Paint, Cumulative Layout Shift and Time To First Byte. In the dashboard you then slice those numbers the way the problem really shows up: per page, per country, per device type, per operating system and per browser.
Step 1. Check the map before you check the code
Start with the Countries view. Time To First Byte is mostly distance and server work, so a map of TTFB is a map of where your infrastructure is far from your audience. A typical pattern: green across Europe, amber in South America, red in China. If the red region matters to your business, no amount of JavaScript optimisation will fix it. You need a CDN edge or a server closer to those users. If it does not matter, stop worrying about it and move on.
Step 2. Split by device, OS and browser
Next, look at the same metrics per device type. Desktop LCP of 1.2 seconds next to mobile LCP of 4.5 seconds means the page is fine, but the images or fonts are not sized for phones. A single browser standing out, for example one older engine with a much higher CLS, usually points to a CSS feature that browser handles differently. These splits turn "the site feels slow" into "Android Chrome users on this page wait three seconds longer than everyone else", which is something an engineer can act on.
Step 3. Open the Slow Pages list
The Slow Pages view lists which URLs loaded slowly today, this week or in the past year, ranked by real visits. Paste any URL to drill in. You will see its vitals and its resource counts: images, scripts, stylesheets and webfonts per load. A page with 42 scripts and 8 webfonts explains itself. This is where most teams find their quick wins: one page with a heavy third-party embed, one template that ships an unoptimised hero image, one form that loads a full charting library it never uses.
Step 4. Fix one thing, then watch the real numbers move
Because the data comes from live traffic, the effect of a change shows up on the dashboard within hours, on the same visitors, with no re-running of tests. Pick the 24-hour or 3-day range, compare it with the previous period, and confirm the fix worked for the people it was meant for. Then repeat with the next page on the list.
What you get without the guesswork
- A country map of TTFB that tells you whether the problem is infrastructure or front-end.
- Per-device, per-OS and per-browser Web Vitals, so you optimise for the users you actually have.
- A ranked list of slow pages with resource counts, so you know where to start.
- Real-visit measurements that need no cookies and do not slow the page down themselves.
Add unlimited websites for free and start with the page your customers hit first. That is the page where the difference between your browser and theirs costs you the most.