A server problem, not a cosmetic one
Response time was the same on slow mobile and on fibre, so the problem was the server.
A sports newsroom serving 7.3 million requests a month on a server that took 3.4 seconds to answer. We found the real bottleneck, rebuilt the caching around it, moved the whole thing to AWS, and came out the other side with more search traffic than we went in with.
The server took about 3.4 seconds to answer before a single pixel reached anyone.
Unánimo Deportes is a sports news portal for US Latinos, run as a live newsroom with a wire importer that never stops. It served 7.3 million requests and 135 GB a month from origin, over 16,000 articles, and Google had flagged its Core Web Vitals as failing.
Response time was the same on slow mobile and on fibre, so the problem was the server.
Every change had to coexist with editors publishing and the wire importer running.
Caching had to survive publishing all day, not assume a static site.
We measured the site in lab and field conditions until the cause was isolated, including testing a widely held belief, that a diagnostic plugin was slowing readers down, and showing with data that it was not.
The site was running a caching system that could not work with the server hosting it. We replaced that layer with one that serves static HTML without executing code on every visit.
Core, plugins, theme, database and media replicated into a controlled AWS environment without touching production at any point. The old host cut off large exports, so the 7.3 GB database traveled in verifiable, resumable ranges.
On hardware we control, the backlog that had been unreachable on shared hosting became routine. Image weight, the metadata Google reads, the live scoreboard and the way articles link into the statistics section were all worked in turn, each measured before and after.
The last piece was not code. We read three months of the site’s own search data and turned it into a short set of titling and structure rules the desk can apply to what it publishes every day, each one argued from the site’s own numbers.
Only what this project actually runs on.
The hard part was never the speed itself, it was holding it in a site that publishes all day. With the cache purging and regenerating continuously, 95% of visits are still served in under 22 milliseconds. The migration ran on 7 September and search traffic did not dip: the day of the cutover is the only one below average, and the next day was already above where the site had been. Since then the same two-core instance has been absorbing around 270,000 requests a day while we work on what the old host never allowed.
Tell us what you are building and where it is stuck. We answer within one business day.