Below, I’ve summarised some key takeaways from the 10 questions I asked Samuel. I’ve also provided timings for each section of the video, should you want to dig into the answers you’re most interested in.
02:44: How does Googlebot behave in crawling and indexation?
The above understanding is, of course, correct. However, the reality and subsequent considerations are much more complex according to Samuel:
Googlebot is a term used for a collection of lots of different pieces of software and processes, and there are hundreds of phases running in parallel with each other.
There are limitations, as Google only has limited crawl resources. This includes memory limits and processing time.
If a resource is taking too long to load, Googlebot will stop and assess its current understanding of a page, which may mean your most important content isn’t loaded and seen. Your crawl budget may be impacted if this is a recurring issue in terms of page speed.
14:20: What are the basics of SSR (server-side rendering) and why is it important?
21:41: What is the difference between unused CSS and render-blocking CSS?
There is often confusion between the delineation of these two areas. But they are two very different things:
Unused CSS is self-explanatory insofar as it’s CSS that isn’t required for the rendered view of the page. This should be slimmed down where possible – think about unnecessary CSS used in templates across a site.
Render-blocking CSS is something that will stop the flow of HTML elements being rendered to the page.
This type of CSS can be deferred in load or switched out using different rel tags.
26:13: Image optimisation (compression, width and height, lazy loading)
I wanted to find out what Samuel had to say about image optimisation for websites with a lot of images – are there ways we can do this in bulk?
Image optimisation is a really overlooked part of page speed optimisation – there are so many brands that do this badly!
Formats are important here. PNGs and JPEGs tend to be quite large – WebP format can save a lot of time.
Another common issue is not utilising the correct HTML elements for displaying images.
Put effort into user experience as a whole.
Lazy loading can be a good way to solve page weight load issues caused by lots of images that are not needed on the initial page load.
39:54: What are the most common issues and fixes for page speed depending on common CMS?
We go through ways in which you can optimise page speed for various types of popular CMSs, hosted or self-hosted.
Databases can cause the biggest problems in terms of performance in common CMSs.
Caching the database and content is a good way to tackle this, in a similar approach to SSR. Lots of plugins are available to help with this.
However, Shopify is an exception to this rule, as it has its own methods of caching and comes with inherent SEO struggles, which we’ll detail at another time.
47:19: Which is the best CMS from a page speed perspective, and worst?
The million-dollar question:
As a full-stack developer, Samuel prefers to build everything from scratch as every CMS will have its issues.
In terms of the worst, Samuel isn’t a fan of WordPress. While the most popular, it is the most abused in terms of being open to hacking due to its public code. It’s also still based on PHP, which isn’t the best technology out there today.
52:28: Headless CMS – is it a fad or is it a really good solution for both page speed & SEO?
What is a headless CMS and can it be good for page speed and SEO?
A headless CMS is a backend-only CMS, which involves providing a function of interacting with the database with the output returning via an API.
Benefits involve content being served to many different frontends, resulting in different site templates, which a typical CMS may struggle with.
Samuel prefers headless CMSs because the ability to layer in optimisations is better, due to the separation of the front end and the back end. They offer a lot more control.
58:28: How to ask for changes in a language that both parties understand (SEO and dev)?
Relationships between dev teams and SEO teams are a vital component of site success. What are the best ways to manage this from a site speed perspective?
This isn’t a problem at Reddico, but in a wider sense, for SEOs, it’s about being open to understanding development and developers.
If you’re willing to go on a journey of discovery rather than just sending over recommendations, you’ll go much further. Developers love puzzles, rather than being given recommendations with no context.
SEO-aware developers are the easiest to talk to in this context, though this is not always the case. It’s all about collaboration.
1:04: What are the easiest fixes with the least effort required from a dev perspective?
Another gem that SEOs would all love to know. Find out what Samuel had to say:
If you want impact for page speed insights, image optimisations are great. Images are mostly poorly optimised on the web, even on the world’s biggest websites.
Use lazy loading to make the page load quicker in general.
SERP Speed, Reddico’s free SEO tool, allows you to compare your web page speed against those in the top 10 positions for your chosen keyword. It also provides insights and recommendations for improvements, making it especially useful since the introduction of Google Core Web Vitals. Give SERP Speed a try.