https://github.com/dfkaye/datauri-vs-src-test
compare load times for script.src = url, script.src = dataURI, script.text = code, and Function(code)
https://github.com/dfkaye/datauri-vs-src-test
Last synced: 3 months ago
JSON representation
compare load times for script.src = url, script.src = dataURI, script.text = code, and Function(code)
- Host: GitHub
- URL: https://github.com/dfkaye/datauri-vs-src-test
- Owner: dfkaye
- Created: 2013-07-10T00:07:22.000Z (almost 12 years ago)
- Default Branch: master
- Last Pushed: 2014-10-09T20:09:53.000Z (over 10 years ago)
- Last Synced: 2025-01-02T03:46:49.310Z (5 months ago)
- Language: JavaScript
- Homepage:
- Size: 1.44 MB
- Stars: 0
- Watchers: 3
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
README
Script loading performance tests
================================
Attempts to determine and compare load times between dynamic script loading strategies:
+ script.src = url
+ script.src = dataURI
+ script.text = code (added 1 Aug 2013)
+ Function(code) (added 2 Aug 2013)
Test page
---------
Test page loads jquery files first, then loads codebase.js.
Buttons let you re-load the codebase.js using the various strategies.
__Results__
Results indicate total time in milliseconds for each type of strategy (clean, get, run, end), plus average times.
[ 1 AUG 2013 ]
Originally this test covered only the src attribute, comparing URL vs dataURI performance, the URL
pointing to a static CDN domain. In that setup, URL generally outperformed the dataURI across
browsers - except for Internet Explorer (8-10) which processed the dataURI even faster than Chrome.
After adding the script.text strategy, the scripts needed to be modified so that all create > exec >
profile sequences were fair. That meant moving the remote script to this repo and wrapping the entire
script body in a function that could be called externally by any of the three strategies. This gives
more control over the source, and, apparently, prevents script caching in the browser, due to the
proxying done by rawgithub.
Results of the 3 scripted dom element strategies now mimic an empty cache (so it's first-hit comparison only).
The script.text = code strategy wins for all but IE where text vs URL are within 20ms (ymmv).
The script.src = url strategy performs worst - except in IE again - but previously, when hitting
the static CDN, script.src performed *best* - except in IE).
The script.src = dataURI strategy performed a bit faster than script.src = url -
except that it was __quite crash prone__ in Chrome and Firefox, and often performed orders of magnitude worse in
Firefox on the first hit.
[ 2 AUG 2013 ]
Added Function(code) strategy to compare performance vs. scripting dom elements.
[ 15 AUG 2013 ]
Added averages in display.
Chrome 28
Firefox 22
Opera 12
IE 10
src URL
600ms
600ms
520ms
200ms (amazing)
dataURI
100ms (crash prone)
125ms (crash prone)
185ms
250ms
script.text
40ms
80ms
44ms
185ms
Function(code)
25ms (100ms first time)
28ms
26ms
25ms
__Discussion__
The point of all this had been to ferret out performance gains in time-to-first-byte and time-to-load.
[2 AUG 2013 ] - However, the Function(code) strategy appears to have best performance
across the board, barely ahead of script.text = code. In Chrome, the *first* invocation
of Function(code) __always__ took 100+ ms. Tobie Langel was right. Lazy evaluation reduces
startup latency: [Lazy evaluation of CommonJS modules](http://calendar.perfplanet.com/2011/lazy-evaluation-of-commonjs-modules/)
Using dataURI means the script string is *larger* than the original source.
Using script.text and Function(code) means you have to transform or encode
or stringify the actual script source file.
Using script.src means you don't have to stringify the script file but you're then subject to
request latency over the network.
Both script.text and dataURI mean more bytes in the initial page load if they're inlined.
But if they reside as vars or map entries in a src-referenced script, then the initial html payload isn't so bloated.
[ 24 JUL 2013 ] - dataURI performance and power consumption on mobile poorer than URL fetch -
see [data-uris are slow on mobile](http://www.mobify.com/blog/data-uris-are-slow-on-mobile/)
__[1 AUG 2013 ]__
Setting window.codebase = null; in the removeScript() function revealed that script should be
attached to the DOM *before* script.text = code assignment ~ __order matters!__
__Next Up__
[ 31 JUL 2013] - explore browsers' built-in lookahead + prefetch capabilities effectively to
load additional scripts as strings, such as in a build map file with each script url containing the
stringified version of the source *(this will probably be in its own repo).*