3 ms·

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 sr

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.

troels 12y ago
Could affect rendering though, since the browser may treat the js as content to render. Probably should be benchmarked to make any conclusions.
- eric_h 12y ago
  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.
  - igrigorik 12y ago
    "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.
igrigorik 12y ago
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).
MBCook 12y ago
That seems awfully hacky given the availability (and reasonable fallback) of the async option.
- mike-cardwell 12y ago
  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.
  - dspillett 12y ago
    > 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.

troels 12y ago

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

eric_h 12y ago
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.
- igrigorik 12y ago
  "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.

igrigorik 12y ago

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).

MBCook 12y ago

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

mike-cardwell 12y ago
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.
- dspillett 12y ago
  > 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.