Why is my PageSpeed score low?

1. Start with the part Google ranks on

A PageSpeed Insights report has two parts. The block at the top, "Discover what your real users are experiencing", comes from real Chrome visitors to your store over the last 28 days. The score below it comes from one simulated test.

Google's ranking uses the real-visitor part: the Core Web Vitals. They pass when, for 3 in 4 phone visits, the main content shows within 2.5 s, taps get a response within 200 ms, and the page barely jumps (layout shift under 0.1). If yours pass, a low lab score is not costing you rankings. Small or new stores often have no real-visitor data yet; then the lab score is all you have.

2. The lab score is a simulation of a slow phone

PageSpeed loads your page once at full speed and notes the moment the first frame was drawn. Then it simulates a slow phone, and counts every file that finished before that first frame as needed for it. So two things decide the score: when the first frame arrives, and how much your page downloads before it.

3. Why the same page scores 65 one minute and 95 the next

On Google's test machine the first frame doesn't always arrive on time. Sometimes it comes a whole second or two late, while the page's files are already in and the processor is idle. When that happens, everything downloaded meanwhile counts against you. We ran the Inlinex home page 63 times in October and saw it clearly: the first frame came at about 0.3 s, 1.35 s or 2.4 s, never in between.

Two of those runs, 19 seconds apart on the same page, scored 95 and 75. Nothing about the store changed. On Google's own machine the late start was the usual case for this store in October, which is why its owner kept seeing scores in the 60s. Shopify's own demo store, with no apps at all, starts late too. So a low score is not proof that your theme is bad.

4. What makes the first frame late

Across 27 runs on Google's machine, the first frame came late whenever a render-blocking stylesheet was still downloading about 0.33 s in. On Shopify that is usually a stylesheet added by an app (chat, reviews, pop-ups) from cdn.shopify.com/extensions. When the last blocking file was done by about 0.31 s, the run started on time.

It caught us on this very site too. A font file that finished at 0.41 s held our own first frame to 1.35 s. With the font built into the page, the first frame came at 0.29 s.

5. What makes a late start expensive

A late start only costs a lot if the page downloads a lot in its first two seconds. On the Inlinex home page that was 2.2 MB in 124 requests, which the test reported as "main content at 11 s". The usual culprits:

• chat widgets and session recorders (Microsoft Clarity alone added about a second)
• YouTube videos embedded in product descriptions: about 630 KB of player code on one Inlinex product page
• product rails, Instagram feeds and second banners far below the fold
• the cart drawer's styles, although nobody sees the drawer until they tap the cart

6. Fixes that worked on a real store

Each was tested on Google's own machine before it went live on Inlinex:

1. App stylesheets load in the background instead of blocking the first frame.
2. Chat and session-recording scripts wait for the visitor's first tap, scroll or key, or 4 s after load.
3. The cart drawer's styles load in the background.
4. On the home page, header and headline appear in the same first frame.
5. Videos in product descriptions load only when scrolled near (one product page went from 57 to 86).
6. Links that went through a redirect now point straight at the final address.

Result: the home page scores 100 when the test starts on time, and 93-96 when it starts late (it was 53-66), with Accessibility, Best Practices and SEO at 100 too. The last step was making the page's own code smaller: on Google's test, every 31 KB removed brought the first screen about 0.15 s sooner. The full case study has every number.

7. What didn't work

Making the page render-block until the headline appears (rel="expect") worked in local tests and then made Google's test start late 4 times out of 4. Loading Google Fonts after the page, an extra preconnect hint, and a tiny animation to "keep frames coming" made no difference. Hiding a product page until its photo loads doesn't help either: it only works when the main element is text.

8. Check your own store in ten minutes

1. Open pagespeed.web.dev and test your final address: the one with no redirect (with or without www, whichever your store uses). A redirect costs about a second in the test.
2. Read the real-visitor block first. If Core Web Vitals pass, Google already sees your store as fast.
3. Run the test four times and compare. One run proves nothing.
4. In a low run, look at the filmstrip under the score. If the first frames are blank white, the test started late. In "LCP breakdown", a small time to first byte with an "element render delay" over 1,000 ms is the same sign.
5. Under "Render-blocking requests", look for files from cdn.shopify.com/extensions. Those are your apps.

A score in the 90s on every single run isn't something anyone can promise while Google's test sometimes starts blank. A realistic target is on-time runs in the 90s, late runs as high as your page allows, and real visitors passing Core Web Vitals.