The Train Has No Signal and Neither Do Your Readers: A Website Field Test from Crewe to Carlisle

I like a train window. I also like a website that works when the train window is the only thing I have. Last Thursday I took the Crewe to Carlisle line — the slower, prettier one up through Wilmslow, Stockport and Manchester, then on past Oxenholme and Penrith — with my laptop shut and my phone in hand. The plan was simple: use the journey as a proper field test for russellfutcher.com. Not on office fibre. Not on a pretend “slow 3G” setting in a developer tool. On actual, patchy, apologetic mobile data, with an older handset and a seat that gave my elbows nowhere to go.

I had a short list of pages: the home page, the latest article, the side projects page, the contact page and one older post with a lot of images. I wanted to know what loaded, what stalled, and what made me sigh. The answer was mostly encouraging, with a few bits I have now fixed.

The rules of the test

I gave myself three rules. First, no cheating: no switching to the train’s onboard Wi-Fi unless my mobile signal had completely died. Second, no refreshing like a nervous driver. If a page took longer than ten seconds, I noted it and moved on. Third, I had to use the site as a reader would — not as the person who built it. That meant tapping the first thing that looked interesting, not the page I knew was lightweight.

The handset was an older iPhone SE, which is not ancient but is not a flagship either. The seat was a fold-down table with about as much room as a paperback. The signal came and went in the familiar rhythm of a UK intercity run: fine outside Crewe, useless in a cutting, triumphant on a viaduct, gone again behind a hill near Shap.

What loaded, what stalled

The home page was fine. That pleased me more than it should. The text appeared almost immediately, the navigation was readable, and the main image — a fairly modest JPEG — arrived in a few seconds. On a bad stretch near Wilmslow it went text-first, then image. That is exactly the order I want. A reader can start reading before the decoration turns up.

The latest article was also decent. I had already cut a lot of the fat earlier this year: no web fonts, no carousel, no pop-up asking for an email address before I had read a single paragraph. The page held its shape while loading. Nothing jumped about. The paragraph I was reading did not get yanked down the screen because an ad or a cookie banner had finally woken up. That matters more than any speed score.

The older image-heavy post was the weak point. Not catastrophic, but noticeably slower. The images were too large, and a couple were loading even though they were far below the fold. On a good connection you would never notice. On a train near Penrith, you notice. You notice the blank spaces, the delayed layout, the little jolt as each picture arrives. I made a note: resize, compress, lazy-load the lot below the first screen.

The contact page was the real embarrassment. The form itself loaded, but the submit button sat there looking confident while the network coughed. I tried it twice. The first attempt spun. The second worked. That is not a disaster, but it is not good enough. If someone is on a patchy connection and wants to send me a message, the least I can do is give them a plain email address as a fallback. I have now added one, visible without JavaScript and without a form.

The small things that made a difference

A few changes have already gone in. I switched the remaining font loading to system fonts, which means the site now uses whatever the phone already has. It looks slightly different on every device and I have made my peace with that. I reduced the homepage image by about half. I added proper width and height attributes to images so the page does not shift about while things arrive. I made the navigation work as ordinary links, not a JavaScript menu that waits for a script to wake up. And I wrote a short, plain contact line: “Email me directly if the form is playing up.”

None of this is glamorous. It is the website equivalent of checking the tyres before a long drive. But the train test made the case better than any dashboard could. Most website audits happen on fast office broadband, on a large monitor, with a cup of tea and no time pressure. Actual readers are on patchy mobile signal, older phones, cramped seats and a vague sense that they might be about to miss their stop. They do not care about your Lighthouse score. They care whether the words turn up.

A short checklist for independent sites

If you run a small site — a personal site, a portfolio, a side project, a one-person shop — here is the checklist I would tape to the inside of my laptop lid.

• Serve the text first. Let the pictures follow. A reader who can start reading is a reader who stays.
• Use system fonts or one lightweight font. Two custom fonts is usually one too many.
• Resize and compress images before they go anywhere near the site. Then lazy-load the ones below the first screen.
• Keep JavaScript for things that genuinely need it. A menu does not need it. A contact page does not need it.
• Always offer a plain email address as well as a form. Forms fail. Email is stubborn.
• Set image dimensions so the page does not jump around while loading.
• Test on a real phone, on a real train, in a real seat, with the signal coming and going. Not just in a simulator.
• Make sure the site is readable at 10% signal. If it is not, cut something.

I got off at Carlisle with a flat phone battery and a slightly better website. The journey took four hours. The fixes took about ninety minutes. That feels like a fair exchange. Next time I might try the Settle to Carlisle line and see what happens when the signal is even worse. I suspect the site will be ready. I am less sure about my elbows.