A web store opens from a tap in the game, so the player's expectation is "the next screen", not "a website". Every claim about store speed should come with the device, the network, the metric and the script, or it's an adjective. Here are ours, with all four.
The method
- Viewport: 390 × 844 (a current iPhone), Chrome.
- Network: simulated 4G through Chrome's network emulation: 9 Mbps down, 170 ms round trip.
- Loads: three cold loads (no cache), report the median.
- Metrics: TTFB (first byte), DOMContentLoaded, load, LCP (largest contentful paint, the moment the biggest visible element is drawn), total bytes transferred, request count.
- Script:
tools/perf/store-speed.mjsin the Appside repository, Node + Playwright, about 50 lines. Point it at any URL.
Medians across cold loads on a slow simulated network is also the method Appcharge describes for its own store work (its post of September 30, 2026), which is the right one; the difference here is that the script and the numbers are published, so anyone can re-run them.
The numbers: Appside demo store, October 27, 2026
| Metric | Median of 3 |
|---|---|
| TTFB | 212 ms |
| DOMContentLoaded | 875 ms |
| load | 963 ms |
| LCP | 1,080 ms |
| Transferred | 323 KB |
| Requests | 54 |
The store is server-rendered HTML with the catalogue in the page, so the first content doesn't wait for a JavaScript bundle. The remaining time is images and fonts, which is where the next gains are (see below). We'll re-run and update this table when the store changes; the date on the table is the date of the measurement.
What each number tells you
- TTFB over 500 ms on 4G means the server or the CDN is slow, or the page is built per request from a slow source. Nothing on the page can fix it.
- A large gap between TTFB and LCP means the page needs a lot of work before the biggest thing shows: a JavaScript bundle, an unsized hero image, a blocking font.
- Bytes over 1 MB on a store page is almost always images that weren't resized for a phone, or a framework bundle. Appcharge's post describes starting from about 1.36 MB of compressed JavaScript on its single-page store before its optimisation work; a server-rendered page starts from a different place.
- Requests over 80 usually means per-product images with no sprite or lazy loading, plus third-party scripts.
What to fix first, on any store
- Ship the catalogue in the HTML. If the products arrive by API after the page loads, the player sees a spinner, then a layout shift, then the packs.
- Size images for a phone, and lazy-load the ones below the fold. A hero image at 1,200 px wide is three times the bytes a 390 px phone needs.
- Load third-party scripts after the products, or not at all on the store page.
- Use
font-display: swapor system fonts, so text never waits for a font file. - Measure after every change, same script, same settings. One run on office wifi tells you nothing.
Speed and conversion
Speed is the first item on the conversion checklist because it's the first thing the player experiences. A store that takes four seconds on 4G loses the player before the "is this really my game's store?" question even comes up. We don't quote an uplift percentage here, because we haven't measured one on real players yet; when we do, it'll be on this page with the method.
Create your store free and run the script against it. No card needed to start; 3.9% per successful payment.