The store that looked broken on Facebook.

Because the browser built into the Facebook app has far less memory to work with. It runs inside an app that is already using a large share of the phone, so a page that Chrome or Safari handles comfortably can exhaust what is left. When that happens the page is discarded and the screen falls back to your site's background color. Nothing is broken in your store or your link. The page simply could not finish rendering in that particular browser.

No, although it is impossible to tell them apart as a customer, which is why it gets reported as a broken link. In the case on this page every version of the URL returned a healthy response, including the version with the tracking parameter Facebook adds to a real click. The link was never the problem. The page failed after it had already loaded.

Because it depends on how much memory each phone has free at that moment. Someone with a newer phone and few apps open gets through. Someone with an older phone, or with Facebook running for hours, does not. That is why merchants describe it as random, and why it is easy to dismiss when you test it once on your own phone and it works.

File size is what gets downloaded. Decoded memory is what the image occupies once the browser expands it to draw it on screen, and it is far larger. A 4000 by 3000 photo might download as a one megabyte file but needs roughly 46 megabytes of memory to render. Page weight tools usually report the download, so a page can look reasonable on paper while being far too heavy in practice.

There is no official ceiling, but the contrast in this case is instructive. The homepage held 75.7 MB of decoded image data and failed inside the Facebook browser. The product pages held 6.3 MB and the collection pages 1.4 MB, and neither ever failed. If a page is many times heavier than the rest of your site, that page is the one to look at.

Yes, and that is exactly what happened here. The theme was resizing images correctly everywhere it controlled them. A review app on the homepage was requesting images without a size parameter, so it pulled the full original every time to fill a small thumbnail. Apps render inside your pages but do not always follow the same rules your theme does.

On its own, usually not, because a well built theme requests a smaller version of whatever you upload. It becomes a problem the moment anything on your store requests the original instead. Modern phone cameras produce images up to 24 megapixels, and 36 of the 82 images in this store were in that range. Uploading at a sensible size removes the hazard rather than relying on every app to behave.

For most stores a longest edge of about 2048 pixels is plenty. It is larger than any realistic display size including zoom on a high resolution screen, and it keeps the original small enough that nothing catastrophic happens if some app requests it in full. Going bigger adds storage and risk without adding anything a customer can see.

Shopify can, and it does so whenever an image is requested with a width parameter. That is how themes normally serve images. The resizing is not automatic in the sense of being unavoidable, though. If code asks for the image URL without specifying a size, Shopify returns the original at full resolution, exactly as uploaded.

Open your store on a phone through the app your customers actually arrive from, not through Chrome or Safari, and sit on the page for thirty seconds without touching it before scrolling. Then compare pages. If your homepage feels heavier than your product pages, or if it is the page all your social links point at, it deserves a proper look.

Not at a sensible size. In this project the photos are visually identical on the storefront because the theme was already displaying them far smaller than they were uploaded. What changed is how much data sits behind the same picture. We also kept a checksummed copy of every original before touching anything, so the change was reversible.

The same class of problem applies to any in-app browser, and Instagram is built by the same company on similar foundations. Any browser embedded in another app inherits that app's memory pressure. If most of your traffic arrives from social media, those browsers are the ones your site has to survive, and they are the least forgiving ones your customers use.

It can, because page experience is a ranking input and heavy pages score badly on it. That is the smaller problem here though. A page that ranks but does not render for a share of your visitors is losing orders directly, which costs more than a ranking position. Fix the rendering first, then treat the search benefit as a bonus.

No, and you should not accept a fix that costs you your social proof. In this project the product page reviews were untouched because they used a different component that was never part of the problem. On the homepage we built a section that reads the same review data the app already stores, so the reviews still update on their own, still show star ratings, and simply no longer pull product photographs.

Not once the page it points at is healthy. Before the fix, pointing the link at a lighter page was a sensible temporary measure that cost nothing and took a couple of minutes. It is worth knowing as a stopgap, because it puts something in your control while a proper fix is scheduled.

This one was diagnosed, built, tested and published inside one working day from getting store access. Most of that time went on measurement and verification rather than writing code. The change itself was small, which is usually true once the actual cause is identified rather than guessed at.

A focused performance fix on a single store is typically under NZD $1,000 and is quoted at a fixed price before anything starts. Larger performance work across a full catalog, or a build that needs custom sections written from scratch, is scoped separately. We would rather tell you the cause is small and charge accordingly than sell a rebuild you do not need.