Hacker News Reader

Comment by mike-cardwell | Hacker News Reader

What if you stick this as the first thing in your body:

  <iframe src="/file.js" style="display:none">

And then at the very end of the body tag:

  <script src="/file.js"></script>

Wont that allow us to start a non-blocking fetch of the script early, but then execute it later? I assume it wont be fetched twice. Especially if you send future Expires headers.

View on HN

If you want to initiate an early fetch, just put the <script async> tag at the top - you won't block DOM construction or block on CSSOM. If you need ordered execution, put your inline script block above CSS and add your logic there (but please keep it lean).

Could affect rendering though, since the browser may treat the js as content to render. Probably should be benchmarked to make any conclusions.

In my experience, anything with display:none is not rendered by the browser and doesn't take up any real resources. I've used this trick with infinite side scrolling slide show type interfaces when I found that beyond about 20 elements, things started slowing to a crawl. Setting offscreen elements to display:none fixed it right up.

"Doesn't take up any real resources" is anything but true. An iframe in particular is basically a new render process, which adds a lot of overhead. Just because you've set "display:none" on an element doesn't mean it's free.

That seems awfully hacky given the availability (and reasonable fallback) of the async option.

Using <script async> you don't know how much of the DOM will have been constructed at the time it executes. Using an iframe you can choose to start loading the script early, but then specify the exact point at which it should be executed. E.g, after a certain div has been placed in the DOM or after the entire body has been constructed, etc. Also, <script async> doesn't work in IE9 or below.

> Using <script async> you don't know how much of the DOM will have been constructed at the time it executes.

If you are including jQuery or similar, there is the option of having your code hook into the "document ready" events. If you are not using something like that then you could pull out what they use and implement that part yourself.

Another option, which is less clean but might be useful if you don't want to wait for all of a load DOM to transfer for instance, is to check for the parts you do need and if they are not yet present set a timer for a few 10s of ms time to check again.

> doesn't work in IE9 or below

I don't suggest holding back on using features because of old IE. Instead make sure your code works in everything but can take advantage of the extra feature in newer browsers. PEople using old IE might get a less than optimal experience, but it'll work, and those using something better get the optimal behaviour.

Of course, this falls down when maintaining backwards compatibility requires noticeable code changes rather than just accepting old browsers won't display things as nicely and/or responsively.

Reply on news.ycombinator.com