How to design a website that works on a ten-year-old phone

Designing for a handset that has been in service for a decade is not about reproducing a desktop site on a small screen. It is about removing anything that delays the first useful interaction. An old handset has less memory, a slower processor and an aged battery, so every decorative script, oversized image and tracking tool becomes part of the reader’s wait.

Assuming most visitors own current hardware is how personal sites acquire bloat without becoming useful. Start with a modest baseline: a phone from roughly 2015 or 2016, a mobile connection and a reader who wants an essay, guide or review. The design should feel calm, quick and legible before any attempt to feel clever.

Begin with the content and the task

Define the page’s job in plain language before choosing a layout. A reader may be checking a café opening time, scanning a book list, comparing travel costs or reading a long essay. Those jobs need different emphasis, but none requires a hero video, pop-up or carousel merely to prove that the site uses them. Put the answer close to the top and let the supporting detail follow.

Mobile-first structural order matters here. Put the title, primary image, byline, key action and opening paragraphs into the initial HTML flow; use CSS to rearrange them later when there is room. This keeps the central content available even when a stylesheet fails, and it helps search engines understand the page. It also prevents a sticky navigation panel from swallowing half of a small display before the reader sees anything useful.

The editorial core deserves the same protection. My recent reading list works because the selection and comments give the page a reason to exist, not because of decorative extras. Apply that test to every section: if it helps somebody understand, decide or enjoy the material, keep it; if it only fills space, remove it. Good mobile design is often subtraction made visible.

Find the bottlenecks before redesigning

A slow website is not automatically a design problem, and a pretty redesign can conceal a bloated page rather than fix it. Begin with a waterfall report in Chrome DevTools, PageSpeed Insights and WebPageTest. Watch the transfer size, main-thread work, render-blocking resources and the point at which the page becomes usable. Pay particular attention to the largest contentful element and to scripts that run before the article can settle.

Core Web Vitals provide useful guardrails: aim for LCP within 2.5 seconds, INP within 200 milliseconds and CLS below 0.1, while treating field data from real visitors as the final measure.

Throttle the connection to a realistic mobile profile, but do not rely on the simulator alone. A ten-year-old phone needs time for JavaScript, image decoding and layout that a desktop processor handles instantly. Use CPU throttling in the browser, then repeat the important journey on an actual old iPhone 7 or Galaxy S7 if you can borrow one. Check a cold visit, a repeat visit and a visit with cookies cleared, since caches and consent scripts can hide different costs.

Set budgets the whole site can understand. For a text-led post, an initial ceiling of 1 MB including images and scripts is a sensible target. Defer non-essential code, enable compression and give static assets sensible cache headers. Analytics, chat widgets and advertising scripts often compete for the same limited processor. One restrained analytics package is more valuable than several tools that make the page sluggish and produce overlapping data.

Keep the visual system light

Images usually account for most of the excess weight on a content site. Resize them to the dimensions they actually occupy, compress them and give every image explicit width and height so the browser can reserve space. Use responsive image sources with srcset and sizes; AVIF or WebP can reduce bytes further, but provide a JPEG or PNG fallback because the browser on an old phone may not understand the newest format. The quality should suit the screen, not the largest monitor in the office.

Logo sharpness can also be a source-file problem rather than a CSS problem. If the available artwork contains no detail, scaling it will only enlarge the blur; my pixelated logo repair offers a quick cleanup route before the asset is exported. Prepare small-screen variants when a detailed desktop mark becomes illegible, and keep text as text rather than flattening it into an image. A crisp heading is lighter and more accessible than a decorative graphic.

Treat fonts, styles and widgets as one performance budget. Subset a custom typeface, load only the weights used and allow a system font to appear while it arrives. Put essential CSS in a small inline block and defer the remainder, while avoiding frameworks for a simple article layout. A flexbox structure with a little JavaScript will reach more old devices than a new build system requiring a large bundle. Keep carousels, background video and animated backgrounds off the critical path.

Make reading and tapping comfortable

Typography should be treated as an interface, not a layer of decoration. Use at least 16 CSS pixels for body text, roughly 1.5 line height and a line length that remains easy to scan on a phone. Strong colour contrast helps in daylight and for readers with low vision, while a dark theme should not replace black text with flat, unreadable grey. Let the browser handle wrapping rather than inserting manual breaks that behave badly when the screen rotates.

Controls need enough room for an imprecise thumb. Keep buttons and links at least 44 by 44 CSS pixels, with generous spacing between adjacent actions. Labels should remain visible when fields receive focus, error messages should sit near the relevant field, and the on-screen keyboard should not hide the button a reader needs next. Test the full task, including form entry and confirmation, rather than judging the design from a static home screen.

Avoid interactions that depend on hover, a long press or rapid tapping. Use obvious links for calls, directions and email addresses, and respect the reduced-motion setting for animated effects. Menus need a clear closed state and a target large enough to reopen without frustration. Native controls generally work better on ageing phones than elaborate custom pickers, and plain links can beat a JavaScript modal when the action is simple.

Build for Australian mobile habits

Australia’s mobile market makes a conservative technical baseline especially sensible. Android remains the largest platform here, and many capable Android phones are kept for years, while older iPhones are also common in the second-hand market and family use. Browser versions can be uneven, so test current Chrome and Safari, but do not assume every device receives the latest engine. Modern CSS is useful when it improves clarity, not when it becomes a prerequisite for reading the page.

Local mobile plans add another constraint. Prepaid data bundles from carriers such as Telstra, Optus and Vodafone can be generous, yet finite; a page that quietly downloads several megabytes of autoplay video can still burn through an allowance that a reader expects to use for maps or messaging. Honour data-saving preferences where possible, avoid video as an advertising background and make images and scripts scale down before asking the network to carry them. Saving the data remains welcome in regional Australia too.

Distance and settlement patterns create uneven coverage outside the capitals. On a drive towards the Great Ocean Road or across a remote stretch of highway, a mobile signal may disappear for long periods, so a visitor may open your page from a cached or intermittent connection. Keep the essential article available, make the layout resilient to a failed embed and avoid requiring a login or map script before the text appears.

In Melbourne and Sydney, one-handed browsing on a crowded tram or train rewards the same restraint. Buttons placed near the bottom of the screen can be easier to reach than controls fixed at the top, while a narrow navigation drawer can obscure more of the article than a simple list. Australia’s strong sunlight can also wash out a pale interface outdoors, so test contrast with the screen brightness raised. These practical checks matter more than an interface designed solely for a design tool’s desktop preview.

Keep the promise after launch

A device test should cover content, not just the home page. On the old handset, open several article types, an archive page, a search result and any form. Load the site on mobile data, rotate the device, dismiss the cookie notice and try the main navigation. Look for sideways scrolling, clipped text, overlapping controls, sticky elements covering content and buttons too near the edge. Repeat after a week of use, because caches and background processes change the conditions.

Build in graceful fallbacks. If an image cannot load, its caption and surrounding text should remain meaningful. If JavaScript is blocked, the article should still be readable and its links should still work. If a third-party service fails, the page should continue rather than display an empty shell. This kind of progressive enhancement protects the core promise on ageing hardware and also helps visitors with unstable connections, regardless of where they live.

Treat performance and accessibility as continuing editorial work. A personal blog accumulates years of posts, images, embeds and redesigns, so a page that was light at launch can become heavy as the archive grows. Review new templates against the performance budgets, periodically sample real devices and remove assets that no longer serve a purpose. The archive of a personal site is valuable when the selection remains clear; the same discipline applies to what visitors have to download.

The standard is simple: a ten-year-old phone does not need a stripped-down web, only a complete, well-structured page delivered with respect for limited processing, data and attention. The measure of success is a site that remains worth opening when speed, memory and battery are no longer abundant.