The Shopify server answered in 0.73 seconds and the first content painted in 1.8 seconds. The main element of the page, however, only appeared at 19.2 seconds, and loading finished at 27.4 seconds. Measured on a store we have managed long term, with WebPageTest: Chrome, mobile profile, cold cache, Tokyo test location, 24 June 2026.
Those four numbers are the whole article. The platform was fast, the page was slow. That is a different diagnosis, a different culprit and above all a different fix - and the difference between them decides whether you spend money on a migration that solves nothing.
Split the measurement into two numbers first, or you will fix the wrong thing
Speed metrics fall into those that belong to the platform and those that belong to your page. Read together, they produce "Shopify is slow", a conclusion that nothing but moving house can fix.
| Metric | Measured | Target | What it actually measures |
|---|---|---|---|
| TTFB | 0.73 s | - | response of the platform server |
| FCP | 1.8 s | - | first content painted |
| LCP | 19.2 s | under 2.5 s | main element above the fold |
| CLS | 1.00 | under 0.1 | layout shift during loading |
| Fully Loaded | 27.4 s | - | completion of all requests |
The first two numbers are good. If the problem were in the infrastructure, TTFB would already be slow - the server would answer in two or three seconds and everything else would shift behind it. Here it answered in 0.73 seconds.
A Tokyo test location is unusual for a European store, and TTFB measured from Prague would come out differently. It has no effect on the ratio between 1.8 and 19.2 seconds though: both numbers come from the same run, on the same connection.
The third Core Web Vitals metric, INP, was not measured in this audit, because it is calculated from visitor interactions. We only state what we measured.
The gap between 1.8 and 19.2 seconds weighs 10.6 MB
On a single view of that page the browser downloaded 10.6 MB of data in 548 requests from 57 third-party domains (the same WebPageTest run, 24 June 2026). Fifty-seven domains means fifty-seven DNS lookups, TLS connections and someone else's servers whose availability you do not control.
More than half of that weight came from a single element: a 5.7 MB video above the fold, embedded with autoplay: true. That attribute starts the download immediately, regardless of connection quality, and until the first frame appears LCP does not count. One line in the theme outweighs all the other work.
The theme's own code was 635 kB. On the live page there were three megabytes
When we took apart a local copy of the same theme (27 August 2026), we found 32 custom scripts totalling 635 kB in it, and not a single one was attached without the defer attribute. The custom code was fine.
On the live page, meanwhile, the measurement tool counted roughly 3 MB of JavaScript in 236 files. The theme did not bring the difference between 635 kB and 3 MB. Apps and their external scripts did.
The practical consequence for a budget: anyone who pays for a theme refactor and leaves the apps alone is buying the smaller part of the problem. What apps leave behind in a theme is covered in the article on auditing apps.
CLS 1.00 means the page is built twice
A layout shift value of 1.00 against a target of 0.1 is not a worsened metric, it is a different page from the one the visitor saw a second earlier. Two measurable reasons, both from the theme analysis of 27 August 2026:
- 577 <img> tags in the theme, of which 13 have a width attribute (2 %) and 29 have loading (5 %). The browser does not know how much room to leave for the image, so it leaves none, and once it arrives everything shifts.
- 171 stylesheet_tag calls in sections and snippets. Each of them inserts a <link rel="stylesheet"> into the body of the document, that is, after rendering has already started.
On the second point we are careful: a connection with the measured CLS of 1.00 is likely, but we have not confirmed it. We have not yet run a control measurement after moving the styles into the layout, so it stays a hypothesis, not a finding.
The image_tag filter adds dimensions and srcset by itself and closes the question at the template level. In this theme it was used in five files out of all of them.
Twelve third-party scripts without defer are twelve outages waiting to happen
In the same theme we counted 12 external scripts without a defer or async attribute from seven third-party hosts. Two of them are synchronous right in the <head> - there the parser stops processing the document until the file has been downloaded from someone else's server.
This is not only a question of speed. It is a single point of failure: when that third-party server does not answer, nothing renders. One of the hosts in that theme, polyfill.io, was returning HTTP 520 when we checked it on 27 August 2026.
PageSpeed Insights mixes two different measurements and only one is about your page
The tool shows two sets of numbers: a lab simulation that runs now and on a defined device, and field data from real visitors over the last 28 days. When the values disagree, that is not a fault in the tool.
It means your visitors have different devices and a different connection from the simulation - and for decisions the field data applies, because your customers are in it. The lab number is good for comparing two versions of a page against each other under identical conditions.
The order in which the fixes are done
The order is not arbitrary. The first five items on this page accounted for most of the lost time, the rest was cosmetics.
- Above the fold. Video and the main image: posters, dimensions, loading="eager" and fetchpriority="high" on the LCP element.
- App inventory. Which ones run, which ones are paid for and which ones are simply left over.
- External scripts. What can be deferred, what can be self-hosted, what has to go.
- Styles into the layout. Critical inline, the rest asynchronously.
- Image dimensions across the whole theme, via image_tag.
- A control measurement under identical conditions, otherwise you do not know what helped.
The last point is the one most often skipped. The measurement before the fix and after it has to run on the same profile, from the same location and with a cold cache, otherwise you are comparing two different things.
What speeding a store up costs you
This side needs saying out loud, because offers to speed a site up usually leave it out. When you remove an app, the feature you were paying for goes with it - a loyalty programme, product reviews, the upsell in the cart.
The decision therefore does not belong to a developer. It belongs to whoever knows how much that feature earns. Our job is to supply the other half of the equation: what it costs in data, in seconds and in the risk of an outage.
We measure our own site too, and it does not come out well
With our own tool we measured this website at three screen widths on 30 August 2026 and got 5.3 to 5.6 MB in 55 to 69 requests. For an agency that sells speed that is an uncomfortable number, and it is on the list to be fixed.
We state it here deliberately. An article about speed in which the author comes out looking good is available everywhere; the useful one is where the measurement conditions and the date are visible, because only from those can you check whether the numbers hold for you as well.
Want to know which three things are slowing down your store
Send us the store address. We will return the split between what the platform does and what the page does, with measured numbers and with the order of fixes ranked by effect against cost.
What exactly we measure as part of an audit and speed-up of a site is described on the service page. If you are dealing with speed as part of a larger intervention in the theme, start with the article on how templates get out of hand.
Write to info@lamapixel.com or call +420 775 599 009.
