MARTIN SPLITT: Did you ever inspect the source of a website
and wondered why it looks different from what
you see in your browser when you open the same website?
Or maybe you heard about the rendered HTML or the DOM
and don't know how these are different from what you see
in View Source, for instance.
Then this video is for you.
In this video, I would like to take you
on a journey behind the scenes of your browser.
So let's jump in.
[MUSIC PLAYING]
To understand what happens between a server sending
some HTML into your browser and the browser
showing you the website in all its glory,
we need to start at the moment where you hit return
in the address bar and ask the server somewhere
on the internet to give a website to you.
The first step to get a website into your browser
is to send an HTTP request to the server that
is hosting the website.
Once the server receives the request,
the server chooses how to respond to it.
That can mean running a program like a PHP
script, or a Java program, or whatever,
or simply sending back the content of a file.
For this video, we will skip over what exactly
the server does and focus on the fact
that the server usually starts sending a bunch of HTML
back to the browser.
Many people think of the HTML that
was sent from the server as the same as the website
you will see in your browser, but that isn't really accurate.
Instead, we could say that what you see in the browser
is a dish, and the HTML that was sent is the recipe.
The browser needs to prepare or cook
the dish based on the recipe it received from the server.
It turns the HTML into a number of visual and sometimes
interactive elements that then show up on your screen.
The interesting part is what happens between the HTML
and what you see in your browser.
This is called rendering.
Let's look a little closer at rendering
to see what happens in between the beginning, the HTML that
comes from the server, and the end, the interactive website
that you, well, interact with.
To understand the difference between the HTML
that we received from the server, the so-called source
HTML, the rendered HTML, and the DOM,
we need to look closer at this rendering process.
The rendering process is a series
of steps that start with the source HTML and, if included,
the styling information in the CSS.
The browser starts by parsing the source HTML
and, if available, any CSS found inside,
which creates two tree-like structures called the Document
Object Model, DOM for short, and the CSS Object Model, CSS OM
for short.
For us, the DOM is the more important of the two models,
so we'll focus on it from now on.
For our website, for example, the browser
would create the following DOM tree.
The browser needs this tree to identify individual elements
on the website and their relationship to other elements,
like for instance which text belongs to the heading
and which to the paragraph.
Or what file is the source of this image?
The browser then takes the DOM and CSS OM and figures
out how to fit all of this stuff into the browser window.
This is called layouting and creates a render tree.
The render tree basically contains
the sizes and positions on the screen for each
of the elements in the DOM.
The browser uses this tree to paint
the actual pixels that make up what
we see in our browser window.
It is important to understand that once the browser shows
us the website, it may use JavaScript to allow us
to interact with the website.
The JavaScript might then change the DOM
by adding, changing, or removing elements in the tree.
For example, when I click this button,
it adds an image to the DOM and thus
to the website on the screen.
Here, we can see this in action.
On the left, you see the interactive website.
On the right, you see a representation of the DOM
that the browser uses for this website.
Whenever the button is clicked, the JavaScript
adds a new image to the DOM tree,
and the browser renders it.
In the previous example, the DOM tree
might look different at any moment
depending on what happened before.
The DOM itself only lives in the browser memory
and isn't visible, per se.
But we can represent it in different forms.
One such form is the interactive tree view
that we saw in the browser developer tools
on the right-hand side of the previous video.
Alternatively, we could turn the DOM tree back into HTML.
We call this the rendered HTML.
When we turn the DOM tree back into the rendered HTML,
we might get different results depending
on what happened to the DOM tree before.
For example, the rendered HTML of the previous example website
is exactly the same as the source HTML
as long as the button was not clicked.
As the button is clicked, JavaScript
will run and will change the DOM and, in turn,
the rendered HTML.
Now, you may already wonder, what
is it that I see when I click View Source in my browser?
Well, it's the source HTML, or is it the rendered HTML?
There are three ways to see the source
HTML coming from the server.
First and probably most known is to right-click on a web page
and select View Source, or type in view-source:
in front of the URL.
That shows you the source HTML.
Alternatively, you can also go into the developer
tools on your browser, select the Sources tab,
and see the source HTML there.
Here, you can see that the right side shows the original HTML
without the images that are currently
visible on the website.
A third way is to use the Network tab
in the browser developer tools, where
you can also see the HTML that was sent back from the server.
But what options do I have if we want to see what's in the DOM?
Well, again, the browser developer tools
have us covered.
The devtools contain a tree-like representation of the DOM
that we can explore and interact with.
We find this in the Elements tab in Chrome.
You may notice that, unlike the other devtools
panels and the View Source, this shows us the current DOM
content, including the images that were added by JavaScript.
If we wanted to, we can turn the DOM back into HTML.
This can be quite complex, thanks
to things like the shadow DOM or cross-origin iframes.
But for simpler websites, you can get the rendered HTML
by going into the devtools console
and running this JavaScript snippet.
Again, please note that this isn't always
working, especially for more complex websites.
For debugging, I recommend that you use the URL inspection tool
in Search Console to get the rendered
HTML that Google search uses for indexing of a page.
All right.
So that was quite a ride.
Let's summarize what we learned today.
We started with a source HTML.
That's the HTML that a server sends to our browser
when we open a web page.
Then we learned that the browser turns this HTML into the DOM.
That is an interactive element by element representation
of the website constructed from the source HTML.
The DOM can change as JavaScript might modify it
while the page is loading, upon the user interaction,
or other events while it is open in the browser.
And then last but not least, we identified
rendered HTML as a snapshot of that DOM turned back into HTML.
The rendered HTML reflects the DOM content
on the page at the time the snapshot was taken.
To see the rendered HTML, you can use the URL inspection tool
in the Google Search Console.
So now we've looked at what's the source HTML, the rendered
HTML, and the DOM and explored what tools
you could use to debug issues on your websites.
What tools are you using to debug issues on your websites?
Let us know in the comments below.
And also, thanks a lot for watching,
and please like and subscribe to stay
in the loop with our latest and greatest content around Google
Search.
Thanks a lot, and bye-bye.
[MUSIC PLAYING]
Want more technical SEO antics?
Catch me on the "Search Off the Record" podcast,
where we talk all things Google search, go behind the scenes,
and who knows, maybe discuss my love for JavaScript.
Yay!
Join me, Martin, and the Google Search Relations
elves, and check us out wherever you download podcasts.
[MUSIC PLAYING]