by Martin Splitt of Google explains rendering and the impact of rendering on Search Engine Optimization (SEO).
Martin Splitt of Google took part in a webinar regarding web page rendering and how it affects SEO. Rendering is what happens when a browser requests a web page, and it’s a big part of how Core Web Vitals ratings are calculated.
Understanding this removes some of the myth surrounding Core Web Vitals.
What is Web Page Rendering?
The process of building a web page involves what happens between the browser and the web page, which is known as web page rendering. High Core Web Vitals ratings are the outcome of an efficient rendering process.
Sales, advertising earnings, and even web page crawling can all be affected by inefficient rendering.
Martin answered by drawing a parallel between designing a web page and cooking a dish from a recipe.
HyperText Markup Language is the abbreviation for HTML. It’s a file format for producing documents that can be viewed in a browser once they’ve been rendered.
Martin Splitt explained rendering:
“If you think about HTML as a recipe, and you have all the ingredients in there:
You have a bunch of text
You have a bunch of images
You have a bunch of stuff
But you don’t really have it in the recipe. The recipe is a piece of paper with all these instructions on how to make a thing.”
The first part of Martin’s explanation is that HTML is like a recipe, the instructions. The text and images are the things used to create the finished meal, which is the web page.
Martin continued the analogy by comparing web page resources with the actual physical ingredients:
“Now, the resources of a website are the ingredients, such as the CSS, the JavaScript files as well as the images, the videos, all that stuff that you load to actually make the page look the way that it looks afterwards.
And the website that you know and use in your browser you see in your browser, that’s the final dish.”
Cooking is Like the Process of Rendering
Martin then compared rendering to the actual process of preparing the ingredients (images, CSS, and so on) and cooking them.
He went on.
“And rendering is pretty much the cooking or the preparation process of that.”
Crawling and rendering by Googlebot
Martin then explains what rendering is for Googlebot.
“So crawling fundamentally just goes into a big book of recipes and just takes out a page with a recipe and puts that into our realm, our reach, like basically we are standing here at a kitchen table …and we wait for the cooking to begin and crawling will basically just hand us a recipe.
And then rendering is the process where, rendering goes, Aha! Interesting! Crawler over there, can you get me these ten ingredients?
And the crawler will be conveniently, yes, I got you these ten ingredients that you need.
Thank you very much!
And then we start cooking.
That’s what rendering is.”
How (& Why) Search Engines Render Pages
There’s an intriguing twist in the way we think about indexing, and it has to do with rendering.
When we think of page ranking, we usually think of indexing.
To put it another way, we usually consider the point in time when a search engine:
- Sitemaps or crawling led to the discovery of a page, which was subsequently visited for indexing.
- Using the page source, I gathered all of the content.
- For inquiries, I started ranking the page.
- Because it provides the trigger for rankings, this has traditionally been the most crucial collection of phases in the process.
Indexing, on the other hand, isn’t the last step in the discovery process.
I believe that its weight will decrease over time, while the last stage – rendering – will increases and I suspect replaces the indexed version altogether.
Indexing vs. Rendering: What Is the Difference?
Why Rendering?
You might be wondering why you should bother rendering in the first place. Why would Google need to render pages if a site doesn’t use JavaScript or is otherwise reliant on rendering to “see” the content?
The ability to prioritize material based on how a human would interact with a website is provided by rendering.
It tells the engine how content is shown in a browser and how visible different aspects are, so they’re judging or prioritizing content and weighing usability using the same product that a visitor is using.
Web Page Assembly: Parsing HTML
The following section introduces the term parse, which is a programming term. Parsing is just taking all of the components of an HTML document (JavaScript, CSS, and HTML elements) and following the instructions to build a web page.
Martin continued his discussion of rendering:
“So rendering parses the HTML.
HTML fundamentally, when it comes from crawling, is just a bunch of text, conveniently formatted but …Text!
In order to make that into a visual representation, which is the website really, we need to render it, which means we need to fetch all the resources, we need to fundamentally understand what the text tells us to be like:
There’s a header here, okay.
Then there’s an image there and next to the image there’s a bunch of text and then under the image there’s another heading, it’s a smaller heading, it’s a lower level heading …and then there’s a video and then below that video there’s some more text and in this text there’s three links going to here, here and here.
And all this assembly process, this understanding what it is and then this assembling it into a visual representation that you can interact with in your browser window, that is rendering.”
JavaScript’s Role in Rendering
Some JavaScript is required for the web page to be rendered (created). A lot of JavaScript isn’t required in the initial building of an interactive web page where a site visitor can scroll, read, and click a navigation menu, such as the scripts linked with a contact form.
Some non-critical JavaScript can be delayed or removed entirely if it is not required for the web page to render faster (and enhance Core Web Vitals).
Some JavaScript is required to make the page visible and interactive, while others are not required now or at all.
Martin explained:
“And as part of rendering, at the very first stage, we execute the JavaScript because JavaScript happens to be basically a recipe within the recipe.
So JavaScript can be like, now go chop those onions!
So now you have the onions as a raw ingredient but you don’t put the onions as a whole into your dish, you cut them up.
And that’s what the JavaScript is needed for, right?
…The JavaScript execution is just a part of rendering.”
Discussing The Layout Tree
Martin then moves on to discussing the Layout Tree. He’s referring to the Document Object Model, which is a hierarchical representation of all the components in a web page.
A web page’s various “bits and pieces” are similar to the leaves of a tree. The leaves on what Martin refers to as the Layout Tree are known as nodes in HTML.
The Layout Tree is explained by Martin:
“But then when the JavaScript execution has finished or if there was no JavaScript execution that is fine, too.
But what then happens is we are assembling, like we are figuring out these bits and pieces and how we need to like assemble them on the page and that leads to something called, Layout Tree.
And the Layout Tree tells us how big things are, where on the page things are.
If they are visible or if they are not visible, if one thing is behind another thing.
This information is important for us as well, just as much as executing the JavaScript because the JavaScript might change, delete or add content that wasn’t in the initial HTML as it has been delivered by the server.
So that’s rendering in a nutshell.
From we have some HTML to we have potentially a bunch of pixels on the screen. That’s rendering.”
The Impact of Costly Rendering
Martin then shares some interesting information about the influence of JavaScript on energy consumption. He uses the terms “expensive” to highlight how pricey JavaScript may be in terms of time and energy.
He compares JavaScript to carbon dioxide, a greenhouse gas, and how this affects users and, eventually, publishers’ and ecommerce businesses’ bottom lines.
According to Martin, expensive rendering results in:
“Google Search has the exact same struggle as a real-world user in this case.
Because, for a real-world user, even if you are on a modern phone and a really fast and fantastic and expensive phone as well, more execution also always, always, means more power consumption.
That’s just the thing. And …there have been people who called JavaScript the CO2 of the Internet and I don’t think that’s completely wrong.
…The more expensive you make it the worse it is for us as an experience.
Google Search doesn’t really care. We just have to invest in the resources that we need and we do a lot of optimizations to make sure that we are wasting as few energy and time as possible.
But obviously, if you are optimizing that, a nice and really nice side effect is that your users will probably also be happier because they need less battery, their old phone will still work fine with what you put out there and they will be able to consume your web content and maybe not your competitors because your competitors don’t care and actually produce something that is less convenient to use on their phones.
So this is not something where you would pit Google versus user experience.
This is kind of like the same problem or the same challenge and we are all facing it, including Google Search.”
Rendering insights: Importance of Rendering
When it comes to Document Object Models, DOM trees, and rendering, Core Web Vitals can be a bit abstract and mysterious.
Martin Splitt’s analogies aided in removing some of the ambiguity surrounding one of the most critical aspects of understanding Core Web Vitals scores: rendering.
Another advantage of his presentation is that it raises awareness regarding expensive rendering and how it could affect site users with older phones that have problems rendering the page.
And it’s not just older phones; modern phones may have trouble downloading a web page if the phone has been on for days and the RAM is being used up by several active browser windows.
Finally, he de-mystified the term “rendering.” That advances the discussion on increasing web page speed and Core Web Vitals performance because technical jargon is one of the few things that can slow or stop progress on understanding something crucial.
Citations
Original Duda Webinar Page for Essential Rendering
ArtiBex
ReplyDeleteFree Guest Post
Write for us