Why your website is slow on the phones your customers carry

The new site went live last month. On the office laptop it opens before your hand leaves the mouse. Then a customer replies to your Facebook post to say the link “does not load”, and another asks whether you are on Shopee instead. The site you tested and the site your customers get are two different things. That gap is why a website slow on mobile can look perfect at your desk.

The phone in your customer’s hand

Your laptop has a fast processor, plenty of memory and a fibre connection. The customer is holding a mid-range Android bought at a mall kiosk a couple of years ago. Every script your page ships has to be downloaded, parsed and run by that phone’s processor. On the laptop the cost is invisible. On the phone it is measured in seconds.

The connection is worse than the signal bars suggest. A customer on prepaid data from Globe, Smart or DITO is often on a promo with a fixed allocation, and your page is eating into it. Mobile networks have high latency even when the bars are full, so every extra file the page requests costs a round trip, and coverage changes from one barangay to the next.

They also did not type your address. They tapped a link in a Facebook post, a Messenger reply or your Google Business Profile listing. That link opens inside the Facebook or Messenger in-app browser, which keeps its own cache, separate from Chrome’s, so a previous visit in Chrome does not help. From that phone, a page that takes eight seconds to show its first image looks the same as a page that is down.

What Core Web Vitals measure

Core Web Vitals are three numbers Google collects from real Chrome users while they load your pages, so they describe the customer’s phone, not your laptop. Google publishes the thresholds it counts as good.

• Largest Contentful Paint (LCP): how long until the biggest element above the fold, usually the hero image or headline, is on screen. Good is 2.5 seconds or less.
• Interaction to Next Paint (INP): how quickly the page responds when someone taps the menu, a product or “add to cart”. Good is 200 milliseconds or less.
• Cumulative Layout Shift (CLS): how much the page jumps around as it loads, which is what makes a customer tap “cancel” when they meant “checkout”. Good is 0.1 or less.

Google uses them as a ranking signal, but the better reason to care is that they are the closest thing you have to standing behind a customer and watching. Field data is what real visitors experienced, and it only appears once a site has enough Chrome traffic. Lab data is a test run on a simulated slower phone and connection, deliberately throttled, which is why it disagrees with what you see at your desk. That disagreement is the point.

What a page builder and an unoptimised image cost

Page builders such as Elementor, Divi and WPBakery let a non-developer assemble pages by dragging blocks, and that convenience has a price the laptop hides. The builder loads its whole toolkit on every page whether the page uses it or not: several stylesheets, several scripts, an icon font, slider and animation libraries. Each file is a separate request over a high-latency connection, and each script is work for a modest processor. Then the plugins stack on top: a chat widget, the Meta Pixel, analytics, a cookie banner, each a connection to another server before the page can settle. The result is a page that is still busy several seconds after the customer can see it, so taps go unanswered and buttons move as content loads. That is INP and CLS failing together. Builders are not always the wrong choice. But the cost lands on the customer’s phone rather than your screen, and it should be a decision rather than an accident.

Images are the other big weight. A photo straight from a phone camera is several megabytes and around four thousand pixels wide. Upload it as the hero and the customer’s phone downloads the whole file, then shrinks it to fit a screen four hundred pixels across. That single file can weigh more than everything else on the page combined, and it comes out of the customer’s prepaid allocation. A menu page with twenty dishes or a product gallery repeats the mistake twenty times.

The fixes are unglamorous. Resize each image to the largest size it is displayed at. Serve it as WebP, which is usually smaller than a JPEG at the same visible quality; WordPress can do this on upload with a small plugin. Give every image its width and height so the text does not jump when it arrives. Load images below the fold only when the customer scrolls to them, and never lazy-load the hero, because that is the element LCP is timing. Fonts follow the same rule: a Google Fonts embed is another server to contact before text can appear, so self-host the file or use a system font.

How to check on a real device

1. Get the right phone. Not the newest iPhone. Borrow a colleague’s mid-range Android that is a couple of years old.
2. Turn wifi off. Test on mobile data, on the network your customers use. If they are in the provinces, ask someone there to run the test.
3. Arrive the way a customer arrives. Send yourself the link on Messenger and tap it there, then open it again in a Chrome incognito tab so nothing is cached. Count the seconds until text appears, until the main image appears, and until the menu answers a tap.
4. Do the job the customer came to do. Open a product, add it to the cart, start the enquiry form, reach the GCash or Maya step. Note every lag and every jump.
5. Read the real-user data. Paste the URL into PageSpeed Insights and stay on the mobile tab. The section on what real users are experiencing is field data; if it is empty, the site does not yet have enough traffic. If the site is verified in Search Console, its Core Web Vitals report lists the pages that fail.
6. Repeat for the pages that matter. Home, your top service or product page, contact and checkout. Do not assume the home page is the slowest one.

What to do next

Run the test this week and write down the three numbers for each page. Put them in front of whoever built or maintains the site and ask two things: which pages pass on real-user data, and what the largest file on the home page is. Both answers should come back quickly.

Add a line to every future brief that names the device, the connection and the target, and make sign-off depend on a real-device test rather than a laptop demo. Give the people who upload content a simple image rule, because a fast build gets slow one upload at a time. Re-test after every new plugin and every campaign page. The customer’s phone is the only place the site has ever existed for them, so it is the only place worth measuring.