The book i'm reading is from 2010, so i want to keep only things that are important now, in 2015, and add some comments about the current situation with having ES2015 and modern libs in place.
Every time a <script> tag is encountered, the page must stop and wait for the code to download (if external)
and execute before continuing to process the rest of the page.
JavaScript’s tendency to block browser processes, both HTTP requests and UI updates,
is the most notable performance issue facing developers.
There are, however, several ways to minimize the performance impact of JavaScript:
- Put all
<script>tags at the bottom of the page, just inside of the closing</body>tag. This ensures that the page can be almost completely rendered before script execution begins. - Group scripts together. The fewer
<script>tags on the page, the faster the page can be loaded and become interactive. This holds true both for<script>tags load- ing external JavaScript files and those with inline code. - There are several ways to download JavaScript in a nonblocking fashion:
- Use the defer attribute of the
<script>tag - Dynamically create
<script>elements to download and execute the code - Download the JavaScript code using an XHR object, and then inject the code into the page
- Use the defer attribute of the
This chapter doesn't make too much sense with having ES2015 and modules system now.
Use let instead var, and use modules to not have global scopes impact.
DOM scripting is expensive, and it’s a common performance bottleneck in rich web applications. Modifying elements is even more expensive because it often causes the browser to recalculate changes in the page geometry. Naturally, the worst case of accessing or modifying elements is when you do it in loops, and especially in loops over HTML collections.
function innerHTMLLoop() {
for (var count = 0; count < 15000; count++) {
document.getElementById('here').innerHTML += 'a'; }
}
Having virtual DOM library and not working with DOM directly, like in JSX, makes this issue much more smaller.
Use forEach instead of for () loop. Compare:
Will take 8 sec
console.log(Date.now());
for (var i=0; i<10000000;i++) {}
console.log(Date.now());
Will take 3 sec
var list = new Array(10000000);
console.log(Date.now())
list.forEach(function(){})
console.log(Date.now())
Note, that in ES2015 (for .. of) is preferred from (for .. in).
And having build-in functions like map, filter, reduce makes for loops almost useles.
Watch this: https://egghead.io/lessons/javascript-introducing-reduce-common-patterns
If the interface responds to user input within 100 milliseconds, the user feels that he is “directly manipulating the objects in the user interface.” Any amount of time more than 100 milliseconds means the user feels disconnected from the interface. Since the UI cannot update while JavaScript is executing, the user cannot feel in control of the interface if that execution takes longer than 100 milliseconds.
For modern JS applications that means, that render function should be execute in less than 100ms. Conceptions like timers and Web workers that are inctoduced in this book are not usefulin reactive paradigm, well at least not on the application level.
POST versus GET when using XHR. When using XHR to request data, you have a choice be- tween using POST or GET. For requests that don’t change the server state and only pull back data (this is called an idempotent action), use GET. GET requests are cached, which can improve performance if you’re fetching the same data several times.
The fastest Ajax request is one that you don’t have to make. There are two main ways of preventing an unnecessary request:
- On the server side, set HTTP headers that ensure your response will be cached in the browser.
- On the client side, store fetched data locally so that it doesn’t have be requested again. The first technique is the easiest to set up and maintain, whereas the second gives you the highest degree of control.