By Addy Osmani CHAPTER 6A large amount of the Web’s traffic is images — well over half^5 accord-
ing to the HTTP Archive. In many parts of the world, users have fixed data
caps on mobile, meaning that if this cap (e.g. 1GB per month) is exceeded
the customer has to pay more. This is one reason it’s important for images
to be optimized as much as possible. At the moment, newer formats like
WebP^6 offer some substantial file size savings compared to the equivalent
quality of a JPEG or PNG. I say quality because you can usually beat a
codec if you lower your quality in another format. For those lucky enough
to be running their own servers, some of my colleagues at Google rec-
ommend trying out mod_pagespeed^7 — a tool which can automatically
optimize your site, handling minification and image optimization without
any effort. I’m also happy to recommend ImageOptim^8 and JPEGMini^9 for
image optimization.
CoMPuTe
We refer to JavaScript processing as “compute”. All of it runs inside a ded-
icated engine in the browser (e.g. V8 in Chrome, JavaScriptCore in Safari,
OdinMonkey in Firefox) and in many cases these engines are blazingly
fast. One of the reasons they’re so fast is that the engines keep an eye on
your code and swap it out with optimized lower-level code where possible.
JavaScript developers regularly worry about memory leaks being in-
troduced by their code. Since we don’t handle the retention and release of
memory ourselves and leave this up to the garbage collector, we have to be
careful not to do silly things like leaving references to objects we no longer
need hanging around. Memory usage from all of these hanging objects oth-
erwise grows over time and that’s basically what causes a memory leak —
the garbage collector not being able to release something because it thinks
5 http://smashed.by/growth
6 https://developers.google.com/speed/webp/
7 http://smashed.by/pagespeed
8 http://imageoptim.com/
9 http://www.jpegmini.com/