Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What's the answer to making WordPress sites faster?

I too have tried better hardware, CDNs, plugins like WP Super Cache, and others means of optimizing. Very little impact. Is the problem PHP?

I'm thinking of trying one of those plugins that convert the WordPress site to static web site. I'd imagine that'd have a big impact, at least for sites that don't need e.g. login, shopping carts, etc.



> Is the problem PHP?

PHP is fast for a dynamic language (compared to say Ruby/Python and even JS). It has the disadvantage that it gets slow by default the more code you have, because it has a static execution model.

WP is extremely bloated and slow though. You can only make it fast by telling Apache to not execute it and hitting your cache (or with a caching layer in front).

With heavy caching (flushed on data changes), hand written themes and plugins, modern build tools for frontend assets, image optimization etc. You can get get top metrics.

However, that's just frontend. The admin panel is always slow.

If your use-case allows it, you rather build one with something like hugo. Hugo and similar are very easy to use and net you much better results.

My general tip is to not build websites with WP if you have web development skills.


WordPress is very fast out of the box considering all its capabilities, it's not hard to get in the range of 100ms TTFB out of the box on dirt cheap VPS servers, which is pretty good in my book. The problem is that people add very heavy themes and plugins that push them well above acceptable TTFB numbers.

Full Site Editing with the new Gutenberg editor have amended a lot of that, it's very performant out of the box. Just as an example, I have a site averaging about 200ms for uncached requests, it has an FSE theme and 20 installed plugins, including heavy ones like ACF.

This is all out of the box without cache, but by adding a simple static page cache (either a plugin or something like Fastly, Varnish etc.) you can make it so that the p95 latency drops by 80-90% because most people will see cached page views any way.


The problem is architectural.

Wordpress at its core execute most of its user-facing code trough an un-parallelizable, self-modifying single threaded queue, which has to be run at every page reload[1] and everything and anything will have to inject stuff in it. From handling your pictures in your media library, to checking your server can actually send mails, to managing your page and posts content and layout, everything goes trough it. It's also a system that doesn't really play ball very easily with most PHP accelerators outside of baseline PHP opcache.

You may have better luck using a static cache or memcached. Depending on the theme you're using (90% of what's available from envato themeforest, for example) the improvement will be negligible due to the impact of all the uncachable third-party jquery plugins that are usually included on a commercial theme.

All of the data you're accessing is also for the most part queried from two tables of a single database instance[2] which again handles everything from your mail configuration, page routing and redirection, page layout, contents, stored forms, etc. No sharding, load balancing is natively available. Heck, most WP hosted solutions run MySQL on the same instance running Apache and PHP.

Also the data is usually stored as serialized php values, which have to be parsed and reformatted, again, at every page load using the system described beforehand.

[1]https://github.com/WordPress/wordpress-develop/blob/6.2/src/...

[2]https://codex.wordpress.org/Database_Description


The problem is the ecosystem. You can get response times for the main page down pretty low (especially with caching plugins) and the time to serve static assets is the same for Wordpress or a static site. Most likely if your site feels slow, the culprit is your theme and one or more plugins on your site. You can usually track down problem plugin(s) using PageSpeed Insights since their frontend assets are served from the plugin folders.


First, seconding everything dgb23 said in this thread.

I think if you don't have a need for that dynamic stuff, yes a static site generator is a slam dunk in my humble opinion.

The PHP/Wordpress model where pages are composited dynamically for each pageview was an idea that made sense 20+ years ago. Whereas today, regenerating 1000 (or 10,000) static HTML pages can be done in a few seconds anytime a new blog post is made, giving up-to-date sidebars, homepage and stuff. Other code which needs to be dynamic can usually be fully client-side. And for comments, I don't think almost anyone uses the WP comment feature anymore. It's either off due to spam, or delegated to Disqus or similar. That, combined with the constant stream of WP 0-day exploits, really argues for having your actual WP instance behind your firewall and serving your files from an S3 bucket or plain Nginx (etc).


Use a plugin like 'Cache Enabler' by KeyCDN, it's very lightweight and does exactly one thing very well.

Get rid of as many plugins as possible, many of them add a ton of load time and browser load. Woocommerce is especially bad.

Use a lightweight theme, there are a few good ones out there for that. Or just the default one it comes with.

And yeah if you have zero dynamic content needs then a static site generator can work fine. But with minimal plugins and a cache enabler, response time should be very fast anyways.


I worked on a Strattic conversion some time back - they basically scrape all your pages and serve them statically, but you do have to do some things to support search, forms, etc and you'll end up pruning plugins that don't work well with it.

But, serving static pages is very very fast afterwards.


Bet on Moore's Law and go fully dynamic.


I'll bet on future WP updates eating whatever perf improvements new hardware will give. Besides, Moore's Law is about the number of transistors. Speed - and especially single threaded speed which is what matters for PHP sites - is not going up nearly as fast anymore.


Yes, but practically speaking, waiting 20 years isn't an option. Moore's Law has stopped delivering rapid single-threaded performance gains and not everything is trivially parallelable.

The fastest single-threaded cpus today are only 2x faster than the fastest single-threaded cpus of a decade ago...


Mine renders pages in under 50ms under BAU load and it's hosted on a $1/month cPanel. The only trick I have used is to run it on PHP 8.1 with Lightspeed Cache


Redis or memcache plus a full page caching solution plug-in, mainly.


you also need a small footprint theme like (Neve), and customizing Apache with right modules to compress files, or with less customization ( nginx) might be faster




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: