In the ever-changing landscape of devices and web browsers that your visitors will be using to access your website, one thing remains constant: A fast website is better than a slow one.
Google has taken note of this for some time now in their Google Page Speed Insights tool, and in the Lighthouse software that powers it. They routinely test your websites speed by using simulated mid-range mobile devices and by recording real-world speed data from your visitors’ devices.
It’s no secret that Google has been using page speed as a ranking indicator for some time. Indeed, many clients I talk to cite page speed as one of their main concerns.
So what can you do about it?
Stop building your pages on every request!
In a traditional website, whether it’s powered by a CMS such as WordPress, or some custom-built solution, every visitor to your site follows this process to view a web page:
- The visitor enters your web address into their browser or clicks a link.
- Their browser makes a request to your server for the page.
- Your server runs that request through some programming code that makes multiple requests to a database to retrieve raw content and then runs more code to inject that content into some sort of template to produce an HTML document.
- Your server then sends that HTML document back to the visitor’s browser.
Out of those 4 steps, #3 typically accounts for between 0.5 and 2 seconds of real-time that your visitor has to wait before their web browser even begins to display anything and every visitor is seeing this on every page load. This is called the “server processing time”, sometimes called the TTFB (Time to first byte).
What if I told you that you could eliminate that time from your visitors’ experience altogether?
Well, you can, and here’s how; You need to use something called a Static Site Generator. These are sometimes referred to as JAMStack or SSGs.
A static site generator is only one-third of the puzzle though. While a static site generator will do the work of building your website as a package of static files, you still need two other things:
- Some way of editing your content in a place that the SSG can retrieve it.
- Somewhere to host the static files that the SSG builds.
Hosting an SSG
Technically, you can host a statically built site on any hosting you like. You can even host it in Azure blob storage or an AWS S3 bucket.
You could do those things. You would need to create and manage your own build pipelines using something like CircleCI or Azure Pipelines, but it is possible.
Alternatively, you could host the statically generated site with a service that is designed to manage the build process and hosting from start to finish.
Netlify is one of the most established hosts for JAMStack sites. In fact, Netlify also supports most SSGs, including Gatsby and NextJS, and make it very easy to get a site deployed quickly.
Gatsby has its own offering for hosting which, when hosting GatsbyJS sites is comparable to Netlify.
For next the best choice in my opinion is Vercel as it gives you other features and options with NextJS that are not available on Netlify or any other static site hosting that I know of.
With the hosting sorted, it just leaves you needing a place to write and edit your content.
Content with Static Site Generators
Content can literally go anywhere that is web-accessible when you’re using a static site generator. I know developers who will write all of their content in MarkDown files and stick them in a separate git repository for the SSG to pull from.
Others use raw JSON files.
With a good content management strategy and a developer that understands headless content management, you can not only make the most of your statically generated site but also make your content much more portable.
Portable content is amazing because it means that if you want to rebuild your site in a few years using the next great advancement in website technology you don’t have to worry about migrating your content again as well.
Content migration from one CMS to another is hard and time-consuming and even if you manage to get some automation in there you will always end up with a lot of manual work to do. It might seem daunting to go through all of that with a headless CMS but trust me, it’s worth it to never have to do it again!
What are you waiting for?
As of this writing, Google is planning to make a core algorithm update in May 2021 that will include a new factor – Page Experience – which means it will affect rankings.
They launched web vitals last year that outlined how they planned to measure this. The key outlines to this appear to be:
- Speed (loading, interactivity and visual stability)
- Mobile-friendliness (reducing code, browser caching, and reducing redirects).
- Mobile experience (The webpage design should be simple and responsive to appear attractive on smaller screens. Site structure, too, should be optimised for mobile.)
While a static site generator won’t solve all of your speed issues, you still need your developer to write efficient code and follow Google’s web vitals when building the front-end of your site, but by eliminating that server response time overhead and making your content more portable you give yourself, and your site, the best possible foundation for speed.