Because you are testing it in the best possible conditions. You load your site on fast office wifi, on a new laptop, with everything already cached. Your customers load it on a phone, on a train, on a shared network, with an empty cache. Same site, completely different experience.
This gap is the most common blind spot we run into. A team signs off on a build because it feels quick on the machines in the room. Then the analytics come in and the bounce rate on mobile is double what anyone expected, and nobody can reproduce the problem because nobody is testing under the conditions their customers actually have.
Building for slow connections is not about making an ugly stripped-down site. It is about deciding what has to arrive first, and refusing to let anything else block it.
Anything where the round trip takes long enough that the user notices waiting. That includes rural mobile coverage, congested city cells at rush hour, hotel and airport wifi, older phones on prepaid plans, and any connection where signal drops in and out. Slow is not only bandwidth. Latency and packet loss hurt just as much.
Bandwidth is the number people quote, but it is often the least interesting part. A page that makes forty separate requests will feel slow on a high-latency connection even if the pipe is wide, because every request pays the round trip cost again. Reducing the number of blocking requests usually helps more than shrinking each one.
The other half of the picture is the device. A budget phone parsing and executing a large JavaScript bundle can stall for seconds after the bytes have already arrived. Network and CPU are separate bottlenecks, and a site can be broken by either one on its own.
Heavier than most people guess, and still growing. The HTTP Archive Web Almanac 2025 reports a median mobile home page of 2.6 MB, up 8.4% from 2.4 MB in 2024. The median desktop page came in at 2,862 KB. That is the middle of the web, which means half of all pages are heavier still.
The Web Almanac 2025 breaks the mobile home page median down further. Images account for a median of 911 KB and JavaScript for 632 KB. So on a typical page, images and scripts together make up well over half the total weight before you count fonts, CSS, and third-party tags.
The same report puts the median home page growth at 7.8% year over year, reaching 2.7 MB. Page weight has climbed almost every year that HTTP Archive has measured it, while the connections at the bottom of the market have not improved at anything like that rate. The gap between what we ship and what people can receive keeps widening.
We find this number useful in client conversations because it reframes the argument. Nobody wants to hear that their site is slow. Most people are willing to hear that the whole industry has drifted, and that being lighter than the median is a competitive advantage rather than a sacrifice.
Because JavaScript costs twice. First you pay to download it, which is slow on a weak connection. Then you pay again to parse, compile, and execute it, which is slow on a weak device. A 600 KB image and 600 KB of JavaScript weigh the same on paper and behave nothing alike in practice.
An image that arrives late is a gap on the page. A script that arrives late can block the entire experience, because so many sites now depend on JavaScript to render their content at all. If the bundle fails or stalls, the visitor gets a blank rectangle instead of degraded content.
This is why we build the important parts of a page so they work before any script runs. Text, links, images, and forms can all function as plain HTML. Everything layered on top should improve the page rather than be required by it. We wrote about that approach in our guide to progressive enhancement and why it still matters.
The practical work is unglamorous. Audit what is in the bundle, remove libraries you use one function from, split code so a route only loads what that route needs, and question every third-party tag. Our piece on reducing JavaScript bundle size goes through the specifics.
Serve the smallest file that still looks right on the device asking for it. That means modern formats like AVIF and WebP, correctly sized variants offered through srcset and sizes, explicit width and height attributes to prevent layout shift, and lazy loading for anything below the fold. Never ship one large image to every screen.
The single biggest win is usually the hero image, because it tends to be the Largest Contentful Paint element. Google's web.dev guidance says sites should aim for an LCP of 2.5 seconds or less, measured at the 75th percentile of page loads. On a slow connection that budget disappears fast if the hero is a 900 KB photograph.
Format choice matters more at low bandwidth than at high. AVIF often produces meaningfully smaller files than JPEG at similar quality, and the saving compounds on a page with many images. The trade-off is encoding time and tooling, which is a build-pipeline problem rather than a visitor problem.
What we push back on is the instinct to solve this with a plugin and move on. Automatic optimisation helps, but it cannot fix an art direction decision that put four full-bleed photographs above the fold. Some of this is a design conversation, not a compression setting.
Save-Data is an HTTP request header that signals a user has opted into reduced data usage. MDN describes it as a network client hint that indicates the client's preference for reduced data usage, with a value of on meaning explicit user opt-in. You can use it, but treat it as a bonus rather than a foundation.
When the header is present, MDN explains that origins can deliver alternative content to reduce the data downloaded, such as smaller image and video resources, different markup and styling, and disabled polling or automatic updates. That is a genuinely useful signal, because it comes from the user rather than from a guess about their network.
The catch is support. MDN marks Save-Data as experimental and states that the feature is not Baseline because it does not work in some of the most widely-used browsers. It is defined in a WICG specification rather than a finished standard. So a Save-Data path will help some visitors and simply never fire for others.
There is also a caching detail people miss. MDN notes that responses should include a Vary header referencing Save-Data, so that a reduced-data response never gets served from cache to someone who did not ask for it. Skip that and you can end up serving the stripped version to everybody.
Partly, and less reliably than you would like. The Network Information API exposes navigator.connection, which MDN describes as providing information about the system's connection in terms of general connection type. Its effectiveType property gives an estimate of connection speed, including values such as slow-2g that you can branch on.
MDN is clear about the limits. The Network Information API also carries the limited availability marker, meaning it is not Baseline because it does not work in some of the most widely-used browsers, and the specification lives with the WICG. Any logic you build on it has to have a sensible default for the browsers that return nothing.
Our position is that connection detection should only ever downgrade optional extras. Skipping a background video preload or holding back an autoplaying carousel is a reasonable use. Deciding whether to render your actual content based on a network guess is not, because when the guess is wrong the visitor gets a worse site for no reason.
Almost never. A second version doubles the work, drifts out of sync within months, and splits your SEO across two sets of URLs. The better answer is one site that degrades gracefully, where the light experience is what everyone gets first and the extras load afterwards for people who can take them.
We have watched separate mobile and lite sites fail the same way every time. The main site gets a redesign and the lite site does not. A price changes in one place and not the other. Six months later the lite version is actively misleading, and taking it down breaks whatever links have accumulated.
The exception is a genuinely different product, like a status page or a checkout flow that has to work in a warehouse with no signal. Those are separate applications with separate jobs, not a stripped copy of your marketing site. If you cannot describe the different job in one sentence, you do not need a second site.
Throttle it deliberately and test on a real device. Chrome DevTools has network and CPU throttling built into the Network and Performance panels, and Lighthouse applies simulated mobile throttling by default. Run the test with an empty cache, because a returning-visitor result tells you almost nothing about first impressions.
Lab tests are a starting point, not the verdict. They tell you how the page behaves under one specific simulated condition. What real visitors experience shows up in field data, gathered from actual sessions on actual devices, which is where the ugly surprises usually live.
The other half is holding the line after launch. A site that ships fast drifts slowly as tags, fonts, and features accumulate over a year. Setting numeric limits and checking them on every deploy is the only thing we have found that actually works, which is the argument we make in our guide to setting and enforcing a performance budget.
One low-tech test beats most tooling. Put the site on a real phone, turn wifi off, walk somewhere with poor signal, and try to complete the main task. You will learn more in five minutes than in an afternoon of synthetic runs.
Start with whatever blocks the first meaningful paint. That is usually a render-blocking script, an oversized hero image, or a font that hides text while it loads. Fix those three and most sites feel dramatically better on a weak connection, before you touch anything more sophisticated.
After that, work down by weight. Cut the largest JavaScript dependency you are not really using, resize the heaviest images, and remove one third-party tag nobody can justify. Each of those is a small, safe change, and together they usually beat any single clever optimisation.
If you want a second pair of eyes on where your site is losing people, we are happy to walk through it with you. We do this work every week and the first pass is usually quick. Reach out at phoenix.studio and tell us what your slowest page is.
Tell us where you want to go. We'll tell you how we'd get you there.