I then tested on a lower performance server which costs £80 per month at Vultr and again couldn’t detect any difference when in the back-end.
No matter what performance tuning I done, I couldn’t make it work faster for us. But at least I am on an £80 server instead of a £500 server I guess.
Thanks for WordPress - it's great. I think I first started 'using' it around 2006/2007ish.
What really happens if you decided you didn’t like the products a website sold?
…Would you give them the time to move and take their backups with then or would you immediately hit the delete button on their data?
These are the reasons we switched to self-hosted Wordpress in the beginning. You don’t need to be on HN for long each day to see the same stories being told continuously about how the big guys treat the wee people.
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.
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.
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).
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.
But, serving static pages is very very fast afterwards.
The fastest single-threaded cpus today are only 2x faster than the fastest single-threaded cpus of a decade ago...
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.
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/...