When we built a school management platform for a counselling academy, one constraint shaped every decision more than any feature request: most users would open it on a phone, on mobile data, sometimes on connections that drop mid-request. That's not an edge case in our markets. It's the default user.
Most performance advice assumes the problem is shaving milliseconds for users on fast connections. Building for low bandwidth is a different discipline: the goal is for the product to remain *usable* when the network is slow, flaky, or briefly gone. Here's what actually moves the needle.
Set a page-weight budget and defend it
Decide up front what a page is allowed to cost, we aim for well under a megabyte for first load on content pages, and treat anything over budget as a bug. Budgets fail silently: one marketing image, one analytics script, one icon library added 'temporarily' and the page doubles. Check the numbers in every review, not once at launch.
Render on the server, ship less JavaScript
Server-rendered and statically generated pages (we use Next.js) mean users see real content while JavaScript is still downloading, or even if it never finishes. Reserve client-side interactivity for the parts that genuinely need it: forms, dashboards, live data. A page that renders as HTML works on connections where a client-rendered app shows a spinner forever.
Images and fonts are where budgets die
Serve modern formats (WebP/AVIF), size images to the layout instead of shipping originals, and lazy-load everything below the fold. For fonts: subset them, preload one or two weights, and always define fallback system fonts so text renders immediately. A platform's data tables and forms don't need a six-weight font family.
Design forms for connections that drop
The most expensive failure on a slow connection is a long form that loses everything on one failed submit. Keep forms short, validate on the client before the round-trip, keep the user's input intact when a submission fails, and make the retry obvious. Optimistic UI is nice; not losing twenty minutes of typed data is essential.
- Client-side validation before the network round-trip
- Preserve input on failure, never blank the form
- Clear pending states so users don't double-submit
- Paginate heavy lists instead of loading everything
Test on the connection your users actually have
Chrome DevTools will throttle your connection to 3G in two clicks, and it's the cheapest usability test you'll ever run. If a flow is painful under throttling, it's painful for a meaningful share of your real users. We make throttled walkthroughs part of pre-launch checks on every platform we ship.
None of this is exotic engineering, it's a set of defaults chosen for the users you actually have rather than the ones in a demo video. If your current platform frustrates users the moment they leave good wifi, it's fixable, and usually without a rebuild.
Building something this applies to?