Inlinex: from the 60s to 100 on Google's phone test.
Inlinex sells inline skates from Singapore on Shopify. Its phone score kept coming back in the 60s, although real visitors found the store fast. Four weeks of measuring found out why.
100 / 100 / 100 / 100 for Performance, Accessibility, Best Practices and SEO on Google's phone test, 2 Nov 2026. Open Google's report
The problem
Phone PageSpeed runs of the home page on Google's own test: 66 (3 Oct), 66 and 66 (8 Oct), 63 (9 Oct), 64 (12 Oct). A typical run showed the first content at 3.9 s and the main content at 9.3-11.0 s.
Real visitors were fine all along. Google's Chrome data for the store passed Core Web Vitals on 8 Oct: main content within 1.7 s for 3 in 4 phone visits, taps answered in 122 ms, no layout shift. So the job was the lab score, without making real visitors' experience any worse.
What we found
The first frame came in steps of about a second. Over 60 runs on Google's machine on 12 Oct it arrived at about 0.4 s in a good run, and at about 1.4 s or 2.4 s in a bad one. By then the page's files were in and the processor was idle. Our own runs of the page show the same steps:
See the numbers
| Start | First frame | Runs | Scores |
|---|---|---|---|
| On time | 0.25-0.59 s | 45 | 68-95 |
| 1 s late | 1.34-1.39 s | 5 | 63-64 |
| 2 s late | 2.31-2.50 s | 13 | 54-83 |
63 Lighthouse runs of the Inlinex home page (phone, simulated slow 4G) from one PC in Singapore, 3-30 Oct 2026.
Everything before it was counted. In a late run, Lighthouse counted every request that finished before the late frame as needed for it. On the home page that was 2.2 MB in 124 requests, which became "main content at 11 s".
It wasn't the theme. Shopify's own Dawn demo store, with no apps, started late in 4 of 6 runs too. It scores higher only because it downloads less in that time.
The trigger. Across 27 valid runs on 30 Oct, the start was late whenever a render-blocking stylesheet was still arriving after about 0.33 s. That was nearly always the chat app's stylesheet. When the last blocking stylesheet was done by about 0.31 s, the run started on time.
What we changed
Every change was first tested on Google's own machine, as an A/B on alternate templates that shoppers never see, and went live only after that. Each file was backed up first and read back after writing.
- The chat app's stylesheet loads in the background instead of holding up the first frame.
- Session recording (Microsoft Clarity) and the chat widget wait for the visitor's first touch, scroll or key, or 4 s after load.
- The cart drawer's stylesheets load in the background, with one inline rule keeping the hidden drawer hidden.
- On the home page, the header and headline appear in the same first frame.
- YouTube videos in product descriptions load only when scrolled near. That's about 630 KB of player code that no longer loads up front.
- 16 menu links that went through a redirect now point straight at the final address.
2 Nov, for all four scores at 100:
- Accessibility was 97, all from colour contrast. We darkened the sale price, the Google reviews widget and the footer's grey text, and made one small link big enough to tap.
- Six cart-drawer preloads that competed with the main stylesheet were removed, and Shopify's checkout-button stylesheet no longer holds up the home page.
- Three large cart scripts (duties, shipping estimate, free gift) moved out of the page into cached files, with identical behaviour.
- The Google reviews widget (119 KB, most of it the app's own script) now loads when the shopper scrolls near it.
Those last two took the home page's code from 136 KB to 96 KB as Google downloads it. That mattered more than we expected: on Google's phone test, the first screen came about 0.15 s sooner for every 31 KB removed (an A/B on Google's machine). Moving the same code to the end of the page did nothing; only removing it helped.
Ad pixels and analytics were not touched.
Results
Home page, phone, Google's own PageSpeed test:
| When | Scores |
|---|---|
| Early October (3-12 Oct) | 53-66 when the test started late (the usual case), 73-86 when on time |
| A/B, 30 Oct: before the final fixes | 87, 87, 88, 83, 86 |
| A/B, 30 Oct: with the fixes | 99, 100, 100, 92 |
| Live, 30 Oct | 100, 100, 100, 92, 100, 91 (91 and 92 were late starts) |
| Fresh batch, 1 Nov | 100, 100, 100, 100, 99, 99, 99, 100 and one late start at 88 |
| 10 runs, 2 Nov, after the contrast and preload fixes | 99, 99, 99, 100, 99 on time; 91, 91, 93, 86, 91 late. Median 96. |
| 10 runs, 2 Nov 14:00-14:08, after the lighter page | 100, 100, 100, 100 on time; 96 on a semi-late start; 93-94 late. First content 1.23 s (was 1.53 s). |
| All four scores, phone | 2 Nov, before | 2 Nov, after |
|---|---|---|
| Performance | 91-94 | 100 when the test starts on time, 93-96 when late |
| Accessibility | 97 | 100 in 10 of 10 (afternoon batch) |
| Best Practices | 100 | 100 in 10 of 10 (afternoon; 7 of 10 in the morning, see the notes) |
| SEO | 100 | 100 in 10 of 10 |
| Before | After | |
|---|---|---|
| Product page with a YouTube video | 57 | 86 |
| Real visitors, Core Web Vitals (Chrome data, 28 days) | passed (8 Oct) | passed (1 Nov): main content 1.9 s, taps 123 ms, layout shift 0, first content 1.7 s |
Honest notes
- Google's test still starts late sometimes: about half the runs on the afternoon of 2 Nov, against 1 of 9 on 1 Nov. Late runs now score 93-96 instead of the 50s and 60s. On 2 Nov the late starts no longer lined up with a slow stylesheet, so a store can make them rarer, not impossible. That's why we say "100 when Google's test starts on time", not "always 100".
- The 3 Best Practices runs below 100 on 2 Nov lost points to Shopify's own Shop Pay check, which Google's machine was asking too often (it answered "too many requests"). That's Shopify's code, not the store's.
- One run on 1 Nov scored 70, and we couldn't open its report to see why. Nine fresh runs in the same hour scored 88-100.
- Real visitors passed Core Web Vitals before the work and still pass after it. The fixes moved the lab score; real visitors didn't need rescuing.
What didn't work
We tried these on Google's machine and dropped them: making the page render-block until the headline (rel="expect", late 4 of 4), loading Google Fonts after the page, an extra preconnect, a tiny animation to "keep frames coming", and hiding product pages until the photo. We also learned not to judge a change on one run: the same unchanged page scored 65 or 85 depending on how the test started.
Want the same look at your store?
The free check reads your store in about a minute. Every fix starts with this method on your home, product and collection pages. How Shopify speed optimisation works or see a sample report.