
Building the DOM faster: speculative parsing, async, defer and preload - nachtigall
https://hacks.mozilla.org/2017/09/building-the-dom-faster-speculative-parsing-async-defer-and-preload/
======
matmo
"One thing to pay attention to when preloading fonts is that you also have to
set the crossorigin attribute even if the font is on the same domain: <link
rel="preload" href="font.woff" as="font" crossorigin>"

But why?

~~~
the8472
Because the spec says font-loads from stylesheets must always be anonymous
CORS. Thus the preload needs to match that.

[https://drafts.csswg.org/css-fonts/#font-fetching-
requiremen...](https://drafts.csswg.org/css-fonts/#font-fetching-requirements)

------
TwelveNights
Wow, that was a very interesting read. I had never even thought about the
interaction between the different parts of the DOM before.

------
finchisko
Wondering if async attribute is actually a thing in 2017. Last time I observed
chrome dev tools it seems that async is default behaviour at least for Chrome.

~~~
acdha
Depends on how you create it: in HTML, it matters but JS created script
elements are async by default.

------
seanwilson
Great article. I can't think of another one that explains the complexity of
how JavaScript and CSS block rendering. The diagrams really help.

------
outoftacos
This seems like a very promising idea, especially since every site nowadays
loads 12 scripts that were copy/pasted from eight different sources by six
different developers all over the page, and each one just blocks everything no
matter how fast your network or client is.

I mean, that's if you're lucky and the development team was relatively
competent.

~~~
ralmidani
Build systems really help reduce the number of scripts (and stylesheets)
loaded. I currently use Ember-CLI, and it's just a "vendor" script containing
all your third-party scripts and another with your app-specific code.

The old-fashioned way of embedding scripts directly is really wasteful, I
agree.

~~~
thephyber
I think you vastly underestimate how wasteful 3rd party JS API implementations
work. Especially for advertising, analytics, and other injected widgets.

Build systems exist, but that doesn't mean they are used everywhere or that
all features can be integrated into them. The same goes for static analysis
tools, dynamic analysis tools, perf optimization tools, security vulnerability
testing tools, unit testing, automated integration testing, etc. -- they
exist, but their coverage is _far_ less than 100%.

~~~
ralmidani
I understand build systems cannot solve every problem, and the mechanism
described in the article is certainly useful. I was merely responding to the
concern about third-party scripts with links copied-and-pasted mindlessly, and
which would be better handled using a build system.

~~~
outoftacos
Sure, but adding GA to a page is what I meant by copy/paste, this still
happens everywhere outside of the build process. Then of course marketing
needs to add 10 other things and they can't figure out whatever hip new build
tool someone set up and then suddenly things get really messy.

Yes this happened even at whatever company you think is a paragon of
engineering best practices and modern development.

------
module0000
Signs your "profession" has been changing... When I click a story with "DOM"
in it, expecting to read about a new Depth of Market interface.

~~~
thephyber
Document Object Model (in the browser) has been a topic of heavy discussion on
HN since I found it half a decade ago.

perhaps you just misjudged the composition of topics frequently posted to this
site.

~~~
module0000
It was meant as humor :)

~~~
thephyber
Strangely enough people usually can't infer sarcasm without body language.

This is the same reason the Secret Service put a large bounty on software that
can accurately identify sarcasm from legit intent to do harm to political
figures.

