4 ms·

> You don't have to do this 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 i

> You don't have to do this 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.

rapind 6y ago
> 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. 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).
- falcolas 6y ago
  > Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk 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.
  - yurishimo 6y ago
    A lot of them do it via special htaccess rules. Check the cache first for an html file, otherwise, fall back to PHP. If not, there may be a little php code running but generally much less than a “normal” request.
  - rapind 6y ago
    So I don't normally setup WP sites, but I have as a favour. A caching plugin just generates the HTML files and you configure NGinX / Apache to the appropriate directory. Historically I think most did it via .htaccess w/ Apache for shared hosts, but I've only configured it w/ NGinX. E.g. https://www.nginx.com/blog/9-tips-for-improving-wordpress-performance-with-nginx/#wp-super-cache https://www.nginx.com/blog/9-tips-for-improving-wordpress-pe... 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.
  - deleted 6y ago
    [deleted]
  - achairapart 6y ago
    Server rewrites. Usually they work adding rules to Apache .htaccess. 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.
  - kirstenbirgit 6y ago
    >I'd be very curious how a WP plugin is managing this. 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.
splatzone 6y ago
You touch on a really good point here about the default cron setting (yes, it still uses the lazy cron on page load by default.) From a developer point of view this is questionable at best, but from a business point of view I reckon decisions like these are the core of why WordPress is popular. 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
- falcolas 6y ago
  I realize that it's really written for end users instead of developers, but that means scares me every time I see something as high profile as the White House using it. For the exact reason as you say here: "it's easy to shoot yourself in the foot and get your site hacked". 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.
  - kijin 6y ago
    Hopefully the White House has access to someone who knows how to set up WordPress without shooting themselves in the foot. The fact that WordPress.com doens't get hacked all the time means that there are definitely people who know how to do it.
    - earthboundkid 6y ago
      Yes, but there are also a lot of people who don’t. I still use an RSS reader and basically every six months, a blog that I followed 5 years back and went dark will get taken over by spammers because no one was paying attention to it anymore.
kortilla 6y ago
> 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. 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.
- mudlark 6y ago
  Caching is hard. Drupal used to, may still use the dB for caches. So you get pool issues. You have to also throttle features, like site Search or other intensive scripts. So in the main the internal caching is a step up from none.

rapind 6y ago

> 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. 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).

falcolas 6y ago
> Page caching in WordPress is usually (always?) serving up the pre-rendered HTML direct from disk 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.
- yurishimo 6y ago
  A lot of them do it via special htaccess rules. Check the cache first for an html file, otherwise, fall back to PHP. If not, there may be a little php code running but generally much less than a “normal” request.
- rapind 6y ago
  So I don't normally setup WP sites, but I have as a favour. A caching plugin just generates the HTML files and you configure NGinX / Apache to the appropriate directory. Historically I think most did it via .htaccess w/ Apache for shared hosts, but I've only configured it w/ NGinX. E.g. https://www.nginx.com/blog/9-tips-for-improving-wordpress-performance-with-nginx/#wp-super-cache https://www.nginx.com/blog/9-tips-for-improving-wordpress-pe... 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.
- deleted 6y ago
  [deleted]
- achairapart 6y ago
  Server rewrites. Usually they work adding rules to Apache .htaccess. 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.
- kirstenbirgit 6y ago
  >I'd be very curious how a WP plugin is managing this. 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.

splatzone 6y ago

You touch on a really good point here about the default cron setting (yes, it still uses the lazy cron on page load by default.) From a developer point of view this is questionable at best, but from a business point of view I reckon decisions like these are the core of why WordPress is popular. 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

falcolas 6y ago
I realize that it's really written for end users instead of developers, but that means scares me every time I see something as high profile as the White House using it. For the exact reason as you say here: "it's easy to shoot yourself in the foot and get your site hacked". 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.
- kijin 6y ago
  Hopefully the White House has access to someone who knows how to set up WordPress without shooting themselves in the foot. The fact that WordPress.com doens't get hacked all the time means that there are definitely people who know how to do it.
  - earthboundkid 6y ago
    Yes, but there are also a lot of people who don’t. I still use an RSS reader and basically every six months, a blog that I followed 5 years back and went dark will get taken over by spammers because no one was paying attention to it anymore.

kortilla 6y ago

> 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. 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.

mudlark 6y ago
Caching is hard. Drupal used to, may still use the dB for caches. So you get pool issues. You have to also throttle features, like site Search or other intensive scripts. So in the main the internal caching is a step up from none.