This is incorrect. WP supercache generates static html that takes precedence over falling back to the php engine. This is the way it worked nearly a decade ago too.
I wish people wouldn’t spend so much effort bad-mouthing technology they don’t even understand. I don’t even like Wordpress but reading this is super annoying.
I'm not a big WP fan, but this statement is false in most cases. Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk (or CDN) without hitting PHP. Pagely (the post we're discussing) even handle that for you w/ their own CDN. I would imagine they also support request based caching and purging, warming, etc.
Most purely content sites (non-app) can run really well with a very simple TTL based cache (instead of long lived w/ complex flushing). You can very easily use something like Fastly for cloud based varnish w/ an appropriate TTL.
I also feel the need to point out that gatsby type sites and just pre-rendering / caching as well, at least in part (possible using json from a CMS for dynamic data).
I'd be very curious how a WP plugin is managing this.
Third party hosting building in caching, normal in-line caches (like Varnish), nginx/apache caching, sure - I get those, and they behave how you say. But a WP plugin? I'm curious how that would bypass PHP & WP entirely.
On the other hand, this trick was mostly useful years ago when shared hosting plans were really underpowered.
As of today, with improvements of both PHP 7.x and general server performance, even a cache system that uses PHP very early (before any DB connection) to load a pre-rendered html cache file goes a long way in terms of number of pages being served.
Actually, if this become your bottleneck, the .htaccess trick won't help a lot, and you would still look in tools like memcached, redis or reverse proxies to improve things.
I think a lot of third-party hosts provide this out of the box, maybe even using their own CDN. WP is so popular that it's be difficult not to find a service that handled it all for you so long as you have room in the budget.
If you don't know how the cache plugins do this, it's pretty obvious you are not very knowledgable about WordPress site operations. Please stop spouting falsehoods here.
You don't have to know what cron is to install a WordPress site. You don't have to know anything about git or setting up varnish. You just bung the files on your PHP server, put in your database credentials and away you go.
There is a big conflict here between what is practical for users and what is best practice for developers. WordPress has always put user experience first, to the point where it's easy to shoot yourself in the foot and get your site hacked by installing a bunch of badly made plugins. But this tradeoff in the favour of user experience had made it easy for millions of people to set up their own website, and is the reason WordPress is the most popular CMS in the world
Indeed. And so many commentators here on HN (myself included) bemoan FAANG centralization and wish for decentralization and federation and the like... well, this tradeoff is relevant in that matter.
What about the conflict between what is practical for users and what is best practice for users?
Security isn't just a developer's concern. Having to clean up a hacked WordPress site because of crappy defaults isn't very practical for users, either.
WP is absolutely NOT secure by design; it's a hot mess that has helped normalize ignoring security in our web applications. That we encourage its use, that we haven't replaced it with something better, is a damned travesty.
The fact that WordPress.com doens't get hacked all the time means that there are definitely people who know how to do it.
Regular reminder that wordpress.com is a different software product to wordpress.org :)
wordpress.com runs their (relatively) newer JavaScript-based stack; wordpress.org (which is what we're talking about here, unless I misread the article referenced here completely) is the LAMP stack version.
It's written in JavaScript; it runs on node.js - at least the front-end part of it (https://github.com/Automattic/wp-calypso). I don't know what is running on the backend but I don't think it's LAMP?
The point I was making though is that "WordPress" can mean two different things - wordpress.org (the self-hosted LAMP version) or wordpress.com, which is a SaaS offering (so the language is more or less irrelevant unless you're really interested in running your own admin frontend, I guess).
Calypso is our JS dashboard that lets you manage all your sites in one place, plus get cool WP.com features like stats and notifications. It's just a REST API client, just like the iOS and Android apps.
I updated my original comment here.
> A good practice is to set up your own cron job on the server and disable the internal cron in your wp-config.php
Defaults matter. And when I was working on it, this wasn't well documented anywhere. If it is now, great. It shouldn't be the default.
> Just install a page caching plugin of your choice[1]
A bad idea, IMO. It's still going through the PHP server and all of the routing/plugin/DB code within WP. Much better to use Varnish (and its ilk) and avoid overloading the PHP service.
> Or use a managed WordPress hosting service
Back when I worked for an remote DBA company, we were tapped many times to help optimize DB access by Wordpress. It reminded me that it's remarkably easy to start a WP hosting company, and remarkably hard to do it right.