Static sandwiches
It's lunchtime and you're going to a new sandwich shop. They've got a wide choice of fillings. They have a load of sandwiches with the most popular fillings pre-made. Decisions decisions. Do you choose one of the pre-made ones and get it straight away, or ask for something different, maybe more custom and wait for it to be made for you, or do you get one of the popular options but have it made fresh?
Let's now think about it from the sandwich shop owner's point of view. They don't have to offer pre-made sandwiches - they could all be made to order. Or they could only offer pre-made and customers just buy off the shelf.
Web content, please
I expect you've already figured out where this is going. Let's substitute the sandwich shop for a web browser and the sandwiches themselves for web content. Just as the shop can offer pre-made sandwiches a website can offer static pre-compiled content that is available straight away. Alternatively, just as a customer can request a custom made sandwich meaning a longer wait time, a user can request a page with specific content, for example, a profile page for a particular person. This is dynamic and has to be compiled before it is served. It may involve fetching data from a database or API. The additional processing takes time. So, pre-compiled pages, like pre-made sandwiches, are obviously faster.
As web developers, if we want to deliver content as efficiently as possible, it stands to reason that we should offer static content where possible and dynamic content where necessary. I used a profile page as an example of a dynamic page as this is a common pattern. There's a template for a personal profile and then the data for that one person is fetched and bound to it to create the finished page. But it doesn't have to work like this. The page could be pre-compiled and made into a static page, stored ready to be served up on demand. If the data changes or the template changes the pages are re-compiled, so they're always fresh and fast.
What about scalability?
As ever, there are trade offs. If you have a site with profile pages for team members and there are a only 10 then having 10 additional static pages is not a problem and probably the way to go. If, however, you're a huge platform with thousands of users then this is a lot of extra files to store, not to mention the overhead of having to re-compile all of the static pages every time the template changes.
What about caching?
Caching is essentially keeping a copy of the compiled page so that it doesn't have to be compiled again. There are 2 main types. The server, which does the compilation, can keep a copy handy, ready for the next request. The browser can keep a copy so that if we want the same again it'll be quicker. The complexity here is that, much like sandwiches, the content can become stale. Caching is a whole topic in itself. While some level of caching and periodic re-compilation is certainly useful for speeding up common requests for dynamic content, it's still not as efficient as static pages which are always fast and always fresh.
Static first
I changed my personal website from a WordPress site to an Eleventy site for these reasons. It's now all static and all my pages load pretty much instantly as there's no additional processing at the time of request - it's all been done at the time of publishing. No server side processing also means it's cheaper to host.
Static pages won't work for all types of content. Sites with a lot of real time data or that need to run queries can't necessarily but sites which are document based, like a blog or a documentation site should almost certainly be static.
We should look for opportunities to compile content as early as its change frequency and scale will allow.