Group items tagged

A quick intro into how the WebKit / Chrome browser works under the hood, in 30 minutes.

3 hour workshop on web performance from the ground up: what is fast, impact of latency and bandwidth, TCP performance, SPDY protocol, browser parsing and execution, rendering optimizations, critical path, and more.

My previous blog post, Cache them if you can, suggests that current cache sizes are too small - especially on mobile. Given this concern about cache size a relevant question is: If a response is compressed, does the browser save it compressed or uncompressed? Compression typically reduces responses by 70%.

Yottaa is proud to introduce Websitetest.com, a free testing tool with multivariate testing capability. In a single test, see how your website performs across multiple locations, browsers, and connectivity types. Set tests to run in the future at time increments of your choice.

At Bugsnag we use SPDY on our production rails application. For our users who run modern browsers, this can make the site feel much faster and more responsive. Want to get SPDY working on your production rails app? Read on. What is SPDY?

When we look back over the history of web performance we see a heavy focus on reducing the number of requests and getting files to the browser quickly. Our platform has changed a lot, and while optimizing for network performance remains a crucial part of our jobs, we now have to broaden our performance horizons. Our users also expect smooth scrolling, animations and interactions, even on mobile devices. In short we need to deal with not just how quickly our sites and apps load, but also how quickly they run. [video] In this session Paul takes a lightning tour of how Chrome converts the DOM into pixels, see how our code affects its workload, and arrive at a modern workflow for finding (and eliminating) rendering bottlenecks.

Or why it is better to use the `script[async]` attribute to fasten page load time.

we can tell the browser which sockets we will need ahead of initiating the actual requests via the new preconnect hint shipping in Firefox 39 and Chrome 46

getElementsByTagName("a") is faster than querySelectorAll("a") in nearly all browsers. There's one very important difference between these two methods, and it's not that one accepts only a tag name and the other accepts a full CSS selector. The big difference is in the return value: the getElementsByTagName() method returns a live NodeList while querySelectorAll() returns a static NodeList. This is extremely important to understand.

en fait, la création de la liste d'éléments est 90% plus rapide avec getElementsByTagName par contre ça peut être compensé par les accès aux propriétés, plus rapides avec la liste statique retournée par querySelectorAll : http://jsperf.com/access-to-nodes-via-queryselectorall-vs-getelementsbyta/2 donc rien d'absolu, ça dépend de chaque code