
Using iframes and document.write to improve navigation performance - jaffathecake
https://jakearchibald.com/2016/fun-hacks-faster-content/
======
andybak
Isn't the problem that there's a performance 'enhancement' in wide usage that
actually hurts performance?

Devil's Advocate: maybe the real answer is to go back to proper full-page
loads and figure out why your javascript and CSS parsing is taking so long.

~~~
jaffathecake
In some cases, yeah. I touch on this at the end of the article. But if you
can't avoid having that JavaScript on the page, avoiding a revaluation is
beneficial.

One technique I didn't cover (as the article was getting long) is using a
service worker to speed up server renders. The test & code can be found at
[https://jakearchibald.github.io/streaming-
html/](https://jakearchibald.github.io/streaming-html/)

------
iainmerrick
This is great, what a nifty hack!

Arguably a little bit clickbait-y, as the headline is accurate but doesn't
mention the streaming JSON idea that's covered in the same article. That's a
much more sensible approach than abusing iframes.

And as the article also says, you'll get the benefit of progressive rendering
for free if you just don't make your site into a single page app in the first
place.

~~~
jaffathecake
ND-JSON only works for aggregations of data where the chunks are small. If
you're building a news site you can't really chunk a single article up into
ND-JSON. If you want a transition between pages then you can't use full
navigations, and if you want to keep streaming the iframe hack seems to be the
only solution.

~~~
iainmerrick
_If you 're building a news site you can't really chunk a single article up
into ND-JSON._

One paragraph per chunk?

~~~
jaffathecake
Heh, right. And if you've got something nested like a quote, a list, an aside
etc etc, how do you represent that as a flat stream of chunks?

I suppose you could implement some kind of SAX-like thing expressed as ND-
JSON…

…orrrrrr avoid all that by streaming HTML.

~~~
RubyPinch
well, blockquote, ol, ul, aside, etc etc, are all flows, and as such are not
permitted inside of p, which can only have phrasing content

right?

~~~
jaffathecake
Right, but they can all have paragraphs (and many other elements) as a
descendant.

------
the8472
transplanting a node into a different document while the document.write()
merrily marches along.

It feels like open heart surgery with a rusty knife. But I can't find anything
in the specs saying that it is verboten.

~~~
mmastrac
Technically you should be adopting the node, but I guess browsers don't care:
[https://developer.mozilla.org/en-
US/docs/Web/API/Document/ad...](https://developer.mozilla.org/en-
US/docs/Web/API/Document/adoptNode)

~~~
the8472
That shouldn't affect the parser, because adoptNode "simply" (read: dark
rituals involving goats) changes owner document and the prototype chain but
not object identity, which means the node on the parser stack should still be
valid.

The trick here is that the the invoked behavior is spread over the HTML5 and
DOM specs and maybe a little Ecmascript too. In isolation they appear sane,
combined together they are loose enough that this hack does not run afoul of
any rules.

------
Too
Isn't it standard practice to split large ajax responses into many smaller
requests to allow parallel download+render? I've done this since the very
early days of ajax. You always had to tweak the frame size though and find a
balance of download speed + request handshake time vs render speed, so having
a client side streaming solution for this would be really cool.

~~~
aikah
> Isn't it standard practice to split large ajax responses into many smaller
> requests to allow parallel download+render?

It doesn't guarantee the payload will load faster, especially on mobile.
Obviously, the solution is to avoid loading large ajax responses and only
returning from the server what is absolutely needed.

