Why your website feels slow in the Philippines
It is almost never the server. It is that the site was signed off on a fast laptop on fibre, and your customers are on a mid-range Android phone on mobile data — which is a different website.
A Philippine website usually feels slow because it was never tested on what Philippine customers actually use. Google’s published thresholds are LCP under 2.5 seconds, INP under 200ms and CLS under 0.1, and the figure that matters is the one measured on a mid-range Android over mobile data, not the one your designer sees. The four usual causes, in order: uncompressed images, third-party scripts, fonts that block rendering, and a plugin stack nobody has audited. Hosting is rarely the problem, and moving host is the most commonly sold non-fix in this market.
Test on the phone your customers hold
This is the whole argument. A site reviewed on a MacBook over office fibre is being judged under conditions almost none of its visitors share. The same pages on a three-year-old Android handset, on mobile data, in a mall with congested cells, are a materially different product — and that product is the one earning or losing your money.
You do not need a lab to check this. In Chrome on your own machine, open DevTools, take the Performance panel, set CPU throttling to 4× slowdown and the network to Slow 4G, and reload. That approximates a mid-range phone closely enough to be useful, and it is generally an unpleasant surprise the first time.
Then do it properly: open the site on an actual mid-range Android, on mobile data, away from your office wifi. Count the seconds out loud. Anything you would not wait through, your customer will not wait through either.
What the thresholds actually are
Google publishes these, and they are the same everywhere — there is no Philippine allowance:
| Metric | Good | Needs work | Poor | What it means |
|---|---|---|---|---|
| LCP | ≤ 2.5s | 2.5–4s | > 4s | When the main thing on screen finishes loading |
| INP | ≤ 200ms | 200–500ms | > 500ms | How fast the page answers a tap |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 | How much the layout jumps while loading |
CLS is the one owners underrate. It is why someone taps the wrong button as an advert loads above it — and on a phone, where the target is a thumb, it converts irritation into a lost booking.
Our own numbers, since we are the ones telling you to measure
Measured on this site’s homepage, 11 September 2026:
| Measure | This site | Why it matters |
|---|---|---|
| Total page weight | 470 KB | Every kilobyte is billed to your visitor’s data plan |
| Requests | 33 | Each one is a round trip on a congested cell |
| Third-party hosts | 0 | Nothing loaded from another domain — no tag manager, no hosted fonts |
| Layout shift (CLS) | 0 | Nothing moves while the page loads |
An LCP figure. We can measure one here, but it would be a desktop browser on a fast connection, and presenting that as a mobile result is precisely the mistake this article is about. A speed number is only meaningful with the device and network attached to it. Ask any agency quoting you a score which device produced it — including us.
The four things actually slowing you down
1. Images, by a wide margin
A single phone photograph dropped straight into a page can weigh more than this entire homepage. The fix is unglamorous and enormous: resize to the dimensions actually displayed, serve WebP or AVIF, compress, and let images below the fold load lazily. Most Philippine business sites we audit would halve their weight on images alone.
2. Third-party scripts
Tag manager, three analytics tools, a chat widget, a review badge, two ad pixels. Each is a separate connection to a separate domain, each can block rendering, and none of them are on a connection you control. Our own site loads zero third-party hosts, which is not asceticism — it is the single easiest large win available, and it is why the fonts are self-hosted rather than fetched from Google.
3. Fonts that block the first paint
A page that waits for a webfont before showing text shows nothing at all for the duration. Self-host the files, subset them to the characters you use, and set font-display: swap so text appears immediately in a fallback and reflows when the real face arrives.
4. A plugin stack nobody has audited
Chiefly a WordPress issue, and rarely the platform’s fault. Plugins accumulate, each loading its own CSS and JavaScript on every page whether or not that page uses it. A site with thirty active plugins is carrying thirty sets of assets on the contact page. Auditing them is dull and usually the cheapest speed work available — see WordPress versus custom for when the platform itself is the constraint.
What is usually not the problem
Your hosting. It is the most commonly sold fix and rarely the cause. Server response time is one part of LCP and usually a small one; if the server answers in 200ms and the page still takes six seconds, a faster server buys you very little. Check the server time before anyone sells you a migration.
Your page count. A twenty-page site is not slower than a five-page site. Weight per page is what matters, and a single page can carry all of the problems above on its own.
Your CMS, usually. WordPress can be fast. It is not fast by default and it will not stay fast unmaintained, which is a different criticism and a fair one.
When speed is not your problem at all
If you have almost no traffic, speed is not the constraint — demand is, and a faster site with nobody on it earns the same as a slow one with nobody on it. We would rather tell you to spend the money on ads or SEO first and come back to performance when there is traffic to lose.
Where speed genuinely decides revenue is checkout, booking and enquiry flows with real volume moving through them. That is where we hold a pass/fail speed gate at launch, measured on a mid-range Android over mobile data, because a gate measured any other way is not a gate.