
Preload, prefetch and other link tags - iamakulov
https://3perf.com/blog/link-rels/
======
twiss
You can also put prefetch hints in a header:
[https://developer.mozilla.org/en-
US/docs/Web/HTTP/Link_prefe...](https://developer.mozilla.org/en-
US/docs/Web/HTTP/Link_prefetching_FAQ#What_are_the_prefetching_hints.3F)

------
kevingadd
It's unfortunate that Chrome's definition of 'mandatory' is flexible in a bad
way. If you've done enough performance profiling of webapps in Chrome you may
have noticed that even cached resources can take over 20ms to load from cache
- this is because all cache loads have to go between processes, so they get
delayed until thread/process switches can happen and messages can get ferried
back and forth. If you're unlucky, you eat this delay on every resource you
load. In some cases this can add over a second to load time for an
application.

You might think 'well this calls for prefetch, right? load them all at once'.
You're right! Except it doesn't work. Chrome content processes ignore prefetch
directives, all they seem to do is ensure that they're in cache - so there's
no way to avoid eating this 20+ms hit per-resource.

Ideally you control all the code being run in your app so you can just issue
the relevant XHR requests to load everything up-front and not block on those
requests, but I've frequently run into cases where a downloaded resource loads
other resources, etc. Really frustrating that caching and prefetch are so slow
in Chrome and there's no indication that they will fix it.

It's my understanding that in comparison Safari does not have this hit per-
asset, loading the applications I've tested is _dramatically_ faster on an
iPhone compared to Chrome on a desktop PC. :(

------
strictnein
Random question: for the preconnect, is there some Javascript API now that
allows for the monitoring of the TLS handshake?

As specified in the article, the handshake is:

    
    
       TLS handshake (only for HTTPS sites). Perform two roundtrips 
       (a message goes client → server → client → server → client) to initiate a secure TLS session
    

Is there any part of that which could be used to send a custom message to the
client? A short bit of text or a number or something. Don't really have a
practical use for this, just more of an esoteric one.

~~~
tyingq
You can't do it from a browser, but the "tls client hello" could certainly
hold a custom message of sorts. Either in the "random bytes" it's supposed to
send, or stuffed in as a fake cipher preference in the supplied list.

Good breakdown of the handshake here: [http://www.moserware.com/2009/06/first-
few-milliseconds-of-h...](http://www.moserware.com/2009/06/first-few-
milliseconds-of-https.html) (skip down to the client hello)

------
smacktoward
I'm not sure where the submitted title came from; it's not the title on the
article, and it's factually incorrect -- there's only one tag (LINK), which
includes an attribute (REL) that can be set five different ways. That's a lot
cleaner and more orderly than "5 different tags to preload something"
suggests.

~~~
dang
We've replaced the title with that of the article. (Submitted title was "HTML
has 5 different tags to preload something. Here’s a deep-dive into all".)

------
sureaboutthis
Just because I can...

I find it interesting that he is inconsistent in his usage of <link>. Some of
his markup has a closing slash and some of it doesn't. However, my main gripe,
is that the HTML spec has never specified or required a closing slash. While
it is allowed, putting that slash there has no meaning, it does nothing, and
the spec tells browsers they are to ignore for those reasons.

When I ask why some people insist on putting it there, I get wildly different,
unreasonable answers.

"It's just a bad habit I picked up."

How do you pick up a bad habit for something that does not exist?

"I do it so it's XHTML or XML compatible."

Well, you aren't serving it as either XHTML or XML and are very unlikely to do
that. In addition, the rest of your HTML is probably not XHTML or XML
compatible on top of that.

"The spec does allow it."

It allows it, as I always tell them, due to backwards compatibility with
(X)HTML uses in the past, but it also says you're wasting your time and
effort. See my comment at the top.

To end this, no HTML specification in the history of the universe has ever
stated you need to or should put a closing slash on <link> or <img> or <input>
or any other HTML tag and there is no example of such usage anywhere in said
documentation either.

~~~
underwater
HTML doesn't require a closing slash, but without it needs to be context-aware
and maintain a whitelist of tags that are self closing (one effect of this is
that custom elements can never be self closing).

It's not really surprising that a developer would gravitate towards an
encoding that is not dependent on maintaining a whitelist of tags, because
that is the solution that intuitively feels more "correct".

~~~
sureaboutthis
If one needs a closing slash to be reminded which of the five or so tags are
self closing, one has far more issues than needing a closing slash.

~~~
underwater
My point is that not that remembering things is hard, it's that it feels like
a hack. Developers gravitate to solutions that feel elegant.

~~~
sureaboutthis
Putting the slash in, as I said, is there for backwards compatibility only,
not elegance, and it could be removed at any time since this backwards
compatibility issue no longer exists, or is of minor consequence nowadays.

It is far, far better to read and follow the standard specification and not
follow a whim that makes you feel good. These are the things that will burn
you first.

