Guides / Getting started
What a rider's phone downloads
We measured what small transit and heritage railway websites weigh on a phone, and what that costs a rider standing at a stop. The findings, and the five fixes worth doing first.
In August 2026 we fetched a handful of small transit agency and heritage railway websites the way a phone does: the page, then every script, stylesheet and image it asks for. Not a lab benchmark — just the bytes a rider's handset pulls down before a single departure time appears on screen.
We are not going to name them. Every one of these organisations is doing something difficult with almost no budget, and the person who maintains the website usually also answers the telephone. But the numbers are worth putting somewhere, because none of these problems are hard to fix and most agencies have never seen them measured.
What we found
| What we measured | What we found |
|---|---|
| Weight of one page on a phone | Median 1,348 KB. The heaviest was 3,190 KB |
| Heaviest single file | An 873 KB theme script on a page of route listings |
| Structured data | None. Not one machine-readable block across any site measured |
| Meta description | Missing on three of four, so search engines write their own |
| Telephone numbers | Printed as plain text on most, so a thumb cannot dial them |
| Pinch zoom | Disabled outright on one site |
| Viewport declaration | Absent on one ticket-booking page, which loads a desktop layout on a phone |
One agency's own homepage stated that the times printed on it were not correct and were in the process of being updated. That is not carelessness — it is what happens when the website is a second, hand-maintained copy of a schedule that lives somewhere else.
Why the weight matters more for you than for a city
A megabyte is nothing on office broadband. It is a different thing on a phone with one bar, at a shelter on a county road, on a plan where data is counted. The rider most dependent on your service — no car, older handset, edge of the coverage map — is the rider who waits longest for your page and is most likely to give up and ring the office instead. Which then costs your office a telephone call.
Almost none of that weight is information. It is a theme, a slider, two analytics tags, a maps library on a page with no map, and an icon font loaded for four icons. A timetable is text and a table. The information a rider came for is nearly always under 20 KB.
The five fixes, in the order worth doing them
- Make every telephone number a link. On a phone, a number written as text has to be memorised and re-typed; the same number in a tel: link is one tap. If you do nothing else on this list, do this one — it takes an afternoon and it is the difference between a trip booked and a trip abandoned.
- Put the times on the page, not only in a PDF. A PDF on a phone opens in a separate viewer, zooms badly and cannot be read aloud by a screen reader. Keep the PDF for printing if you like, but the page itself should carry the times.
- Delete what nobody looks at. A slider, a second analytics tag, a maps SDK on a page with no map. Every one of them is bytes a rider pays for and nobody reads.
- Write the one line under your title. Without a meta description a search engine invents one out of whatever is at the top of your page, which is usually your navigation.
- Add structured data for your organisation and your questions and answers. It is how a voice assistant answers a rider's daughter when she asks how her mother books a ride. Right now, for most small operators, there is nothing there to read.

What is reasonable to aim for
A timetable page has no honest reason to be heavy. As a reference point: our own rider pages come in around 64 KB across four requests, with no JavaScript at all — the fonts and the stylesheet are most of it. We are not claiming that as a feat of engineering. It is what you get when a page is text and a table and you stop putting furniture on it.
Whatever you run on, the target is the same: under 200 KB, no more than a handful of requests, every number tappable, and the times coming from wherever your schedule actually lives rather than being retyped by hand twice a year.
How to check your own
- Open your busiest page on a phone, on mobile data rather than the office wifi, and count how long before a departure time is readable.
- In a desktop browser, open the developer tools, choose the network tab, tick 'disable cache' and reload. The total transferred at the bottom is your number.
- Sort that list by size. Anything over 100 KB deserves a reason for existing.
- Try tapping a telephone number on the phone. If nothing happens, that is your first job.
- Search for your agency by name and read the two lines underneath. If they are your navigation menu, write a meta description.
None of this requires new software. It is worth doing whoever you buy from, and worth doing if you buy from nobody — which is why we have written down how to do it rather than only offering to do it for you.
Questions
Is a heavy website really costing us riders?
It costs you the riders with the weakest signal and the oldest phones, which for a rural operator is a large share of the people who most need the service. It also costs your office telephone calls from people who gave up on the page.
We only have PDFs. Is that so bad?
A PDF is fine as a printable handout. As the only copy of your times it is a problem: it does not resize on a phone, screen readers handle it poorly, search engines index it weakly, and it goes stale silently because nothing connects it to your actual schedule.
Our website is maintained by a volunteer. Where do we start?
Telephone links, then a meta description. Both are single-line changes in almost any website builder, and between them they cover the two things a rider does first: ring you, or find you.
How did you measure this?
We requested each page with a mobile user agent and then fetched every script, stylesheet and image it referenced, adding up the bytes. Anything a page loads later with JavaScript is not included, so the real figures are higher than the ones quoted here.
Read next
- Evaluating software you will barely useA buyer's guide for small agencies: the questions that actually predict whether a system will be used, the pricing traps to name out loud, and what to insist on in writing.
- Publishing GTFS when there are five of youA plain walkthrough of what a GTFS feed is, the seven files that actually matter, how to get yours onto Google and Apple Maps, and what breaks it six months later.