Static or DB Drive? Convince me
I get myself into these arguments, well discussions that always turn into everyone believing their right without backing it up with anything tangible.
The question posed on my Discord Channel was:
"Which 5,000 post blog will return the best overall performance, a blog built using MySQL with something like WordPress or one built using a static site building tool, Textpattern, Grav, Hugo and so on?"
Interestingly there were a lot of comments supporting both, the main argument for a large database-driven site was mostly one thing:
Better indexing therefore faster searching and better experience for end-users.
On the other hand, the static site supporters said:
With NVMe, larger sites perform effortlessly even with a very high object count
Lower page load overheads make up for potentially less efficient out of the box indexing/caching
Many large WP site owners convert their pages to static content via a plugin, what does that tell you?
Interested in the views from folks here who may have experience with both. I have sites that use both, whilst the static sites way outperform the database-driven ones, they are too small to really compare.
Comments
My issue is "the best overall performance" is vague. Best overall performance, in what regard?
Take --
Build time:
SSG's typically build out the entire site (some are incremental) - meaning you have that overhead to consider, especially when you make a change that impacts all pages. WP/DB-driven is on-the-fly, so you don't have that overhead.
Concurrency:
With caching, it's really neck-to-neck. Without caching, static with 100% have many times more concurrency than WP. Simply, serving static files is much, much lighter than running PHP and querying a DB.
TTFB/Server Response Perf.:
Again, with caching, it'll be neck-to-neck. Without, static almost always edges out for reason above.
On-site performance (render, FCP, yada, yada):
Highly dependent, and the backend stack itself doesn't really matter past server response T. Some "static sites" are client rendered, call APIs client-side, so technically those will be slower.
There are far too many variables here. 5k posts isn't a whole lot. You could even locally index every one and run the search locally, in which case static is much faster. As you scale, it makes less sense and you'll want to offload. WP's default search is subpar, and typically at scale you'd offload to something like elastic search. A similar service, or custom API (that will naturally be faster w/ less overhead) is typically what powers static search
Not sure what this is referring to. Drive performance matters, yes, but it matters in both cases. Impact on WP/server side is arguably more
With caching, overhead is near-equal. Getting cache primed efficiently and handling cache-purges efficiently is another matter.
Many, many WP site owners also use 69 plugins, have "password" as their password, run around from Bluehost to Hostgator, presume Apache = slow, VPS = fast, etc, etc. What does that tell you?
Tl:dr; There's no "better" solution. It depends on your use case. Publishing a blog post every day? WP is probably better. Building a KB that never changes? Convert it to static, skip the hosting cost, and you also don't need to worry (as much) about security, caching, and maintenance.
All fair points.
The question was really about overall speed and searchability, the number can be whatever you want 5,000 or 50,000.
Essentially if you have a static site, say 5k pages in the content tree, will that cause the site to be slower than a DB driven alternative. No, because a visitor arrives at your site to be given a single page, the homepage. Moving between pages will likely have little difference, depending on how much content is on each and what amount of data it is being drawn from to generate it if not an entirely static page.
Will the ability to search be significantly longer than had it been in a DB, possibly. Again depends on how much needs to be searched.
Would the end-user really notice any difference if it was static or DB driven? That I can't say, not identified any very large static sites to test. Will need to do that out of curiosity.
I personally guess that speed really comes down to where a static site is being searched or generating pages using a lot of content it has to find in the content tree.
Speed? Mostly equal. Searchability? Depends, as noted.
Size of static site does not impact response time, only build time. w/ Caching, navigation speed is near identical.
Exactly. And implementation of said "search."
Yes, but again, depends on the implementation. I've had the pleasure(?) of working with some insanely sized WP sites - ie, have a site that's got 138k text posts alone - there is a noticeable delay when searching (~500-600ms, which honestly is pretty impressive). Had someone else, who was building a business directory, attempt to import every single business in California or something. Totaled around 16 million or so (he had actually wanted more). I recommended that he pursue a different solution, but he attempted to import it anyways, and got to around 1 million posts or so. Search time was around 2-5 seconds.
If he'd used elastic search, it would probably be a whole lot less.
Static will win for sure. File systems are essentially databases that have had way more battle testing than say mysql. mysql has good people working on it sure...but stuff like ext3/4 isn't just optimised it's kernel level optimised.
It is a bit of an apples v oranges though. You don't go for wordpress because of it's stunning speed.
Databases were built to address issues massive filesystem chains/tables couldn't. (ie, complex data retrieval and structured storage/relationships). That's hardly a fair comparison - 'static' is fast not because of it's faster filesystem/storage abstraction, but because the content is pre-rendered.
Save inodes too. 10 million posts would be better in a DB for example.
I know replies like this don't contribute much - but the first reply by @johnk covers all the high points, and I agree with what he's written.
For my use case (websites that get edited and updated regularly) - WordPress is a better option (again - for me). And I have looked for alternatives, tried several.
BikeGremlin I/O
Mostly WordPress ™
Why? admittedly I have not used many static site generators, the one I do (getkirby) is as easy if not easier than WordPress to update daily. I don't get edited and updated regularly as being a better option to use WordPress. Personal preference aside.
IMO if you consider the price-performance ratio, static should be better. You can easily build deploy your website for free using GH Actions, Netlify, CF Pages, etc. for free, and also deliver them super fast for free.
As already said: "it all depends!"
I have used wordpress for the past few years. the biggest change is that I have become a developer and I mainly use nodejs. In fact, I rarely share my ideas either. I'm a lazy person and I believe that knowledge has a price.
Action and Reaction in history
@Lee has a lot of money he can pay. he also slaps faces if he doesn't like what he hears.
Here are some of my reasons (probably doesn't fit every person, nor every use case):
Last but not least: quite good stability, performance and security.
Sure, if you install 89 plugins (even for the stuff that can get implemented with a few lines of code), if you don't test any updates in a staging environment (auto-updates), if you use admin-admin123 and similar passwords, don't implement any caching etc, you are likely to have problems.
But with a bit of caution and common sense, WordPress is not nearly as bad as many people make it be.
The bad:
When it comes to resource usage, it does relate to the above-noted pros: how much time you save thanks to the pros of WordPress, and is it more valuable than paying an extra XX dollars for a more powerful hosting service.
That's my view of it. I've tried to find a high-quality static HTML alternative, because I like set-and-forget stuff. But I couldn't find one that doesn't cost me a lot more in other places, even if it saves some time and money on updates and hosting. If I were better any good at coding, my preferences might have been a lot different.
BikeGremlin I/O
Mostly WordPress ™
Never really understood a point in these sort of "convince me" debates.
You do or don't. Be a man.
♻ Amitz day is October 21.
♻ Join Nigh sect by adopting my avatar. Let us spread the joys of the end.
Don't have as much money this week as last week. My stupidity has seen me purchasing an established UK hosting provider recently. The final bits of paperwork are with my solicitors, all on track and it should be complete early next week. I really need to stop and get out of this industry but when you show me a bargain..
WordPress with a full page caching plugin (eg. WP Super Cache) gives you most of the advantages of something DB-driven, plus many of the advantages of a static site. When a page is cached, it's served directly via the web server, without hitting any app code, as long as your Nginx/Apache/etc config is correct.
On the other hand, tracking changes to articles via source control can be very useful.
Daniel15 | https://d.sb/. List of all my VPSes: https://d.sb/servers
dnstools.ws - DNS lookups, pings, and traceroutes from 30 locations worldwide.