Why the fuss about “static” sites?
The easiest way to look at this is comparing a monolithic approach, such as WordPress versus a decoupled frontend which could be a static site.
WordPress (Monolithic) vs “Static” sites
In a nutshell, WordPress or a “Monolithic” website refers to a site that is an “all-in-one” or “one-size-fits-all” solution. The backend and frontend are tightly coupled and the one cannot operate without the other.
A static site is a site without a backend, it’s also referred to as Jamstack, which means it’s made up from Javascript, APIs and Markup (HTML & CSS). But this does not mean you don’t have a backend, you merely don’t require a backend or server to render the website when a user requests access.
Benefits of Static sites
Blazing Performance
Websites built with static site generators are characterised by insanely fast loading times as there is no need for a backend or server to render the page on each request.
Scalability
There is no complex code to serve each time a user visits thus scalability is no longer a headache as the infrastructure needed to scale is minimal.
Simplified Hosting
Your hosting would typically be distributed across a CND (Content Delivery Network) meaning users across the world would not request pages from your website from the same server, but rather from the node closest to them.
Auto Backups
Everything is managed through version control so we have a complete history of all changes.
Security
With static assets you gain immunity against malicious attacks, Static Sites are very secure.
Ease of Change
With a decoupled backend / front-end we can change the one without affecting the other. In fact, your backend does not need to be up and running for users to access your site.
No platform limitations
All development is hand written code and we’re not tied into anything only a specific platform can or can’t do.
APIs
It takes a mindset shift to not think of your website as one solution, but rather this central hub that pieces various services together. If we need to solve a specific need, we get the best service for that and integrate through an API to pull the functionality into your website.
Mobile
The future of the web is mobile, it needs to be fast and lightweight not costing our users heavy data or loading times.
Progressive Web Apps
We build static PWAs to give you automatic code splitting, only load initial critical HTML, CSS and data and JavaScript takes care of the rest on client side. It also means static sites does not mean static data, we can hydrate any data once the page loads via an API to update any piece of content.
Comparison of features
How do I edit my content?
All this talk about not needing a backend and decoupling the frontend must have you wondering: “What if I want to change my content?”. And the answer is simple, there are various CMS (Content Management Systems) out there that could help us with editing the content. The most popular being WordPress. What we would typically do is deeply couple the frontend with WordPress through the WordPress API to ensure any content updates from WordPress would reflect on the frontend.
The key thing to understand here is that you get a “run time” vs. “build time”. Run time is when a user request a page from your website, build time is a DevOps process where we build a new version of your static site with the current “snapshot” of content from your backend. So each edit on your backend would result in rebuilding the frontend and republishing the static site.
How is the performance on rebuilding all the time?
The initial inkling is that recompiling the static site on a content or code change is bad for performance, but the really is that it is really efficient. For the majority of websites the content changes far less often than there are page loads. Some static site generators can convert up to 1000 pages a second, and this does not affect your live site. Only once the site has been regenerated would it replace the live site.
The alternative (Server Side Rendering) means that your page is compiled on the server before it is returned to the client (browser) on each page load. Even if this is a 1 or 2 second process it escalates quickly when you scale your site to a couple of thousand users, putting more strain on your server.
If we consider a publisher’s website as an example, they might get 100,000’s page views a day and publish 20 new stories. Rebuilding a static site 20 times a day would still be far more efficient that server side rendering 100,000’s times a day.
Typical Architecture
Considerations
How much do I want to do myself?
From a technology perspective there are a lot of moving parts, you don’t just need a web developer, you need someone that understands the entire ecosystem and have the ability to expand and build onto your site for what you might need in future.
A developer could set everything up as a once-off project, giving you access to update content, but if there are changes, updates or anything else you might require, you would need to get the developer to update it for you. It’s not a straight forward WordPress site where you can swap out themes, update or install plugins, etc. You need deep technical knowledge to work behind the scenes of a static site.
What type of website am I trying to build?
Static sites really shine when you’re building content sites. Even content that might change often like blogs, catalogues, etc.
It’s not impossible, but needs quite a bit of extra work is something like eCommerce where there’s a high volume of traffic, transactions and user content is present.
Resistant to Tech Threats
The live static site is served from HTML, CSS and Javascript. This has no thread to new technology — besides the odd chrome update that might break layout or something. The backend compiling in Node.js is controlled and even if there are updates we can do maintenance in a controlled manner. Even if the backend/WordPress goes down, the live site will not be affected. If you don’t touch your static site for the next 10 years, it will still be there, no updates required, no thread to hacks, etc. If you left your WordPress site there, it’s almost guaranteed it will get hacked when it’s outdated within a year or two.
Design / Layout Flexibility
The backend of a static site just represents the actual content, any design / layout changes need to be done in the actual code on the frontend by an experienced resource. You would have some flexibility on a static site to add pages, content, etc. but within the pre-existing design of the frontend. This could be an advantage to protect your brand and not let anyone lose on updating designs, colours, etc. Any design changes should then be done by an experienced professional.
Time to set-up
In some instances building a static site is a more structured approach to creating a site where you follow the typical project lifecycle of design, develop, deliver. Meaning it might take a bit longer to set-up a static site but for companies that are more brand conscious this is a good approach and process to go through to ensure all stakeholders have input and form part of the website creation process.
At the end of the day, I believe you need to look at the longevity of the solution you are putting into place as well as the ongoing work required to keep it up and running. Both approaches have various considerations in those respects and it starts with you asking yourself what you want to achieve with this website and what success would look like for you at the end of the day.
