How Can I Reduce My WordPress Site’s Server Response Time (TTFB)?

Emily Routledge

Active member
Registered
Joined
Aug 13, 2016
Messages
80
Points
8
I’m running WordPress on shared hosting and struggling to bring Time To First Byte (TTFB) below 300 ms. Which specific server-level configurations (e.g. switching PHP versions, tweaking OPcache settings, adjusting MySQL parameters) or host-side optimizations (like LiteSpeed, Redis, etc.) have you applied that made a real difference?

Thanks for any concrete examples or config snippets!
 

CharityHost_org

New member
Registered
Joined
Dec 17, 2024
Messages
5
Points
1
For large sites like woocomerce sites, Redis cache helps a lot but usually not available on standard shared hosting accounts. Having quality hosting, good servers and network is going to be very important as well, because you can tweak and tune the services all you want, but the quality of the server resources and network will be a limit there.
 

GreenhostCloud

Member
Registered
Joined
Feb 17, 2024
Messages
28
Points
1
I’m running WordPress on shared hosting and struggling to bring Time To First Byte (TTFB) below 300 ms. Which specific server-level configurations (e.g. switching PHP versions, tweaking OPcache settings, adjusting MySQL parameters) or host-side optimizations (like LiteSpeed, Redis, etc.) have you applied that made a real difference?

Thanks for any concrete examples or config snippets!
Switching to PHP 8.1+, enabling OPcache with higher memory (opcache.memory_consumption=256), using LiteSpeed with LSCache, and enabling Redis object cache significantly improved my TTFB. Also, optimizing MySQL with query_cache_size=64M and reducing autoloaded options helped a lot.
 

Maxoq

Well-known member
Registered
Joined
Feb 25, 2015
Messages
545
Points
28
Maxoq
Also, optimizing MySQL with query_cache_size=64M and reducing autoloaded options helped a lot.
Careful with that one now. The query cache is gone entirely in MySQL 8.0 and was already deprecated in 5.7, so on anything modern that line does nothing at best. On MariaDB it still exists but defaults to off, and turning it on for a WooCommerce site usually hurts: every write invalidates entries and the cache sits behind a single global mutex, so under load it becomes a queue.

If you can touch MySQL at all on shared hosting, innodb_buffer_pool_size is the one worth spending on. Rest of that post holds up, especially the autoloaded options point, which people skip because it is not a server setting.
 

Chris Worner

Well-known member
Registered
Joined
Apr 15, 2016
Messages
628
Points
28
Chris Worner
optimizing MySQL with query_cache_size=64M
query_cache_size does nothing on MySQL 8, the query cache was removed there, and on MariaDB it is off by default and usually stays off because the invalidation lock hurts on write heavy Woo carts. Leave it in my.cnf on MySQL 8 and the server refuses to start on the unknown variable, so check before copying that line over.

Same post, the opcache.memory_consumption=256 only counts if it actually applied. That directive is PHP_INI_SYSTEM, so it is ignored from .user.ini or ini_set on a stock setup and only takes effect from php.ini or the pool config. Load a phpinfo page and read the value the server reports, not the one you wrote.
 

OffshoreRacks

New member
Registered
Joined
May 12, 2024
Messages
7
Points
1
If host its running litespeed webserver, install litespeed cache plugin proferably before any other technique, PHP 8.1 as minimum, also no matter what you do on your site, if you have panel account for example you will never be in control of how much ram/cpu cores its assigned to your account so take this in mind also. Another tip its just to add your site under cloudflare DNS and hace CDN cache.
 

joschavz

New member
Registered
Joined
Sep 19, 2025
Messages
1
Points
0
From my experience with using Nexcess Servers, having Redis Cache, FastPixel for cache, and optimizing my images using either WEBP or AVIF boosted the speeds of my website. For websites in Hostinger under shared hosting, I had to use CloudflareCDN and WPRocket. Also, I like to keep my PHP version one sub-version away from the latest.
 

I Forgot

Member
Registered
Joined
Apr 19, 2016
Messages
24
Points
3
TTFB under 300ms on shared hosting is honestly ambitious because you're fighting against noisy neighbors and limited resources, but it's definitely achievable with the right optimizations. The single biggest impact I've seen is switching to a host that uses LiteSpeed with LSCache instead of Apache - I moved a client's site from traditional shared hosting to LiteSpeed and TTFB dropped from around 800ms to 200ms literally overnight without changing anything else. LiteSpeed has built-in caching at the server level that's way more efficient than PHP-based caching, and if your current host doesn't offer it, that alone might be worth switching hosts. If you're stuck with Apache, at least make sure you're on PHP 8.1 or newer with OPcache enabled because the performance difference between PHP 7.4 and 8.1 is substantial, sometimes 30-40% faster.

For OPcache specifically, most shared hosts have conservative default settings that you can improve if you have access to php.ini or can use ini_set in your wp-config.php file. Try setting opcache.memory_consumption to at least 128MB, opcache.interned_strings_buffer to 16, and opcache.max_accelerated_files to 10000 or higher. I had a WooCommerce site where just bumping max_accelerated_files from the default 2000 to 10000 shaved about 80ms off TTFB because it was constantly evicting cached files and recompiling. Also enable opcache.validate_timestamps=0 in production so it's not checking if files changed on every request, though remember you'll need to manually clear OPcache when you update plugins. For MySQL, if you have access to configuration, increase query_cache_size and innodb_buffer_pool_size, but honestly on shared hosting you probably can't touch these settings.

The other game-changer is implementing object caching with Redis or Memcached if your host supports it, because WordPress makes dozens of database calls per page load by default and caching those objects in memory is massive for TTFB. I set up Redis on a client's site that was averaging 600ms TTFB and it dropped to around 250ms just from eliminating repeated database queries. Install the Redis Object Cache plugin and make sure it's actually connected and working - you can check in the plugin settings. Also don't overlook simple things like enabling Gzip compression, making sure your wp-config.php sets WP_CACHE to true, and limiting the number of plugins because each active plugin adds overhead. I've seen sites where disabling just 2-3 poorly coded plugins that hook into every page load reduced TTFB by 100ms. Finally, if you're doing everything right and still hitting walls, shared hosting might just be your bottleneck - sometimes paying a bit more for VPS or managed WordPress hosting with better resource allocation is the only real solution when you've maxed out what's possible on shared infrastructure.
 

BlueLeaf

Well-known member
Registered
Joined
Apr 11, 2017
Messages
218
Points
18
Been in that boat. On shared hosting, I’ve had small wins just by trimming autoloaded options in wp_options (some plugins dump a lot in there). If your host allows.user.ini, setting opcache.memory_consumption=128 and opcache.max_accelerated_files=10000 helped me get around 80–100ms improvement once on a bloated Woo site.
 

Proxysolid

Real Mobile & Residential Proxies – Spain & World
Collaborate
Registered
Joined
Oct 29, 2025
Messages
21
Points
1
Honestly, it's quite complicated. Reducing TTFB on shared hosting is difficult because many problems stem from the provider itself. I'd suggest optimizing a few simple things.

Use LiteSpeed + LSCache (if your hosting provider offers it). It usually reduces TTFB significantly more than Apache or Nginx on shared plans.

If you can, remove (or replace) resource-intensive plugins or those that query MySQL excessively. Just remember that each query adds milliseconds.

Redis only helps if it's local; remote Redis tends to worsen TTFB.
.
 

VPS Circlejerk

New member
Registered
Joined
Sep 28, 2025
Messages
6
Points
1
You should definitely ensure your opcache.memory_consumption is set to at least 128MB and bump opcache.max_accelerated_files to 10,000 to prevent your server from constantly recompiling scripts and evicting cached files.

If you have already optimized your database and plugins, you are likely hitting the physical resource limits of shared hosting where you are fighting "noisy neighbors" for CPU cycles.

Honestly, expecting sub-300ms response times on a cheap shared plan is like trying to win a Formula 1 race in a minivan.
 

PC Klinika™ Zagreb

New member
Registered
Joined
May 11, 2025
Messages
2
Points
1
Most of WordPress sites are already bloated and too dependent on plugins. Hosting it on a shared hosting and hoping for under 300 ms TTFB is kinda unrealistic unless its a static site consisting of text mostly.
Also since its shared hosting, even if you optimize to perfection, server response might lag.

On the positive side: TTFB is really not that important unless its some apsurd amount of time.
 

Innomax

New member
Registered
Joined
Apr 25, 2026
Messages
1
Points
0
On shared hosting, sub-300ms TTFB is tough, but we’ve seen gains by switching to PHP 8.1/8.2 and tuning OPcache (more memory, fewer revalidations). Hosts using LiteSpeed with LSCache perform better than typical Apache setups, and adding Redis helps reduce DB load. Also, cutting heavy plugins and using a lightweight theme makes a noticeable difference.
 
Similar Threads
Replies
14
Views
8,588
Replies
3
Views
3,758
Replies
14
Views
13,986
Replies
1
Views
2,553
Replies
2
Views
3,221

Latest Hosting OffersNew Reviews

Sponsors

Tag Cloud

You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.

Top