Is Google using “defer” the wrong way?

See: https://developers.google.com/maps/documentation/javascript/tutorial

Google is using here:

<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" async defer></script>
</body>
</html>

My question is why Google is using "defer", because in my opinion it does not do anything in the script of them above?

Let's compare this (1):

<script src="script.js" defer></script>
</body>
</html>

With this (2):

<script src="script.js"></script>
</body>
</html>

The only difference is that when executing "script.js" in case: (1), you will be sure that the "end of the body tag" and "end of the html tag" are not yet in the DOM. In case (1) those tags are already in the DOM, when executing "script.js". But the end of the body / html tag will not change anything on your screen (rendering), so those tags are having actually no influence on "rendering". So theoretically there is a small difference between those 2 examples, but in practise there is no difference at all.

So what could be the reason to use defer? Let's go back in history. If you would use in old browsers:

<script src="script.js"></script>
</body>
</html>

The problems was that you did not have "preload scanners". They can scan the document (in parallel), searching for downloads to start already. An old browser would see "script.js" for the first time, when the "HTML parser" would reach that part of the document. That's pretty late to start the download and a waste of time. That's why they came up with "defer", so you could place the script tag at the beginning of the document, but the execution would take place when the html parser would be done with the whole document (so it would not block the html parser).

For newer browsers "defer" would not make sense anyway, because you could just use a "sync script tag", just before the end of the page. The "preload scanner" will start the download almost immediately. And because you are placing it at the end of the document, the execution of the script, will not block the html parser (execept end body / html, but those tags, will anyway have no influence on rendering).

So "defer" is only adding some functionality to older browsers, because in newer browsers you could just use the "sync script tag" at the end of the document.

But defer in older browsers would only make sense if you place the script tag at the beginning of the document and not at the end of the document. If you place "defer" at the end of the document, then anyway the browser has to wait a long time before it can start downloading.

So what i'm saying is: "defer" makes no difference in practise when you will put it on a script tag just before the end of the document. It would only make sense if you would put it on a script tag at the beginning of the document.

So it looks like to me that Google does not really understand the meaning of "defer", because why they would add it? It's not doing anything. Or is that wrong thinking of me?

This are some more questions / posts of me where i have my doubts anyway about what Google is saying about rendering and using defer / async et cetera:

Google is wrong about defer?

Why a browser is not always finishing rendering of the preceding HTML, before executing javascript?

External blocking scripts force the browser to wait, before the page can be rendered?

Consequences javascript can have document.write in the code?

Scripts that are dynamically created don't block rendering?

Loading external javascript via async script tag at the end of a webpage

That's why i wanted to check how Google is making their own scripts and after one Google search i found already this example, with for me strange looking use of "defer".

Anyway there could be a reason to use it, but Google is not clear with giving the right reason. In documentation, Google is telling the story, i was telling you in this post / question. But that's no reason to use "defer" like that.

I know that different browsers treating "defer" differently, so maybe that's why Google is using it. But then their documentation is not giving the right reasons. And then my question is what that reason exactly is?

So who knows more about this? Or "defer" is really there for nothing in the script of Google?

I've been thinking about it and i will give it a shot to answer my own question ;). Probably Google is thinking that people will copy / paste this code:

<script src="https://maps.googleapis.com/maps/api/js?key=YOUR_API_KEY&callback=initMap" async defer></script>

... and just add it somewhere on the page. So in a case like that, "defer" would make sense.

Actually if you have 1 script tag at the end of the document, and you are using "async" on it, it also makes no sense. But it makes sense if the script tag is not at the end of the document.

But if i would be Google, i would anyway add some note about it, because if you are a big company, people are checking examples and value it. I know webmasters by myself who are just adding async / defer to a script tag, at the end of the document, while it's the only one. You could think: but it's not doing anything, so what's the problem about it? For example async can just add a little extra delay before executing JavaScipt (compared with sync). So in a case like that, it can be better to use sync in terms of page speed, instead of async on your script tag.