How Fast Is Your Website, Really? What We Found When We Measured Ours

At the end of August, a performance report on our homepage recorded a layout shift score of 0.025, comfortably inside Google's threshold of 0.1. Ten days later we measured the same page again, this time on a throttled mobile connection and watching it for longer. It scored 0.277, which is a clear failure.

Both readings were correct. They were measuring different things, and the first one stopped watching before the page had finished moving.

That gap is the reason this guide exists. Website speed is one of the few things a business can check for itself without hiring anyone, and one of the easiest to check badly. Here is what the measurements mean, what they miss, and what we found when we ran them against our own site.

What counts as fast in 2026?

Three measurements do most of the work, and they map to three things a visitor actually feels.

• Largest Contentful Paint is how long until the biggest thing on the screen appears, usually the headline or the hero image. The target is 2.5 seconds or less.
• Interaction to Next Paint is how long the page takes to respond visibly after someone taps or clicks. The target is 200 milliseconds.
• Cumulative Layout Shift is how much the page moves around while it loads. The target is 0.1 or less. This is the one people describe without naming it, when they say they tapped a link and hit an ad instead.

Two things about these targets matter more than the numbers. They are judged on real visits, not tests, and they are judged at the seventy-fifth percentile, so three out of every four visits have to clear the bar before a site counts as passing. Google uses them in its ranking systems, as one signal among many. The better reason to care shows up in your inquiries rather than your rankings.

Is slow internet still a fair excuse here?

It used to be. It is getting harder to say with a straight face.

Median mobile download speed in the Philippines reached 59.64 Mbps at the end of 2025, having climbed almost 26 Mbps, or 77 percent, in twelve months. Median fixed broadband sits at 105.17 Mbps. There are 98 million people online here, and 89 percent of the country's 137 million mobile connections now run on 3G, 4G or 5G. The network that Philippine businesses used to apologize for has quietly become adequate.

That moves the question somewhere less comfortable. When our own homepage was slow, the server was answering the first request in about 31 milliseconds. The connection was fine and the hosting was fine. What took the time was everything the page asked the browser to do next.

What does a performance score actually tell you?

Less than it looks like. A Lighthouse run is a single simulated visit, on a simulated mid-range phone, on a simulated network, in a browser with no history and nothing else running. It is a useful, repeatable sample of one visit. Real visitors arrive on real devices, with tabs open and caches half full, and they scroll.

That last word is where our own two numbers came from. As Google's own documentation puts it, lab measurement "only considers layout shifts that occur above the fold and during load", while in the field the measurement "considers all unexpected layout shifts that occur throughout the lifespan of the page". Our homepage had a shift that waited on the page's load event and then landed somewhere between eight and twenty-five seconds in, under a throttled mobile profile. The lab tool had finished and filed a pass. The shift happened anyway, and a visitor on a slow connection would have watched the hero rearrange itself under their thumb.

The cause was a decision that had looked right a few weeks earlier. We had moved the script that sets up our type system out of the page head and into the footer, which is standard advice and which did what it promised: the page started painting sooner. The cost only appeared later in the load, when the type finally arrived and the hero re-laid itself out. A trace recorded the hero passing through twelve distinct states before it settled.

The lesson we took from it is that performance work trades one thing for another more often than it simply improves things. If you only ever read the summary number, the trade stays invisible.

What did we find when we measured our own site?

We re-ran the measurements while writing this, so the numbers below are this week's. Method, so you can repeat it: Lighthouse 13.5 driving an isolated Chrome build against the live site, mobile and desktop profiles, five runs of each on the homepage and three of each on a blog post page, and medians reported instead of best results.

On mobile, the homepage scores 70 out of 100. Layout shift comes in at 0.0096, comfortably good, which confirms the September fix held on the live site. Responsiveness is fine, with total blocking time near 100 milliseconds. Loading is the problem: the largest element takes a median of 5.4 seconds to appear against a 2.5 second target, and it swings between 4.4 and 12.7 seconds from run to run. On desktop the same page scores 84 and paints its largest element in 2.1 seconds, which passes.

Then we tested a second page, and it produced the more useful finding. A blog post on the same site carries 1.8 megabytes against the homepage's 4.6, and it is slower: a median mobile loading time of 9.7 seconds. The lighter page lost. It spends roughly 1.4 seconds waiting on resources in the page head before it can draw anything, against about 0.6 seconds on the homepage, and it asks more of the phone's processor once it starts. Weight matters, but the order things happen in matters more.

The underlying diagnosis is ordinary. Our server answers the first request in about 31 milliseconds, so hosting is not the constraint. The homepage ships 4.6 megabytes, of which roughly 2.6 megabytes is image payload that correct sizing and compression would remove, with another 641 kilobytes of cacheable content being fetched again on repeat visits. Those are content and configuration decisions, which is the same conclusion we reach on most of the sites we audit, including this one.

The layout shift work held. The loading work is still open. Both halves are here because the second one is the more common situation, and it is the one worth writing down.

What usually makes a page slow?

Across the sites we audit, the same four causes come up, roughly in this order.

• Weight, almost always images. Photographs exported at print dimensions and scaled down in the browser, hero videos that autoplay, and stock illustration nobody needed. This is the single most common cause and usually the easiest to fix.
• Code that blocks the first paint. Stylesheets and scripts in the page head that the browser must finish before it can draw anything. A small amount is necessary. Most sites carry more than they need.
• Content that arrives without reserved space. Images without dimensions, embeds, cookie banners, and late-loading fonts. Each one pushes whatever is below it down the page as it appears.
• Third-party tags. Analytics, chat widgets, pixels, and the tag that was added for one campaign in 2023 and never removed. They accumulate quietly because no single one feels expensive.

Three of the four are content and configuration decisions. That is good news for the budget, and awkward news for anyone hoping a developer can solve it alone.

How do you check your own site in fifteen minutes?

You do not need a specialist for a first look. Five checks will tell you where you stand.

• Run Lighthouse. It is built into Chrome under the developer tools, on the Lighthouse tab. Choose the mobile setting, because that is where most of your visitors are.
• Run it three times. Single runs vary a great deal, and one lucky sample will send you chasing the wrong cause. Compare the middle result, not the best one.
• Check the field data too. Paste your address into PageSpeed Insights. If your site has enough traffic, it will show what real visitors experienced over the last month, which outranks any test you can run.
• Open it on a real phone, on cellular. Not the office wifi, and not your own laptop. Then scroll slowly and watch for anything that jumps after you can already read it.
• Look at the weight. In the developer tools, under Network, reload and read the total transferred. Anything past two megabytes on a marketing page deserves a conversation.

Does fixing this change the cost or the timeline?

Built in from the start, it costs discipline more than budget. Image sizes get decided with the design, what loads first gets decided with the build, and the result is tested on a throttled connection before launch rather than after. On a standard company site delivered in eight to sixteen weeks, that work sits inside the existing phases.

Retrofitting is a different conversation, worth having honestly before you spend. Compressing images and removing unused tags is quick and often gets a site most of the way. Rebuilding a hero that was assembled the wrong way round, or unwinding a theme that loads every feature on every page, is closer to construction than tuning, and at that point you are choosing between a repair and a rebuild at the professional tier of our cost guide. If you are briefing this work out, our guide to website briefs covers how to ask: name the target, name the test conditions, and ask for the numbers before and after.

One thing worth refusing is a plugin that promises to fix performance by being installed. Caching helps and compression helps, but neither makes a four megabyte page a light one, and a report that improves without the experience improving is the situation this whole guide is about.

Common questions

What counts as a good loading speed for a website?
The largest element on the screen should appear within 2.5 seconds for at least three out of four real visits, measured on mobile. Between 2.5 and 4 seconds needs work. Past 4 seconds counts as poor.

Why does our site score well but still feel slow?
A test score comes from one simulated visit that stops watching early. It misses anything that happens later in the load, anything triggered by scrolling, and anything your real visitors' devices and connections add. Run the test three times, then open the site on a phone on cellular data and trust what you see.

Does website speed affect our Google ranking?
Yes, as one signal among many rather than a switch. Speed is better treated as a conversion issue than a ranking tactic, because the visitor who leaves before the page appears was never going to read it or fill in the form.

Is slow hosting usually the reason a site is slow?
Rarely, in our experience. On our own site the server responds in about 31 milliseconds while the page still takes seconds to appear. Check the server response time before you pay to move hosts, because the cause is usually the weight of the page rather than the machine serving it.

How much does it cost to fix a slow website?
It depends on whether it is a repair or a rebuild. Compressing images, removing unused tags and correcting what loads first is usually quick and inexpensive. A site whose structure loads every feature on every page is closer to a rebuild, and worth quoting honestly as one.

How often should we check?
Test before every launch, after any redesign, and once a quarter otherwise. Sites get slower the way rooms get cluttered, one reasonable addition at a time.

Where we stand

Our own site is partway through this work, which is how the sections above came to have real numbers in them. The layout shift problem is measured and fixed. The loading weight is measured, and it is the next item on our own list. One loose end remains: we have not yet confirmed how the page behaves for a visitor who does not have our brand typeface cached, because the machine we tested on had the font installed locally and quietly hid the answer. That will need a clean test before we call it done.

If your own fifteen minutes turns up more than you expected, or the report says one thing and the page says another, we are glad to take a look with you. Most of what we find is ordinary and fixable. The rest is at least worth knowing about before it is quoted to you as a rebuild.