Rashmi Kumari: A 51 MB Homepage Cut To 4.6 MB

The homepage carried three video clips. One played in the mobile hero. One played in the desktop hero. One sat behind a text block that both devices shared. Their original files were large: 26.4 MB, 9.8 MB and 30.8 MB. That is 67 MB combined. All three downloaded on every visit, before a shopper touched anything.

The desktop clip was hidden on phones. A line of code, display: none, hid it from view. Hiding something from view does not stop a phone from downloading it. Nothing in the old code blocked the request. A shopper on a slow connection still pulled a 9.8 MB file. They would never even see it.

First, we made a copy of the live theme. A theme is the code that controls how a Shopify store looks and behaves. We checked all 333 files in the copy against the original, file by file, before changing anything.

The old code loaded every video’s file the moment the page opened, hidden or not. The new code waits. It watches the page as a shopper scrolls. Only when a video is about to come into view does its file start loading. A hidden video never comes into view, so its file never loads. A still image loads first instead, so the page always has something to show.

None of the three videos was removed. Each one was re-encoded instead, meaning compressed down to a much smaller file without cutting its length. Then each was set to load only once a shopper could actually see it, using the rule above.

Cutting the download size didn't fully fix the load time Google's hosted check reports. We'd rather say that plainly than round it up.

That check is PageSpeed Insights. It runs the same kind of simulated phone test, but on Google's own servers. After the fix went live, it tested the homepage three times. Each run recorded a slow Largest Contentful Paint, the moment the page's main content finishes appearing on screen, at between 12.3 and 12.5 seconds. The next day, a separate check on a product page came back even slower, at 12.6 seconds.

Lighthouse, run on our side, never came close to those numbers on either theme. It measured around 3 seconds on both. That gap matters. The byte reduction is real, and we measured it two separate ways. But the slow paint only shows up on Google's hosted check.

A second fix is already aimed at that gap, sitting on a separate copy of the theme. In this version, the hero video waits until two things happen, the page finishes loading and the browser records its main paint, then holds off another 250 milliseconds. So unless the shopper scrolls or taps first, the video can't load before that paint. We checked it against the live theme, and the founder published it on 23 September 2026. Whether it actually closes the gap is still an open question. One PageSpeed check on the homepage later that day read 3.5 seconds, but one run isn't proof.

What we left alone on purpose

The product page still runs its own video in a format called HLS. That video pulls 1.6 to 1.9 MB by itself and slows down the page's main paint. It's the next thing to fix, just not this one.

The page also has a stylesheet that stops the browser from drawing anything until it finishes loading. Shopify's own tool for placing that file directly in the page caps out at 15 KB, and this file is larger. Splitting it into smaller pieces needed approval from the account, so we didn't do it.

A few scripts stayed running too: a newsletter popup, checkout tracking and an analytics tool. We switched off one WhatsApp button at the founder's request. Beyond that, the only other edits were connection hints, one font preload on the product page, and three homepage stylesheets set to load without blocking.

This fix is for a store whose homepage carries autoplay video or full-size photos nobody resized. It is not the fix for a store that is slow because of checkout apps or a crowded app list. That kind of slowness needs its own check first.