Let’s talk about page speed, JavaScript and everything in between

In this video, I talk with Samuel Banks, Reddico’s Head of Development and Technology, about page speed, JavaScript and everything in between. We cover page speed optimisations, headless CMS, common issues around CMS and page speed – and much more. 

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? 

There are two well-known phases of Googlebot processes when talking about JavaScript SEO. Firstly, Googlebot follows links to discover the raw source of a page, and then if CSS and JavaScript are detected, it returns to render the page and update the index accordingly. 

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.

• Having content and links in the initial HTML source code is much better than rendering them in JavaScript, as Google will process them a lot earlier, as Google processes HTML a lot earlier than JavaScript.

• 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.

• If all your content and links are generated by JavaScript it may take Googlebot a long time to parse this, and there are also questions around whether authority is passed on through these types of JavaScript-generated links. 

14:20: What are the basics of SSR (server-side rendering) and why is it important?

Here, we discuss server-side rendering around sites that use/rely on a lot of JavaScript, and how this can open up solutions to some of the problems around JavaScript and crawling and indexing:

• Using SSR delivers a fully rendered version of a page in HTML without the need to execute JavaScript, allowing Google to parse a lot of information quickly. 

• This also stops potential issues with slow-loading JavaScript and content and links being ignored. 

• In terms of implementation, clients can be sceptical over SSR. Timelines can vary depending on the JavaScript framework and understanding of SSR, among other things. Technically, it’s not too hard to implement, though lack of understanding how it works can be a blocker. However, that can be solved through good communication and reciprocal support in order to come down to the most effective solution for the client. 

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.

34:38: Do we follow the same mentality with JavaScript as we do with unused CSS?

Is there a way to handle this situation with developers and clients? How do we advise clients when coverage reports are suggesting that most of the JavaScript is being unused by Google? 

• You need to consider that JavaScript frameworks are used a lot in the modern web. Even though Google isn’t seeing it, it’s still required to support key sections of the website framework.

• It’s better to assess the use of unused JavaScript libraries. Redundant tags such as unused third-party analytics scripts should be cleaned up. Generally, unused JavaScript should be looked into with a lot more caution than CSS.

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.

• Alongside our own CMS Verbis, Ghost is also strongly recommended as it’s very quick. The team behind it are very SEO aware and allows you a lot of control.

• 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

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.