Your account is awaiting approval
Thanks for registering. An administrator has to approve your account before you can run tests. You'll get an email the moment it's active.
Start a new speed test
Point us at your current live site. We clone it onto ScalaHosting, then benchmark both side-by-side. Cloned sites are auto-removed within 72 hours.
How it works
Your sites
Suggest a feature
Tell us what this platform should do next. An administrator answers every request right here — you get an email when yours is answered, and you can reply to keep the conversation going.
All requests
What happens when you test a site
- You point us at your live site. That's the only required input — the URL of the site as your visitors reach it today, wherever it is hosted.
- We clone it onto ScalaHosting (optional but recommended). Using access you provide — SFTP/SSH, or simply your host's cPanel login — we copy your actual files and database into an isolated preview environment on ScalaHosting infrastructure, on its own HTTPS subdomain. With a cPanel login, cPanel produces a full account backup which we download, restore and then delete from your account. For WordPress sites, URLs are rewritten so the clone runs exactly like the original. Your connection credentials are used once, in memory, for the copy — they are never stored.
- Both sites get the identical test battery. One benchmark run tests your current host and the ScalaHosting clone back-to-back, minutes apart, with the same tools, settings and vantage point — so the only meaningful difference is the hosting underneath.
- Every run is frozen. The raw numbers of each run are stored as an immutable snapshot (we keep the last 5 runs per project), so results can't drift after the fact. You can create a public, revocable share link for any finished run — it keeps working even after the clone is removed.
- Clones clean themselves up. Cloned sites are automatically deleted after a platform-wide window (72 hours by default — the current value is shown on your Tests page), so no copy of your site lingers.
The test battery
| Test | When it runs | What it measures | Where it runs from |
|---|---|---|---|
| Head-to-head server probes (ours) | every run | TTFB, full HTML download time, HTML transfer size — 5 timed requests per site, median reported | The platform's own server — the identical vantage point for both sites |
| WP admin probe (ours) | every run, WordPress sites only | TTFB + full load of wp-login.php (median of 5) — the sign-in page bypasses page caches on most stacks, so it approximates uncached wp-admin speed. No WordPress login is used or needed | The platform's own server, same vantage point for both sites |
| Google PageSpeed Insights (Lighthouse lab) | every run · mobile + desktop | Performance score (0–100), server response time, FCP, LCP, CLS, TBT, Speed Index | Google's test infrastructure (simulated device, throttled network) |
| Chrome UX Report (field data) | every run, when Google has it | Real Chrome visitors over the trailing 28 days: LCP, INP, CLS, FCP, TTFB percentiles + pass/fail rating | Google's real-user dataset |
| GTmetrix deep test | admin-triggered | GTmetrix grade, performance & structure scores, TTFB/FCP/LCP/CLS/TBT, onload & fully-loaded times, page weight, request count + full report link | GTmetrix cloud (limited paid credits, so it's opt-in) |
| WebPageTest (private instance) | every run, once the platform's own WPT server is enabled | First-view TTFB, start render, Speed Index, LCP, CLS, TBT, load & fully-loaded, bytes, requests + full waterfall | A dedicated WebPageTest server we operate — unlimited runs, no third-party quota |
Our head-to-head probes — the headline comparison
Each site gets 5 timed HTTPS requests, 400 ms apart, sent with browser-like compression headers (gzip/brotli) and following redirects. We time two moments per request: TTFB — when the first response bytes arrive (this is dominated by the server + network, i.e. the part hosting controls), and full HTML load — when the complete HTML document has been received; we also record the compressed transfer size. We report the median of the samples (with the best run alongside) because a median ignores one-off network blips in either direction. Both sites are probed from the same machine within the same minute — no external service, no quota, and no way for either side to get a friendlier route.
Lab data — PageSpeed Insights & GTmetrix
Lab tests load the page on standardized simulated hardware and network, which makes them comparable across sites — but they are synthetic, and scores naturally wobble a few points between runs. We run PageSpeed Insights twice per site (mobile and desktop) and record the Lighthouse version with every run so results stay interpretable later.
Field data — what real visitors experienced
Where Google's Chrome UX Report has enough traffic for a URL (or its origin — we flag which), we show real-visitor percentiles for the Core Web Vitals. Two honest notes: small or new sites often have no field data at all, and a fresh clone never has field data — it has had no visitors yet. That is expected, and it is exactly why the lab tests and our same-vantage probes carry the side-by-side comparison.
How the comparison stays fair
- Same content: the clone serves your actual files and database — not a demo page tuned for benchmarks.
- Same battery, same order, same moment: every tool that tests one side tests the other, within the same run.
- Same vantage point: our probes hit both sites from the same server, eliminating geography as a variable.
- Medians, not best-of: the headline numbers are medians of repeated samples, and each run's raw samples are kept in the frozen snapshot.
- No cherry-picking: a run is stored whole — including errors and metrics where your current host wins.
Limitations we want you to know about
- Your live site is measured as-is — including any CDN or cache in front of it. That is deliberate (it's what your visitors get), but it means you are comparing stacks, not bare servers.
- Our probes run from a datacenter, not from end-user devices — treat them as a controlled relative comparison, while the field data (where present) shows real-user experience.
- Lab scores fluctuate run-to-run; look at the pattern across metrics and runs rather than a single number.
How to read the numbers
| Metric | What it means | Good (Google's thresholds) |
|---|---|---|
| TTFB — time to first byte | How fast the server starts answering; the purest hosting metric | ≤ 800 ms |
| FCP — first contentful paint | When the first text/image appears | ≤ 1.8 s |
| LCP — largest contentful paint | When the main content is visible; Core Web Vital | ≤ 2.5 s |
| CLS — cumulative layout shift | How much the page jumps around while loading; Core Web Vital | ≤ 0.1 |
| INP — interaction to next paint | How quickly the page reacts to clicks/typing (field data only); Core Web Vital | ≤ 200 ms |
| TBT — total blocking time | Lab stand-in for responsiveness: how long scripts block the page | ≤ 200 ms |
| Speed Index | How quickly the visible page fills in | lower is better |
Rule of thumb: TTFB and the head-to-head probes tell you what the hosting is doing; LCP/CLS/TBT also reflect how the site itself is built — themes, plugins, images and scripts behave the same on both sides of the comparison.
Data lifecycle & privacy
- SFTP/SSH and cPanel credentials are used in memory for the one-time copy and are never written to disk or database.
- Each clone lives in an isolated environment under its own system user, reachable only via its preview subdomain over HTTPS.
- Clones are deleted automatically after the platform window (72 h by default), or immediately when you delete the project.
- Benchmark snapshots outlive the clone so your results and share links stay intact; share links are revocable at any time.
Platform settings
When on, every cloned site is removed this many hours after it's created — platform-wide. Turn off to keep clones until manually deleted.
Users
The account is created pre-approved. The person receives an email with the sign-in address, their email and a generated password — they can change it later via “Request access” on the sign-in page.
All projects
Every user's projects (newest first) — for support and oversight.