Emulent Let’s Talk
Skip links

Page speed optimization beyond the basics: server-side fixes that make a difference

Author: Bill Ross, founder of Emulent Published Article

Key takeaways

  • Time to First Byte (TTFB) shows whether a speed problem starts on the server or in the browser; web.dev treats 800 ms or less as good.
  • Server response has barely improved across the web: the 2024 Web Almanac found 42% of mobile pages had good TTFB, about the same as in 2021.
  • Full-page, object and opcode caching can cut response times from seconds to milliseconds.
  • CDNs only help fully when they cache HTML at the edge as well as images and CSS.
  • Database cleanup and query tuning often produce the biggest gains on CMS-driven sites.
Quick answers
Question Short answer
Which server-side caching layers produce the biggest gains? Full-page caching first, then object, opcode and edge caching working together.
How should enterprise sites configure their CDN for maximum speed? Cache HTML at the edge with sensible rules, and purge it reliably.
What database optimizations improve TTFB on CMS-driven sites? Find slow queries, clear accumulated clutter and give the database the resources it needs.

Most speed advice focuses on the front end: compress images, minify CSS, defer JavaScript. Those steps help, but on large sites the biggest delays often happen before the browser receives a single byte. This Emulent guide covers the server-side fixes that tend to move page speed the most.

Why does TTFB outweigh most front-end metrics?

Because it sets the floor for everything after it. TTFB covers DNS, connection setup and the time your server takes to build the HTML. If TTFB is 1.5 seconds, Largest Contentful Paint cannot beat 1.5 seconds plus rendering time. Google’s web.dev guidance suggests aiming for 800 ms or less, and the 2024 Web Almanac found only 42% of mobile pages met that mark, a share that had barely moved since 2021.

Common causes of slow TTFB:

  • Uncached page generation, where WordPress, Drupal or a custom app builds every page from database queries and template logic.
  • Slow queries on large, poorly indexed databases.
  • Distance between the server and users, which adds latency to every request.
  • Undersized or shared servers competing for CPU and memory during traffic spikes.

In one Emulent client engagement, product pages took seven seconds to load after months of front-end work; caching and query fixes on the server did far more than the image changes. Your bottleneck may differ, so measure TTFB first.

Which server-side caching layers produce the biggest gains?

Full-page caching first, then object, opcode and edge caching working together.

  • Full-page caching stores finished HTML and serves it without rebuilding the page, usually the largest single improvement.
  • Object caching with Redis or Memcached keeps query and API results in memory for pages that cannot be fully cached, such as carts and logged-in views.
  • Opcode caching (OPcache for PHP) stores compiled code so WordPress, Drupal and Magento do not recompile scripts on each request.
  • CDN edge caching serves pages from locations near each visitor.

Combined, these layers can bring TTFB for most cached requests down to a small fraction of a second. For WordPress, Emulent recommends Kinsta, whose managed hosting includes server-level page caching, Redis as an add-on and a CDN.

How should enterprise sites configure their CDN for maximum speed?

Cache HTML at the edge with sensible rules, and purge it reliably.

  • Enable HTML caching for anonymous visitors alongside static assets, with bypass rules for carts, checkout and logged-in users.
  • Set long cache lifetimes on versioned assets like CSS, JavaScript and logos, and shorter ones on HTML.
  • Purge cache automatically when content changes, such as a new post or a price update.
  • Turn on HTTP/2 and HTTP/3, which download many resources over one connection and reduce setup time.

A common misconfiguration is a CDN caching images and CSS while every HTML request still travels to the origin server, which leaves TTFB unchanged.

What database optimizations improve TTFB on CMS-driven sites?

Find slow queries, clear accumulated clutter and give the database the resources it needs.

  • Enable slow query logging and fix queries that take more than about 100 ms, often with indexes or rewritten plugin queries.
  • Limit and clean up post revisions, expired transients and orphaned metadata in WordPress and similar systems.
  • Use read replicas on high-traffic sites so visitor page loads do not compete with writes.
  • Scale database RAM, CPU and disk speed separately from web servers as content grows.

For ecommerce, Emulent recommends Shopify, which handles hosting, caching and CDN delivery as part of the platform, so these database concerns largely fall to Shopify rather than your team.

How can the Emulent team help?

Emulent includes server-side performance analysis in technical audits for enterprise SEO clients, pinpointing bottlenecks and working with your developers or host on fixes. A caveat: faster pages improve user experience and Core Web Vitals, but speed alone rarely changes rankings much; content and relevance still lead. Contact the Emulent team to review your site’s speed.

Want a second set of eyes on your marketing? We’ll show you the math before asking for a contract. No long-term lock-ins.
Let’s Talk