We've all experienced it.
Websites suddenly becoming slow for no reason, loading times in the double digits, or even the dreaded "Error establishing a database connection". It may come down to the hosting provider you are using, the size of your website, or even the complexity of your aesthetic design, but the crux of the matter is that:
WordPress is ageing.
Running on code first written in 2003, it was designed for a time in the evolution of the internet when waiting minutes for a website to load was not uncommon. We weren't as dependent on the internet then. But now? As a tech generation becomes more and more impatient, website loading times are becoming a crucial factor in the design process of a website, even being factored in by search engines when ranking.
So what's the solution to this problem? Static Site Generators! (surprise, surprise).
But to understand how SSGs work and how they solve WordPress' problems, we first need to understand how WordPress works, and why this is causing slow websites.
How WordPress Works
A typical, barebones website consists of HTML (for the content and structure), CSS (for the design), and JS (for any logic or processing). For anyone starting out in Web Development, the normal inclination would be to write a separate HTML file for every page on your website. We would call this a static website.
Simple enough: you get easy customisation, no complex scripts to slow your site down, and a compact website that doesn't take up much space. Sure, this works for a simple website with 5 pages. But what about a blog with 50 posts? Or an e-commerce website with hundreds of products? I'm sure you can see where I'm going with this. With all these examples, sure, you can copy and paste a blog post template and edit the contents each time you want to write a new blog post, but that's taking away precious time. Time you could be spending writing blog posts.
WordPress solves this problem by (and I'm massively oversimplifying here) storing page and blog post data in a database, separate from the styles. When a user visits a page on the website, WordPress executes PHP code, retrieving data from a database, and assembling this data into HTML and CSS. This is an example of what we call a dynamic website.
All this code has to execute before the website has been rendered, while the user is waiting for the page to load, in a context where 40% of people will abandon a website that takes more than 3 seconds to load.
An optimised WordPress website with the best hosting and minimal assets will take about 1-2 seconds to load. But a website with cheap, low-cost hosting (the type most of us bloggers/portfolio owners will probably use) will take about 4-5 seconds!
Static Site Generators
Now, instead of retrieving data from a database and assembling HTML and CSS each time a website loads, imagine if we just prebuilt this HTML and CSS before the user visited the website, and stored this instead. Instead of executing code, we deliver these files as-is when a person visits our site. This processing happens before the user visits the site, meaning the files are ready to be served as soon as a request is made.
Think of an SSG as an application that inputs website data and outputs a folder with all the HTML, CSS, and assets.
Therefore, while with WordPress we speak of load time, with Static Site Generators, this becomes almost negligible, and we shift our focus to build time.
Static Site Generators are relatively new - below is the growth in popularity of the search term "Static Site Generator":
PROS
Performance
Because Static Site Generators prebuild websites before they are requested by users, load times are cut from several seconds to mere milliseconds!
In-site navigation is also unbelievably fast. In fact, navigating from one page to another is almost instantaneous (Try it now! This website is powered by an SSG). This is because the SSG I use (GatsbyJS) prefetches the files and assets of other pages on the website so that by the time you want to go to another page, it has everything ready!
Security
Databases, servers, and outdated software running on them are a hacker's dream. A study found that about 70% of WordPress websites had a security vulnerability!
The reason is simple - the more servers involved and the more processes and executions done by a server, the more loopholes and vulnerabilities can be found.
But by preloading our pages, we eliminate the need for any logic and work to be performed, thereby eliminating the risk of hackers injecting malicious code into these processes.
Cost
To run a self-hosted WordPress website, you need to spend on average $5-10 a month on hosting plus about $10 annually for a domain. All in all, you could easily spend over $100 a year. With Static Site Generators, this goes down to $0 (or \$10 a year for a custom domain).
Because no processing power is needed, you can host your website on free hosting providers like Netlify and GitHub Pages.
Version Control
Most Static Site Generator websites are published by pushing code to a remote git repository, where it is automatically built and deployed. Apart from making the deployment process easy, this makes it easy to revert to a previous version of your site should the need arise.
But, as with anything, Static Site Generators also have some:
CONS
Pretty steep learning curve
(Unless you are already a programmer).
One of the reasons WordPress is so popular is its relatively shallow learning curve. You get a GUI, a dashboard, and a text editor - literally everything short of a WYSIWYG editor.
Static Site Generators require writing content in Markdown - not very intuitive for the average person.
Add to this their relatively small community compared to WordPress, and this makes the learning curve that much steeper.
No built-in commenting
One of the many side-effects of not running on a server is that you don't get any services out of the box that require processing. That means comments, search, and most forms of contact forms will need third party services. A popular free third-party commenting service is Disqus.
Updating and Publishing the site requires tools on your computer
This means that you can only update your website from a computer that has that particular Static Site Generator installed - plus other dependencies. A WordPress site, however, can be edited from any computer with a browser and an internet connection.
Common Static Site Generators out there
-
Based on react and running on Javascript, GatsbyJS is very easy to transition to for existing web-developers who have already been working with Javascript. What makes it a popular choice is that it can be used to make Progressive Web Apps (PWAs), and its websites are designed to be very fast for users. The gatsby-plugin-image plugin (and its predecessor, gatsby-image) give GatsbyJS image-optimisation out of the box, with features such as resizing, blurring, and preoptimisation. GatsbyJS also has a very rich ecosystem with clear and comprehensive documentation, and a fast growing community on GitHub. This all helps make GatsbyJS sites (like this one) faster for users than websites made by other Static Site Generators.
Examples of websites powered by GatsbyJS are: Airbnb's Engineering and Data Science website, Figma, ReactJS, Hopper.
To get started with GatsbyJS, head to Sitepoint's tutorial, Scott Spence's tutorial, and GatsbyJS' official Quick Start page
-
Hugo's strong point is that it is fast. Built with Go, Hugo websites often take milliseconds to build (compared to 30-60s for GatsbyJS). This is good for deployment and hosting services like Netlify, which allots 200 free build minutes a month and charges for minutes over this. Go, however, is not as ubiquitous in the Web Development space as Javascript, so this may be a turn off for some.
Examples of websites powered by Hugo are: Bootstrap, Kubernetes, Ghost,and CoreUI.
To get started with Hugo, head to The New Stack's Hugo tutorial, and Hugo's quick start page.
-
Being one of the earlier ones (made in 2008), Jekyll popularised the concept of a Static Site Generator. Running on Ruby, its shallow learning curve and its relative maturity make it a popular choice for many web developers. While other Static Site Generators have come on the scene, Jekyll remains widely used in the Web Development space.
Examples of websites powered by Jekyll are: Ruby on Rails, and Frame AI.
To get started with Jekyll, head to Open Source's Jekyll tutorials, Tania Rascia's tutorial, and Jekyll's official tutorials.
-
Billing itself as a simpler Static Site Generator, Eleventy is a Static Site Generator for those that just want the job done. Eleventy improved on the main problems with other Static Site Generators like Hugo and Jekyll. Jekyll has been around for some time, but it is viewed as too slow for some. Hugo is fast, but it requires using Go, a programming language that is unfamiliar for most Web Developers. Eleventy is fast, and uses Javascript, a language that most Web Developers already know.
An example of a website powered by eleventy is their website.
To get started with Eleventy, head to Craig Buckler's tutorial, Tatiana Mac's tutorial, and Eleventy's official getting started page.
Conclusion
You can find a more exhaustive list of Static Site Generators at staticgen.com. If you are interested in adapting your website to Static Site Generators or making a new one altogether, visit this page which talks about JAMstack, the greater movement behind Static Site Generators, and a new approach to web development that creates faster and more secure websites.
Subscribe at darrendube.com for more posts like this
Top comments (39)
I am confused, did I miss the part where you simply cache pages on WordPress so you don’t hit the database?
I mean they even make the plugins for page caching “non tech” friendly, unlike SSGs.
I mean that is the whole argument for a static site generator presented here, that you are serving static files?
Other than cost, which is a valid reason for micro sites, distribution to CDNs and not needing a database are the big winds for SSG surely?
Don’t get me wrong I am not a fan of WordPress but I have seen it run sites that have thousands of visitors on modest hardware.
Wordpress sites are slow due to crappy plugin choices, bloated themes etc. It is not WP itself that is slow and trust me I have seen enough sites on SSG be slow as well as the front end tends to be the bottleneck.
Yeah, but I sort of feel that caching is like dealing with the symptoms of the problem instead of the underlying problem (if that makes sense). I do agree with the fact that SSGs are not for everyone, but developers might work better with them than WordPress
A static site generator is literally a site like wordpress but with an extra build step. Wordpress + caching takes that build step away.
If you ignore all the problems with WordPress, then yeah.
I hear you on that. Jamstack is missing the great user experience that WordPress enjoy in exange for developer's experience. Headless CMSs are closing the gap, but there's still a big gap there. Especially in regards of dynamic data rendering. On the other hand, I sees amazing possibilities from decoupling the front-end from the data/API. This is where I'm investing and I feel there is so much that remains to be seen in that area.
The problem is that a major cache plug-in for WP just released an update with a bug that broke caching in an impossible to debug manner. This just isn't an issue with SSGs. Plus there are plugin vulnerabilities, etc.
That still isn't a WordPress problem as per my first answer.
It is a plugin problem and SSGs will suffer a similar fate with broken plugins as they gain popularity and people with less experience start developing with them.
As for plugin vulnerabilities, SSGs use plugins too and most are served via something like npm (which can be an additional vulnerability as people just blindly trust packages).
Yet again I would stress I am not a fan of WordPress but none of the issues are an issue with WordPress itself and SSGs are far from immune, they are just not widely used enough to justify the effort of attacking them (yet).
I understand what you're saying, and WP isn't inherently bad.
There is something different about the dependencies, though. WP plug-ins are code running on your production server. That is inherently more dangerous (to my server) than an npm script that runs in the browser, or a plugin that emits static HTML code that I upload to S3. The npm script can't bork my production DB and take down my site because there isn't a production DB (speaking strictly about page/article content).
All valid points and I am playing devils advocate in all of this as I actually like SSGs, I am in the middle of working on a hybrid system as we speak.
Just sticking up for poor old WordPress (poor thing with its dominant market share 😂😂).
I just made a bunch of arguments against WP to the marketing department and inadvertently made a new project for my team to redo the site with an SSG. Maybe I'll tell them you said it's not so bad 🤣🤣
I chose to move from Wordpress to SSG (using two CMS approaches: NetlifyCMS or raw Markdown in git for my own site; offline Wordpress and an SSG plugin for a friend who likes WP), primarily for: cost reduction - CDN hosting is massively (1000+ times) cheaper than a VM; security posture improvement (a cloud company problem, not mine now); lower operational hassle (no more patching, DB backups, etc.)
How would you cache a shopping cart website with many pages and components changing all the time?
And how would you manage the same with a SSG?
There are fragment caches, object caches, partial page caches etc.
SSG doesn't need caching. WordPress plugins like WP Super Cache would generate static HTML files but those are basically just snapshots of dynamic WP pages. It's very difficult to manage that if your site is dynamic. You would need to re-generate those snapshots quite often
Yeah it's true you could achieve that with something like fragment caches. But honestly it seems to be a lot of work and I'm not sure if it's worth it. As someone said above it's dealing with the symptoms of the problem instead of the actual problem
"No-one" is talking about one of the biggest and most mainstream trends in web development over the last several years?
My exact same thought 😂
Funny because static site generation was the first big trend on the web back in the mid 90s.
It was abandoned for more complex stuff and because of improving code stacks. But it's still a very valid strategy where it can work and for very heavily hit sites.
You can even make it work with comment sections. (Slashdot for the longest time statically generated their site)
What you do is take in comments, but don't show them till some time passes and your site is regenerated. The advantage of that approach is that the site is always up, and site generation is independent of current load.. if it takes longer.. oh well.. so be it.. but the site is still up).
😂😂I'll be more careful with my titles next time
React: Gatsby, Next.js
Vue.js: Nuxs.js
Used all of those frameworks for SSG with Wordpress, Contentful or Strapi as a back-end. It's totally worth learning.
Let me tell you my story of SSG, I have chosen Jekyll with GitHub pages 3 years back. I used to write Markdown in my local machine, then used to push code to GitHub pages. Then sometimes, I wanted to write a blog post but I wasn't on my development machine. Now I use some Static CMS to tackle this.
Conclusion is, SSG softwares aren't popular because they are currently targetted to developers only.
It's good to list simple ones. And then there's this one github.com/sake92/hepek. I like going a bit outside of popular and try to research really unknown. But to be honest in this case it's a friend who started it. Cool thing in here for me is that it's mostly developer oriented so you I guess it might be easier then learning some markup language or so.
Ive configured wordpress websites to load in less than a second with assets it is easy to tweak there are even plugins who help you do auto minify and file concatanation. Database connection also comes from poorly designed network if you make sure your database is on same server or same country you wont get that issue unless you host is down but then that would also be an issue for static websites.
Then lets talk plugins wordpress being there and established for so long you have huge plugins like WooCommerce that let you start e-commerce websites very easily and configure everything in real time.
And I disagree a lot of people are using static site generator but usually for portfolios and more. Also take time into consideration. If im someone not tech savy and just want a small website for my business with Wordpress you signup, configure and in 5 minutes you are up and running.
They target different audience and different needs.
Really nice post. I also setup my blog with a static page generator. I use Pelican, because I like Python. In my last post I explain how I publish it with Jenkins.
Have you ever made a site with Hugo?
No, I've only used GatsbyJS.
I don't think you need to know Go to use Hugo.
My personal site is built with Hugo, you do need to learn their Markdown extension syntax if you want useful things like automatic linking between pages, or writing your own macros.. but you definitely don't need any Go skills.
I think the headline is misleading.
I'm not a big fan of Wordpress to be honest but it serves a completely different purpose and is a completely different tool. SSGs can be used to create websites for yourself as a developer, for other developers (and can be hosted on a platform like GitHub so others can easily contribute) or in combination with a CMS. A CMS on the other hand can be used for and sometimes even from non-technical folks like clients and you host them easily on shared hosting.
I am using hugo for:
I like it very much! Kudos to the Development Team!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.