3 ms·

Asynchronous document.write (http://github.com/eligrey/async-document-write http://github.com/eligrey/async-document-write) does mostly the same thing, and actu

by Sephr 16y ago

Asynchronous document.write (http://github.com/eligrey/async-document-write http://github.com/eligrey/async-document-write) does mostly the same thing, and actually supports real async and deferred script execution on browsers that support it. Also note that extsrc.js waits until everything, including large images which may take a while, on your page is loaded before running the "asynchronous" scripts, which doesn't sound that asynchronous to me.

rarestblog 16y ago
From the looks of it - it means that you have to modify external scripts in ADW, right? FIXED loading time to browser-specific DOM ready events. Don't see the need to use actual DEFER. Any reasons to do it?
- Sephr 16y ago
  The only reason is so that you can use the browser's native async and defer script scheduling. And yes, you need to modify the external scripts (only adding a single line to the start and end). If you can't convince the widget provider to change the script, you can place <script>document.write.to = "the URI of the following widget script";</script> right before the widget script itself. Also, on your fixed loading time thing: with onload, it still won't run until every image and iframe on your website has loaded too.
  - rarestblog 16y ago
    How many browsers support 'document.write.to'? It uses browser-specific event. onload is fallback. I've tested the slow image (20 second delay instead of image) - no, it doesn't require loading of images, scripts fire up as soon as HTML finishes loading. Sorry.
    - Sephr 16y ago
      document.write.to isn't something used by any browsers, it's something that my asynchronous document.write library uses instead of polluting the global namespace. Those image results are interesting, and I admit that I only took a quick skim of your code, so I may have been wrong to assume that it would be limited by onload.
      - rarestblog 16y ago
        It was. Thank you for noting that. It was your comment that made me look into window.onload and scrape it, replacing with more sophisticated browser-specific code. Thank you!

by Sephr 16y ago

rarestblog 16y ago

From the looks of it - it means that you have to modify external scripts in ADW, right? FIXED loading time to browser-specific DOM ready events. Don't see the need to use actual DEFER. Any reasons to do it?

Sephr 16y ago
The only reason is so that you can use the browser's native async and defer script scheduling. And yes, you need to modify the external scripts (only adding a single line to the start and end). If you can't convince the widget provider to change the script, you can place <script>document.write.to = "the URI of the following widget script";</script> right before the widget script itself. Also, on your fixed loading time thing: with onload, it still won't run until every image and iframe on your website has loaded too.
- rarestblog 16y ago
  How many browsers support 'document.write.to'? It uses browser-specific event. onload is fallback. I've tested the slow image (20 second delay instead of image) - no, it doesn't require loading of images, scripts fire up as soon as HTML finishes loading. Sorry.
  - Sephr 16y ago
    document.write.to isn't something used by any browsers, it's something that my asynchronous document.write library uses instead of polluting the global namespace. Those image results are interesting, and I admit that I only took a quick skim of your code, so I may have been wrong to assume that it would be limited by onload.
    - rarestblog 16y ago
      It was. Thank you for noting that. It was your comment that made me look into window.onload and scrape it, replacing with more sophisticated browser-specific code. Thank you!