I don't like Wordpress either, but correctly configured it's not that much worse than a static site.

Correctly configured it is a static site with a minimal stub in PHP.

And if you want to go further you can bypass that stub and serve the static pages directly from your web server.

Best of both worlds, really.

> Correctly configured it is a static site with a minimal stub in PHP

Maybe there's a 1001 plugins being used which means the Wordpress site has to make boatloads of requests to the backend. Many Wordpress sites make that mistake. I keep my plugin count to at least five plugins. And they're obviously plugins which I really need, and they're not chatty in any way.

But the sites that are slow or performance sensitive often aren't just static sites. If it's more than just a simple CMS to you, you need to be enough of a WordPress expert that you probably don't need WordPress in the first place (or you're just using it for the themes or plugins). Weird WP performance cliffs are hard to avoid for dynamic content and "correctly configuring" either means rolling a custom solution or getting neck deep in your infra—both of which smell a lot more like engineering than not.

I've only run one wordpress site (and reluctantly), but I found it very hard to configure correctly. I was very happy when I was able to convince my boss to replace it with a much simpler blog system that only supported exactly what we needed.

A raw HTML file won’t scale if it’s served from a potato. ;) This probably has more to do with the host & servers than WordPress.

The energy derived from a potato should probably be enough to serve a static webpage with 100 req/s. Even the highest-ranking HN posts should not result in more than five requests per second. It's beyond me how the "HN hug of death" has ever come to be an issue in any scenario.

you couldn’t be more wrong. wordpress is one of the easiest apps to scale, put a varnish in front of it as you mostly have static content. you can go even further, move the comments to an external tool and you can have a very long cache.

"Jira scales. You just need to put a varnish in front and move the comments to disqus"

no, it doesn’t. the content from jira is very dynamic and adding a reverse proxy will not help as much as it will help with a cms.

All your comment has communicated is that Varnish can scale. Wordpress is not Varnish.

The gp isn't "wrong": putting Varnish in front of WP is a possible solution to the fact WP doesn't scale, not a disproof of the fact.

Furthermore it's a highly limited solution: WP is only static if you limit it's use to its static features, and configuring Varnish for the unholy mess of 3rd-party dynamic/interactive/form-handling WP plugins is nightmare territory.

Wordpress doesn't scale.

Producing cache friendly output is how you scale easily.

A content management system that doesn’t produce cacheable html isn’t scalable and one that does is. It’s not the job of the content management system to serve the cached pages. That’s what CDNs, browsers, and caching layers in general are for.

Caching is one facet of scaling (albeit a large one). It's not necessarily the job of a CMS to serve cached pages but there's a bunch of other considerations in scaling, particular where database writes are concerned; something that will be relevant in a system where users post content.

Also, see the final paragraph of the comment above for discussion of the extent to which WP "produces cachable html"