Real Numbers From Sites We Run: Hostinger vs Hetzner vs AWS vs Cloudflare (September 2026)

Why we're publishing this

Most "which host is faster" content on the web is either a paid comparison, a single cherry-picked screenshot, or a synthetic benchmark run once on a trial account. We wanted to publish something different: what our own sites actually measure like, today, with the raw numbers attached, including the runs that don't flatter any particular host. We're not claiming this proves Host A beats Host B — see the caveats section for exactly what a 10-site, mixed-stack, single-day sample can and can't tell you.

The sites we measured

Host identity was verified with dig for the resolved IP, WHOIS/ASN lookup (via ipinfo.io), and — where available — reverse DNS. The Hostinger Cloud VPS resolves to hostname srv719345.hstgr.cloud, AS47583 Hostinger International Limited, Boston MA. Hetzner resolves to static.176.59.180.157.clients.your-server.de, AS24940 Hetzner Online GmbH, Helsinki FI. race-planner.com serves server: AmazonS3 with x-cache: Hit from cloudfront headers directly. The two Cloudflare Workers sites were confirmed uncached at measurement time via cf-cache-status: BYPASS / x-vinext-cache: BYPASS response headers, not served from edge cache.

Methodology

Dates: All measurements taken September 28, 2026, within a roughly 90-minute window (08:40–09:46 UTC) plus a separate curl pass, to keep conditions comparable across sites.

Tool 1 — Google PageSpeed Insights API (pagespeedonline/v5/runPagespeed), mobile strategy, performance category, 3 runs per site with a short pause between runs. This is a lab metric under Lighthouse's simulated mid-tier mobile device and throttled network — it is not the same as a real visitor's experience, and it is not Chrome UX Report (CrUX) field data. PSI returned real CrUX field data (28-day rolling Chrome telemetry) for 3 of our 10 sites — primetimeanime.com (overall "Average"), chattoanyone.com (overall "Fast"), and visualsentinel.com (overall "Average") — and no field data for the other 7, which don't have enough real-world Chrome traffic for Google to report a percentile. Where field data exists, we've noted it; every number in the tables below is still the lab measurement, not the field data, since only 3 sites have both.

Tool 2 — local curl from this machine, located in Pakistan, 5 runs per site, recording time_starttransfer (a practical proxy for TTFB) plus DNS, connect, and TLS handshake timing. This is a second, independent vantage point — not a replacement for PSI's mobile-emulated numbers — and it reflects the specific network path from Pakistan to each site's CDN edge or origin, which varies by host region (Hostinger Boston MA and Hetzner Helsinki FI are both far from Pakistan; a Cloudflare-fronted site instead reflects the distance to the nearest Cloudflare edge, which is much closer).

Metrics recorded: server response time / TTFB, Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), First Contentful Paint (FCP), and the overall Lighthouse performance score (PSI); DNS/connect/TLS/TTFB/total time (curl).

Raw data: PSI raw runs (CSV) and curl raw runs (CSV).

PageSpeed Insights results (mobile, lab, average of 3 runs)

PSI's "server-response-time" audit measures processing time under Lighthouse's throttled mobile simulation and reads very low (1–150ms) for cacheable static responses even when LCP is 3–5 seconds — the LCP number is dominated by simulated slow-4G network throttling, not server speed. Don't read the TTFB column here as "how fast the server is" in absolute terms; read it as one lab signal among several, and compare it against the curl numbers below, which run under real (unthrottled) network conditions from one vantage point.

Local curl TTFB from Pakistan (average of 5 runs, seconds)

race-planner.com's max (4.344s) came from a single first-connection run — likely a cold CloudFront edge cache in this region — with the other four runs all under 0.22s. We kept the outlier in the data rather than discarding it; the raw CSV shows all five runs.

What this does and doesn't prove

What it doesn't prove:

• It isn't a controlled host benchmark. The sites are different stacks — Astro static, Next.js in Docker, Next.js under PM2, WordPress on LiteSpeed, a general app server, static S3, and Vinext on Workers. A stack difference can swing these numbers more than a host difference.
• Most of the Hostinger numbers include Cloudflare, not pure origin performance. Only one Hostinger site (timeandhalfcalc.com, shared hosting) and the one Hetzner site (visualsentinel.com) were measured with no CDN in front.
• The AWS example is S3 + CloudFront static hosting, not an EC2 compute instance — a different product category from a Hostinger or Hetzner VPS, included because it's the only AWS-hosted site we run.
• One data point per host category for Hetzner and AWS means we can't say whether the numbers are typical of the provider or specific to that one site's configuration and region.
• Single-day, single geographic curl vantage point (Pakistan). A visitor in the US, Europe, or elsewhere in Asia would see different relative numbers, especially for the two direct (non-CDN) origins in Boston and Helsinki.
• CrUX field data exists for only 3 of the 10 sites (primetimeanime.com, chattoanyone.com, visualsentinel.com); the rest don't have enough real-world Chrome traffic for Google to report it, so most of this page is lab measurement, not real-visitor telemetry.
• It says nothing about Cloudways, because none of the measured sites runs there. Don't read this page as an argument against Cloudways; it's a gap in this dataset, not a verdict.

What it does show:

• These are real, current production sites, measured on a stated date, with the raw per-run data published rather than a single flattering screenshot.
• Hostinger, Hetzner, and AWS are all hosts we actually operate infrastructure on today — that's the basis for anything on this site described as first-hand hosting experience with those three.
• Where Cloudflare fronts a Hostinger origin, the measured experience is a combination of the two — which is the honest, common real-world setup for a budget-to-mid VPS host, not a flaw in the test.
• A visible gap in this dataset (no Cloudways numbers) is disclosed rather than papered over with a comparison we can't back.

If you're choosing a host from this

For a beginner site or small WordPress project, Hostinger is the host we run the most production sites on and the one we recommend most often on this site — see our full best web hosting comparison. If you've outgrown shared hosting, Cloudways is compared in depth on our Cloudways vs Hostinger page from its published specs and architecture, clearly labeled as such (no measured Cloudways numbers).