High Performance Mobile Web by Maximiliano Firtman - Review and notes
Last month (May 2020) I read this book on web performance by Maximiliano Firtman. I'll give you a short summary of the key takeaways of the book
and what I think of it as part of my review.
I also added my personal notes that I took while reading the book. These are bullet
points on what I found interesting and they aren't always self-explanatory.
That's why I recommend that — if you find the topics mentioned interesting — you get a copy of the book here (affiliate link*) and support the author.
The idea of sharing the notes I took came from a video about note taking by Thomas Frank.
The author also published a newer book — Hacking Web Performance (2018) — which you can read for free here .
I just found out about this book after finishing this one though and I haven't read it yet.
ThoughtsI've been researching the internet about performance metrics and how to improve the performance of webpages for quite some time
before reading this book. That's why I recognized many things mentioned in this book already. Nevertheless, it made
my understanding of the topic more complete by connecting the dots and adding valuable insights and ideas on how to
improve performance.
Reading this book motivated me to implement some of the optimizations suggested in my own work and projects and I'll certainly
take it as a reference in the future when doing performance optimizations as well.
What I find interesting is that the author's personal webpage is slow .
Key takeawaysThe book guides you through the whole process of optimizing performance. It starts by exploring the mobile landscape and continues
explaining the most important metrics and tools you can use to measure performance. After that, the author explains how
to optimize performance — first for the first visit and then for repeat visits and mobile devices.
My main takeaways are:
(High) performance is important — especially on mobile devices -> every millisecond counts Before improving performance, measure Optimize for the first visit , after the first load and responsiveness Lots of ideas for improving performance Book notesThese notes are by no means a comprehensive summary of each chapter but rather notes on what I found interesting
or useful .
Chapter 1: The mobile web worldThe author goes over the current state of technology at the time of writing the book (2016). This includes:Mobile browsers/ mobile web platforms/ web apps and their differences Comparing different rendering engines and JavaScript execution engines Mobile devices available (hardware) Networks Operating systems Rendering engines (or layout engines)In charge of parsing, downloading and rendering HTML, CSS, images, svgs, etc. Most wide spread engines are WebKit, Blink (from Google), Trident (IE), Gecko, Presto (Opera, now using Blink). Execution engines - In charge of executing JavaScript codeClassic engines -> interpret JS while executing JIT engines (Just In Time) -> precompile JS (just) before it's being executed Some browsers, such as Opera or Android browser, are not relevant anymore due to their low marketshare.
EmulatorsSimulate hardware and software Device doesn't know it's not a real phone SimulatorsSimulate only parts of the real deviceNot suited for performance testing Testing on real devicesBetter feeling of performance and UX Open device labs are places where you can go and test you site on real devices for free (all over the world)Cloud based testing is a good alternative to open device labs Desktop simulatorsAllow you to throttle network / CPU On-device connection simulatorsConnect to a real device through a desktop computer Lets you simulate a 3G connection on a real device (example is using iOS) I found this chapter especially useful since it sheds some light on the confusing metric jungle.
Loading measurement basics
The blue area is what represents the speed index. The smaller this area is, the better.
Responsiveness measurement basicsResponsiveness depends on harware, engines, screens Measurements involve:Feedback lag (like ontouch) Frame rate (while scrolling or animating) Network time for on-demand resources (XHR)
-Things that affect responsiveness that are out of our control are: Video acceleration and GPU memory CPUs JS runtime (JIT or not) RAM Frames per secondPersistent 30 fps perceived as faster than 60 fps that sometimes drop to 30 Profiling chartsTypically most interesting is CPU and memory Profiling affects performance Remote inspectors (for real devices)Available for Safari and Chrome Chrome rendering settings (for performance measurements)Show FPS meter -> directly see it on the device Continuous painting mode -> find out if content takes too much time to render Show paint rectangles / Show composite layout bordersHow is the browser rendering Show potential scrolling bottlenecks Proxy for devices that don't support remote inspectorsOnly able to measure network requests (Waterfall) Online tools Webpagetest Pagespeedinsights (lighthouse) Monitoring services New relic, Neustar, Keynote, Pingdom, etc. Navigation Timing APIs (navigationStart, domInteractive, etc.)Whole list in the book, explaining each of the available APIs can be used for analytics or to make live decisions on the fly timing.js -> script to get even more timings Resource timing APIs -> list in the bookNetwork APIs Online event -> not reliable, use offline.js or check with own server to check if network is available Network information -> bandwidth, type (Wifi, etc.)Only available in Chrome Could be used to decide if HD or SD videos should be delivered Metered -> connection might be limited by ISP Don't rely on Wifi if you want to check if the user has a fast internet connection Wifi could be available on a bus through a 2G connection Beacon API Can be used to send data when the page is left document.onunload
-> navigator.sendBeaconDoesn't harm performance or delays the load process of the next page window. onunload = ( ) => {
navigator. sendBeacon ( 'http://target-url.com/on-unload' , data) ;
} ;
HTTP Client Hints
Provides additional info about the device/browser in the HTTP header UI APIs
Page visibility (document.hidden)If page is being viewed or not (tab active) requestAnimationFrameFor consistent animations requestIdleShouldn't take more than 50ms User timings
performance.mark (I wrote an article about this here ) Frame timings
setImmediate (better than setTimeout(fn, 0)) HTTPEnable keep alive on the server Support HTTP2 CompressionGzip most common Zopfli -> for static sites Brotli -> alternative to Gzip, 25% greater compression BDHC -> Shared dictionary -> warms up the cache by analyzing traffic Don't compress already compressed files and formats (like most images) Avoid redirects HSTS - Strict Transport PolicyForces SSL (Redirect) Website can be whitelisted as HTTPS in some browsers (link here ) Don't use app banners for the landing page (this can result in a 69% bounce rate)Show them after a few page visits Use native platform tools (iOS, Android) Reducing requestsEspecially useful for HTTP 1.1 (v2 is using compression and allows more simultaneous requests) Domain ShardingHTTP limits the amount of requests only per host Splitting the request up into different subdomains will trick the browser into requesting more resources in parallel Not so usefult for HTTP2 Cookieless DomainCookies are sent by default with every request Set up a different domain for resources which don't need the cookie data Separate API from static files to take the load off the server Flush the HTML early Use DNS prefetching CSS<link>
tags block the rendering of everything below itWebfonts -> If a CDN is used, the user might already have it in the browser cache JavaScriptCritical JS for rendering the first visit should be inlined (<script>
tag) The rest before the closing tag of the bode (</body>
) Images should fit the dimension they are displayed with There are frameworks for Server Side Rendering (SSR) only on the first visit (React, Angular, etc.) Chapter 7: Optimizing after first loadPrefetchingThere are different approaches, from browser implementations with HTML or HTTP headers to prefetching with JS Cache: Data can be stored in browser- or custom cache Application cachePrior to service workers Not so interesting anymore since service workers are supported by all modern browsers Service Worker Core technology of PWAs (Progressive Web Apps) Provides a cache storage API Cache is not automatically deleted when Service Worker is updated Background Sync API Background Periodic Sync API Chapter 8: Optimizing responsiveness and the post-loading experience< meta name = " viewport" content = " width=device-width, initial-scale=1" >
Mobile optimized viewport
Frame rate Chrome has a paint flashin option that shows when something is rerenderd Avoid executing JS while scrolling (some browsers even block JS during scrolling for you) Add momentum to overflow: scroll
-webkit-overflow-scrolling: touch
allows the browser to optimize this component CSS containmentChanging elements with JS can trigger other elements to repaint due to CSS rules Such CSS rules are sibling selectors, descendant selectors, "nth-child", ... Use CSS contain
(e.g. contain: size
) to prevent elements from repainting when the layout changes Network communication Server-sent events -> like websockets but unidirectional (server -> client) Chapter 9: Responsive web designNot only the UI, but also performance should be different on mobile devices.Avoid using one HTML file for all device (same goes for CSS, images, other resources) Use conditional loading for resourcesDon't rely on media queries -> Files can be downloaded by the browser anyway Use JS's matchMedia
query on devices whose context will not change (iPad won't suddenly change to a desktop) Alternatively, there are libraries for this like Enquire.js Resize from big to smallPhones don't resize to iPads Different HTML for phones (based on screen) Desktop HTML UI should still be responsive In this chapter the author shows some extreme measurements that can be taken to gain the best performance possible. The goal is to load all the data necessary for the first page visit within one single TCP package This means that in 14.6KB we need to include everything necessary Only load things required above the fold (ATF) Embed images as data URIs Use viewport of phablet for development as a reference CSS-extraction tools give you the code of the viewport (See "Critical" on Github) Lazy load the rest ImagesClient hints (CH) in the HTTP header tell the server which images are supported Non-blocking image decodingDecode image in web-worker Serve low-res images first and replace them later on (blurry photos like on medium) JavaScriptShould be avoided first No big framework (> 10KB) Use server side rendering first SD/HD pattern -> depending on the client hints, offer a lower resolution of media resources PRPL Pattern - Push-Render-Precache-Lazy Load Future (or present now): WebAssembly, WebStreams This chaper lists all the metrics and optimizations seen in the chapters before.
*As an Amazon Associate I earn from qualifying purchases.
Further reading