How to Optimize Your Server for Mobile Speed

Why Mobile Speed Is a Different Problem

Mobile speed is dominated by network conditions, not server CPU. A cellular connection has meaningfully higher round-trip latency than a wired desktop connection, and its bandwidth swings constantly as a phone moves between cell towers, switches from 5G to 4G, or shares a congested tower with hundreds of other devices. That changes which optimizations actually move the needle: a server with idle CPU and 20ms average response times can still feel slow on mobile if the page requires a dozen sequential round trips to render, because each one of those trips now costs 150-300ms of latency instead of 20-40ms.

This is why the fixes that matter most for mobile are the ones that reduce the number of round trips and the number of bytes sent, rather than the ones that shave milliseconds off PHP execution time. Multiplexed connections, compressed responses, correctly sized images, and a fast first byte all compound under high latency in a way they simply do not under a low-latency wired connection. The rest of this article works through those five levers in the order they typically pay off, from the connection-level protocol up through the front-end payload.

Enable HTTP/2, and HTTP/3 Where You Can

HTTP/1.1 opens a new TCP connection (or queues behind a small pool of them) for every batch of assets, and on a high-latency mobile link that connection setup cost is paid over and over. HTTP/2 multiplexes many requests over a single connection, so the browser stops waiting in line for CSS, JS, and images one at a time. On a CloudStick server, HTTP/2 is enabled per site in the Nginx virtual host, which lives at /etc/nginx-cs/extra.d/<sitename>.d/ssl.conf on the underlying Nginx 1.24 (nginx-cs) install:

HTTP/3 goes further by running over QUIC on UDP instead of TCP, which removes head-of-line blocking entirely and recovers faster from the packet loss that is common on cellular networks. It needs a QUIC-enabled Nginx build, so on stock Nginx 1.24 it is not available out of the box the way HTTP/2 is; treat it as the next upgrade to plan for rather than something to force through a patched build on a production box today. HTTP/2 already captures most of the mobile latency win on its own.

Turn On Brotli Compression

Brotli compresses text-based responses — HTML, CSS, JavaScript, JSON, SVG — noticeably tighter than gzip, typically 15-25% smaller at an equivalent compression level. On a mobile connection where bandwidth is the constraint rather than server CPU, every kilobyte you shave off a render-blocking CSS or JS file reaches the browser sooner. Brotli is configured per site in the same ssl.conf file used for HTTP/2:

A comp level of 4-6 is a sensible default: it gets most of the size reduction Brotli offers without the CPU cost of the highest levels, which matters if the same server is also compressing on the fly for a lot of concurrent mobile requests. If your site already serves pre-built static assets, brotli_static on; lets Nginx serve a pre-compressed .br file straight from disk with zero runtime compression cost at all. On CloudStick, the SSL settings panel for each site includes a Brotli toggle that edits this same directive block and reloads Nginx automatically, so agencies managing dozens of sites do not need to SSH in and repeat this edit one server at a time.

Serve Responsive, Modern Image Formats

Images are usually the single largest payload on a page, and a desktop-sized hero image downloaded onto a 390px-wide phone screen is pure waste — bytes the mobile connection pays for in transfer time that the display never uses. Fixing this is a front-end change, not an Nginx directive, but it is one of the highest-leverage things you can do for mobile speed:

The browser reads the sizes and srcset attributes and downloads the smallest image that satisfies the actual rendered dimensions on that device, and it picks AVIF or WebP over JPEG whenever the browser supports it, since both formats produce meaningfully smaller files at equivalent visual quality. For WordPress sites, this is normally handled by a caching or image-optimization plugin rather than by hand-writing markup on every page — CloudStick's WordPress Manager includes a caching optimizer for the server-side half of this, while the image conversion and srcset generation itself is typically a plugin's job sitting on top. loading="lazy" on below-the-fold images means the browser does not spend mobile bandwidth downloading images the visitor has not scrolled to yet.

Cut Time to First Byte and Defer Non-Critical JS

Any delay on the server side gets amplified by mobile round-trip latency, so time to first byte (TTFB) matters more on a phone than it does on a wired desktop connection to the same server. Measure it directly rather than guessing from a Lighthouse score alone:

A TTFB above roughly 200-300ms usually points at PHP-FPM being starved of workers under load, a slow database query on the request path, or missing page-level caching — the same stack CloudStick's Nginx-to-Apache-to-PHP-FPM proxy path (nginx-cs to apache2-cs on port 81 to PHP-FPM over a socket) serves every request through, so a caching layer in front of PHP execution helps every request rather than just some. On the front end, defer or async-load anything that is not required to render the first screen:

Deferred scripts let the browser parse and render the page before it downloads and executes analytics tags, chat widgets, or anything else that is not part of the first paint, which matters even more on mobile CPUs that are slower than desktop CPUs at parsing and executing JavaScript.

Test Real-World Mobile Performance

None of the changes above matter until you confirm them under realistic mobile conditions, not just from your office Wi-Fi. Chrome DevTools has a built-in network throttling profile for "Slow 4G" and "Fast 4G" under the Network tab, and running Lighthouse with mobile emulation gives you a repeatable performance score plus a prioritized list of what is still costing you time:

Lab tests like Lighthouse are useful for catching regressions before you ship, but they run on a fixed simulated connection and cannot see what your actual mobile visitors experience across real carriers, real signal strength, and real device hardware. Google PageSpeed Insights reports both a lab score and, when there is enough traffic, real-world Chrome User Experience Report (CrUX) field data broken out for mobile specifically — that field data is the number to trust when lab and reality disagree.

In practice, work through these fixes in the order they appear here: confirm HTTP/2 is active, confirm Brotli is compressing text assets, fix oversized images, then chase TTFB and script loading. Each layer compounds with the ones before it, and because mobile latency amplifies every extra round trip and every unnecessary byte, the combined effect on a real phone over real cellular data is consistently larger than any single change measured in isolation. Re-run the Lighthouse mobile score and a PageSpeed Insights field data check after each change so you can see which fix actually moved the number, rather than assuming.