Two weeks ago I mentioned using async/defer in scripts at the bottom is not enough. Growing with the Web has a nice visualization of how async and defer attributes work. Peter Beverloo has another here.
Keep in mind defer is broken in IE <= 9.
You may remember one of the original webperf rules was to put scripts at the bottom.
– The preload scanner scans the whole document as it comes in and issues fetch requests.
– The main parser sends a signal when it reaches the start of the body and sends fetch requests for any resources it discoveres that are not already queued.
– The layout engine increases the priority of in-viewport visibile images when it does layout.
– The resource loader treats all script and css as critical, regardless of where it is discovered (in the head or at the end of the body). see crbug.com/317785
– Resource loader loads in 2 phases. The first (critical phase) delays non-critical resources except for 1 image at a time. Once the main parser reaches the body tag it removes the constraint and fetches everything.
TL;DR: don’t use defer for external scripts that can depend on eachother if you need IE <= 9 support
Even after 20 years of development there are days where browser environments still feel like the wild west.
When you assign a DOM element an ID, that ID becomes part of the
window object. No joke, in the spec even ( emphasis mine ):
7.2.4 Named access on the Window object
The Window interface supports named properties. The supported property names at any moment consist of the following, in tree order, ignoring later duplicates:
the value of the id content attribute of any HTML element in the active document with a non-empty id content attribute.
On josephscott.org the sidebar section has an ID of “sidebar”, which is easily accessed in the Chrome Console:
document.getElementById( 'thingid' );, which is significantly faster.
I ran across a jsperf.com test of a for loop vs foreach and I was surprised at the difference when running the test in Chrome 38:
The for loop consistently came out over 40 times faster than the foreach.
Adam Bard has compiled a list of the most popular used languages for projects hosted at Github for 2014 ( 1 Jan -> 31 Jul ).
Drew McLellan wonders Why is Progressive Enhancement so unpopular?:
Simon St. Laurent touched on this as well in Web Application Development is Different (and Better):
Let’s extend the Web and help it do more – but let’s do that by valuing the many strengths it already brings.
Intentional or not the last few years have brought us a strong push to ignore the idea of progressive enhancement. In many cases that has been to our detriment.
The W3C recommendation on Page Visibility was updated this week. Being able to detect if a tab currently has focus is an opportunity to adjust features and performance accordingly.
The HTML5 Rocks tutorial on Page visibility has example that automatically pauses a video when the tab is out of focus. The Mozilla Developer Network also uses the video pause example for Page Visibility. Must be the “Hello World” of Page Visibility examples.
Another example would be to turn down the update frequency when a tab is out of focus. No point in updating a page every second, even with a websocket, if the tab is in the background. The Page Visibility API makes it easy to dial the frequency down to something more modest, like once a minute, then turn it back up again when the tab gets focus.
Browser support for the Page Visibility API is pretty good in current versions. The two exceptions are Opera Mini and the Android Browser.
To deal with cross browser differences check out Visibility.js.