Traditionally, a crawler would work by extracting data from static HTML code, and up until recently, most websites you would encounter could be crawled in this manner.
However, if you try to crawl a website built with Angular in this manner, you won't get very far (literally). In order to 'see' the HTML of a web page (and the content and links within it), the crawler needs to process all the code on the page and actually render the content.
A friend of mine runs a website built in Backbone, and his website provides a great example to see what's going on.
Consider the product page for their most popular product. With Chrome -> Inspect we can see the h1 on the page:
However, if we just view-source on this page, there is no h1 in sight:
Scrolling further down the view-source page will just show you a bunch of scripts and some fallback text. You simply can't see the meat and bones of the page - the product images, description, technical spec, video, and most importantly, links to other pages.
So if you tried to crawl this website in the traditional manner, all of the data a crawler would usually extract is essentially invisible to it. And this is what you would get:
One page. And one page with very little on it, at that.
In essence, the crawler needs to pretend to be a browser, let all the content load, and only then go and get the HTML to parse.
Every time you set up a new Project in Sitebulb, you need to choose the Analysis settings, such as checking for AMP or calculating page speed scores.
Most people probably won't know what the Render Timeout refers to or how to set it. If you'd prefer not to know, skip the section below and just leave it at the recommended 5 seconds. Otherwise, read on.
What is this Render Timeout?
The render timeout is essentially how long Sitebulb will wait for rendering to complete before taking an 'HTML snapshot' of each web page.
The 'Render Timeout' period used by Sitebulb starts just after #1, the Initial Request. So essentially, the render timeout is the time you need to wait for everything to load and render on the page. Say you have the Render Timeout set to 4 seconds, this means that the each page has 4 seconds for all the content to finish loading and any final changes to take effect.
Anything that changes after these 4 seconds will not be captured and recorded by Sitebulb.
Render Timeout Example
I'll demonstrate with an example, our friends again at Bailey of Sheffield. If I crawl the site with no render timeout at all, I get a total of 30 URLs. If I use the 5 second timeout, I get 51 URLs, almost twice as many.
Clearly, this can have a profound impact upon your understanding of the website and its architecture, which can be highlighted by comparing the two crawl maps:
In this instance, it was very important to set the Render Timeout in order for Sitebulb to see all of the content.
Recommended Render Timeout
Understanding what the Render Timeout is there for does not actually help us decide what to set it at. We have scoured the web for confirmation from Google about how long they wait for content to load, but we haven't found it anywhere.
What we did find however was that most people seem to concur that 5 seconds is generally considered to be 'about right.' Until we see anything concrete from Google, or have a chance to perform some more tests of our own, we'll be recommending 5 seconds for the Render Timeout.
But all this will show you is an approximation of what Google may be seeing. If you want to crawl ALL the content on your site, then you'll need to develop a better understanding of how the content on your website actually renders.
To do this, we'll return to Chrome's DevTools Console. Right click on the page and hit 'Inspect', then select 'Network' from the tabs in the Console, and then reload the page. I've repositioned the dock to the right of my screen to demonstrate:
Keep your eye on the waterfall graph that builds, and the timings that are recorded in the summary bar at the bottom:
So we have 3 times recorded here:
- DOMContentLoaded: 727 ms (= 0.727 s)
- Load: 2.42 s
- Finish: 4.24 s
You can find the definitions for 'DOMContentLoaded' and 'Load' from the image above that I took from Justin Briggs' post. The 'Finish' time is exactly that, when the content is fully rendered and any changes or asynchronous scripts have completed.
Bear in mind that so far we've only looked at a single page. To develop a better picture of what's going on, you'd need to check a number of pages and check the timings for each one.
Obviously the first port of call, you can save time doing discovery work with a thorough briefing with the client or their dev team.
However, whilst it is nice to think that every client briefing would give you this sort of information up front, I know from painful experience that they are not always forthcoming with seemingly obvious details...
Trying a Crawl
It is certainly worth bearing in mind though, in case you are a set-it-and-forget-it type, or you tend to leave Sitebulb on overnight with a queue of websites to Audit... by the morning you'd be bitterly disappointed.
You can also use Google's tools to help you understand how a website is put together. Using Google Chrome, right click anywhere on a web page and choose 'Inspect' to bring up Chrome's DevTools Console.
Then, leave the DevTools Console open and refresh the page. Does the content stay exactly the same, or does it all disappear?
This is what happens in my Bailey of Sheffield example:
Notice anything missing?
What is Google (Probably) Doing?
Our recommendation is that you do the same.