When a website is slow or stuck on mobile, the server tends to get the blame. On our own site, lyaandco.com, most of the problem lay elsewhere: here is what we found, fixed and measured, with before-and-after figures and what remains to be done.

The diagnosis: a fast server, a slow page on mobile

On 28 September 2026, we audited our own site just as we would a client’s. On desktop, the home page scored 92/100 in the Lighthouse audit tool. On mobile, lab-measured on simulated slow 4G, it dropped to 47/100: the screen stayed blank for 6.75 s and the main image took 10.9 s to appear.

The server’s build time was not the problem: it builds the home page in around 0.16 s, then as now. The time was being lost between the server and the phone’s screen.

A second symptom, reported the next day, was more puzzling: on phones, the site would ‘freeze’, and the first swipes did nothing. The culprit was a single line of CSS that fixed the footer at 60 px high, when its content is around 850 px tall on mobile. Combined with another rule in the theme, it created a second, invisible scrolling area, on phones and desktops alike: your finger was scrolling that hidden box, not the page.

Six common causes, and how we fixed them

• Nothing was compressed, and the browser received no caching instructions. Before anything appeared, the phone had to download 1,079 KB of stylesheets and scripts. Compressed, they would weigh around 210 KB: at 1.6 Mbit/s, that is roughly 1 s to download instead of 5.4 s. Text files are now compressed, and the browser is told how long to keep each file.
• Oversized images. On the Products page, two screenshots more than 2,000 px wide (540 KB) were displayed in a 282 × 152 px frame on mobile. Resized to 1,280 px and converted to WebP, they now weigh around 57 KB and 50 KB (−80%).
• Ghost images. A carousel contained 8 images with no file behind them. Each pointed back to the home page itself, so the server rebuilt it 3 extra times on every visit. They have been replaced with a transparent placeholder image embedded in the page.
• A third-party script that froze the screen. The analytics tool (177 KB) ran while visitors were scrolling and blocked the screen for up to 183 ms at a time, in lab tests on a throttled phone. We first deferred it until after the page had displayed. Since 29 September it also waits for a click on ‘Accept’. On a first visit, before any choice is made, the home page no longer contacts any outside domain; on 28 September it sent 9 external requests (analytics and fonts).
• A jumpy page. The home page slideshow had zero height until its script started, then suddenly grew to 400–680 px. Its height is now reserved from the outset, for each screen size.
• Fonts from elsewhere. The page still shifted as it loaded (a layout shift, or CLS, of around 0.3 in lab tests on a throttled phone): the fonts, served by an outside provider, arrived late and replaced the fallback fonts. We now host them ourselves, and on the home page the shift falls to around 0.02 under the same conditions.

For the scrolling issue, we checked 18 pages on mobile and desktop: no hidden scrolling areas and no horizontal overflow. A lesson in method: our first automated test scrolled the page programmatically and saw nothing wrong; we had to simulate real finger swipes.

Beyond the page: the server and third-party content

Sometimes the server really is at fault. On a website we host, it took 0.88 s to build the home page: the runtime engine was recompiling all its code on every visit. We switched it to a mode that keeps the compiled code in memory, and the server now builds the home page in 0.43 s, roughly half the time. On another site we host, the same change cut this time from 0.92 s to 0.38 s.

On the first site, some pages displayed news from many external feeds. For logged-in users, these feeds were fetched live on every page view, with no caching: if one source took several seconds to respond, the page waited with it. We now keep a local copy of each feed, refreshed every 20 minutes, with a strict time limit on each request; if a source fails to respond, the last good copy stays on display. For those users, the server now builds these pages in under a second, instead of several seconds.

The rule: anything that comes from a third-party site (news, fonts, analytics) can make your site as slow as the slowest of them. Host whatever you can yourself, and put a time limit on the rest.

A checklist for decision-makers

• Test it with your finger. Open your site on a phone, scroll, tap the menu.
• Insist on before-and-after measurements, on mobile, on a simulated slow connection, with the same tool and the same settings. Scores vary by a few points from one run to the next, so compare medians.
• After every styling change, check again on a small screen, at 360 and 390 px wide.
• Know the benchmark. According to web.dev (Google), the experience is considered good when 75% of real visits meet three thresholds: the main content appears within 2.5 s, the page responds within 200 ms and layout shift stays at 0.1 or below.

Where lyaandco.com stands as of 30 September

We used the same tool and settings as on 28 September (lab measurements, simulated slow 4G, median of three runs). The home page content has changed slightly in the meantime. The results:

• home page mobile score: from 47 to around 75 out of 100;
• first display: from 6.75 s to 2.81 s;
• main image: from 10.9 s to 5.4 s;
• layout shift: below 0.1 on every page measured.

On a first visit (nothing cached in the browser), lab-measured on simulated slow 4G with the same settings as on 28 September, the home page’s weight went from 2.64 MB to 1.09 MB. Part of that gain comes from the analytics script, which loaded by default on 28 September; without it, the reduction is still 56%.

What remains to be done: even in the lab, our main image is still a long way from the 2.5-second benchmark. Fonts now account for around 40% of the home page’s weight, which makes them the next avenue to explore. And only Chrome’s engine has been tested so far; other browsers and real phones still need checking.

Want to know what is slowing your site down? We can diagnose it, with measurements to back it up. Let’s talk.