Interview With Google's Ilya Grigorik On His New Book: High Performance Browser Networking
If you are Google you don't just complain about performance on the web, you do something about it. Doing something about web performance is the job of one Ilya Grigorik, Developer Advocate, Make the Web Fast at Google, and author of a great new book: High Performance Browser Networking: What every web developer should know about networking and web performance.
That's a big topic you might be saying to yourself. And it is. The book is 400 plus information packed pages. But never fear. Ilya writes in a very straightforward style. It’s like a man page for the web. Which is a good thing.
In case you are not familiar with Ilya, he's the perfect choice for writing such an ambitious book. For years Ilya has been producing excellent content on his blog and if you search YouTube you'll find presentation after presentation on the topics found in the book. Authority established.
Reading the book I was struck by what a complicated beast or little World Wide Web has become. That's clear from just the chapter titles: Primer on Latency and Bandwidth, Building Blocks of TCP, Building Blocks of UDP, Transport Layer Security, Introduction to Wireless Networks, WiFi, Mobile Networks, Optimizing for Mobile Networks, Brief History of HTTP, Primer on Web Performance, HTTP 1.X, HTTP 2.0, Optimizing Application Delivery, Primer on Browser Networking, XMLLHttpRequest, Server Side Events, WebSocket, and WebRTC.
I've often imagined there's a white board at Google with "Don't Erase!" written in red at the top. On it is a complicated diagram of every part of the web and Google's master plan for making that part better. The book reads a little like that imagined diagram. The Primer on Latency is a real eye opener. If you wonder why people are always going on about latency then this chapter is for you. The chapter on Mobile Networks is really good, it fills in a lot of details in an excessively complicated space. With HTTP 2.0 on the horizon you can learn about the entire thing here in full on gory detail. I'd never heard of Server Side Events before so that was enlightening. And the WebRTC chapter has an amazing amount of detail on an exciting new browser capability.
If you've been burned by books that were just reprints of manuals and specification documents, that's not the case with this book. It's full of practical real-world advice. For example, there' one example of how "Apple engineers saw a 300% performance improvement for users on slower networks once they made better reuse of existing TCP connections within iTunes, via HTTP keepalive and pipelining!" Bits like this can be found throughout the book.
And many chapters end with a practical set of things you can do to implement all the stuff you've learned part. For example, the WebRTC chapter ends with a Performance Checklist that begins with a few sections like:
Signaling service• Use a low-latency transport.• Provision sufficient capacity.• Consider using signaling over DataChannel once connection is established.Firewall and NAT traversal• Provide a STUN server when initiating RTCPeerConnection.• Use trickle ICE whenever possible—more signaling, but faster setup.• Provide a TURN server for relaying failed peer-to-peer connections.
Almost every chapter has solid practical advice like this on how to make the web faster for your application.
Here's my email interview with Ilya Grigorik on High Performance Browser Networking. Enjoy.
Please Tell Us Who You Are And What You've Brought To Show And Tell Today?
I'm a web performance engineer and developer advocate at Google. My primary focus is on the network side of things: optimizing protocols, content delivery, server and client networking performance, and just about everything in between.
After Spending A Good Chunk Of Your Life Writing This Book, Can You Summarize It In Just A Few Sentences So People Will Know Why It Should Matter To Them?
Regardless of the platform, or the form factor (desktop, laptop, tablet, etc.), you can be sure that the device will have a web browser. As a result, the web browser is the most widespread deployment platform available to developers today - we're talking billions of devices and users around the world! The goal of my book is to lay the foundation for how to build high performance, connected applications in the browser: network protocol optimization, performance best practices, common gotchas, and so on.
What’s in Your GitHub?
github.com/igrigorik - as you can tell, I'm a big OSS and GitHub fan. One of my fun side projects: http://www.githubarchive.org/.
Everyone Knows the World is Moving to Apps, Yet Your Book is Focussed on the Web. Why Waste Your Time Like That?
First, networking performance is equally critical to every platform. Second, the underlying protocols are all the same: TCP, TLS, HTTP. The client APIs is what's different, but the end result (aka "app experience") is all the same - in fact, I think the difference is already mostly superficial and will only get more narrow as time goes on. Case in point, "web views" can be found in most every native app, and web apps are now also moving in the opposite directions: offline mode, install to home screen, and so on.
What Aren’t People Getting that You Really Want Them to Get?
I think most developers still don't appreciate the importance and limitations of latency on web performance. Specifically, the fact that roundtrips, not bandwidth, is now often the bottleneck for most applications. To be concrete: streaming HD video is bandwidth bound, but loading the page hosting the video, with all of its assets, is latency bound.
Once you convince yourself that latency is indeed the problem, then your entire outlook changes, and you'll quickly begin to recognize problems and optimization opportunities everywhere you look: optimizing underlying transport protocols (TCP, TLS, etc.), content delivery strategies, structure of your pages, choice of application transports, and the list goes on! Once you know where to look, there are a lot of low-hanging fruit for virtually every site and application out there.
In my book, I've tried to approach the subject both from the "how" and the "why" perspectives: first, explain how the underlying protocols work and their limitations and then focus on practical advice for optimizing each one. The book starts with the nuts and bolts of TCP, TLS, and UDP, then dives into how the mobile radio and carrier networks work under the hood, and then works "its way up" through HTTP, XHR, WebSocket, and WebRTC.
What’s Your Personal Tech Stack Look Like (phone, tablet, etc)?
I try to keep it simple. I have three things with me at all times: my laptop, my phone (currently, Nexus 4), and my camera (Fuji XE-1), and that's about it.
Since Google Has Become Evil, What’s the Real Motive behind Make the Web Fast?
First, it hasn't. The goal and motivation for "making the web fast" has always been very simple: faster and more accessible internet means more happy internet users because they can find relevant information and do so quickly. This is why Google has invested so much into this space: improving protocols, laying fiber (and launching "Loon" balloons as of recently!), building faster clients (Google Chrome), and so on. Also, as Vint Cerf likes to point out, the majority of the world is still offline... we still have a lot of work ahead of us!
What Do You See Changing With These New WebRTC Capabilities?
Historically, browsers talked to servers. With WebRTC, we now have access to a full user-space UDP stack in the browser! I don't think the full implications of this have yet registered with most web developers -- in large part because we've never thought about what this can enable. The peer-to-peer video streaming makes for a nice demo, but that just barely scratches the surface of what's possible. I don't have a crystal ball to predict where we'll end up with P2P in the browser, but I know it will be very exciting watch.
Since Phones are Becoming so Powerful and Networks are So Fast, Can We do Away with Edge Caching?
See my earlier point about importance of latency. No amount of CPU, GPU, or RAM will help you if your application is blocked on the network, waiting to receive the resources required to construct the page. Edge caching reduces the roundtrip times between the client and server by positioning the bits closer to the user. As a result, no, edge caching is definitely not going away. If anything, it's only becoming more important due to growing demand for "real-time" interactivity and responsiveness from our applications. Not to mention the many other benefits of edge cases, such as traffic offload, content optimization and caching, and so on.
Give Me Your Ripple Of Evil. What Happens Without Your Book?
We are all stuck staring at blank white pages after every click for multiple seconds. Nobody wants that.
A Lot of People Complain that Prefetching, One Of The Key Mobile Performance Boosters, Kills Their Data Caps. Just How Wrong Are These People?
In all likelihood, prefetching is not the culprit. More likely, the app is fetching unnecessary content due to misconfiguration, missing compression, or misconfigured caching -- it's surprising how many apps still get the basics wrong! A well implemented prefetch strategy may incur some overhead, since you are by definition attempting to predict the future, but careful measurement can help you tune this tradeoff.
So Your Book, Is It The Best Book On Web Performance Or The Greatest Book On Web Performance?
I partition "web performance" into three broad segments: network, compute, render. I wrote HPBN with the goal of providing the best go-to resource for learning about and optimizing networking performance. That said, I'll let the reader judge if it lives up to that promise!
Should We All Move to Kansas So We Can Get Google Fiber’s 1Gbps and Single Digit Latency For The "Last Mile"?
I've been seriously considering this myself for some time now. In short, yes.
You Wrote the Book and Offered Free Chapters Online So People Could Read and Comment. A Very Public Process. You Found A Lot Of Errors This Way. How Did This Agile Approach Work?
Ship early, ship often, get it in front of your customers for feedback, and then iterate from there. I can say with confidence that this applies equally well to writing a book, just as it does for any other project. Getting the book in front of people working on these problems (both implementors and web developers) was key to finding the right mix of practical "how" and "why". By the way, the book is still and will continue to be available online and free (but you're more than welcome to buy a copy also :-)).
The Picture You Paint of the Browser Is That It Has Become Very Complicated With Many Ways to Send and Consume Data (Ajax, DataChannel, WebRTC, WebSocket, SSE). Has The Browser Jumped The Shark Complexity-wise?
Actually, I would argue that it's pretty simple once you know the underlying mechanics and use cases for each of the API's. Take AJAX, SSE, and WebSocket: AJAX is optimized for HTTP request-response, SSE is for server-side streaming over HTTP, and WebSocket is for bi-directional streaming. On the other hand, WebRTC and DataChannel are for P2P communication. Once you know your use case, you can quickly narrow down the list to one or at most two API's. From there, you need to take a look under the hood of each protocol to understand how it works, and how you should optimize your application code to get the best performance from it. That's what HPBN is all about.
You Took a Quantified Self Approach to Writing This Book. What Did You Learn?
Well, first, I've learned a lot about web performance -- working on HPBN forced me to clarify a lot of important details I've overlooked before, relearn topics I thought I understood but really didn't, and so on... Turns out, I've spent just north of 1000 hours working on the book (I tracked all of my time via RescueTime, plus old-fashioned paper and pen logging). Other things I learned and re-learned along the way: consistency and showing up is key, deadlines are critical, and getting early feedback is invaluable.
HTTP 2.0 Looks Like a Technology Only a Mother Could Love. Why Should We Kiss This Baby?
I'm curious what makes you say that? HTTP 2.0 can't come soon enough, as it will address a large number of limitations in our stacks. Case in point, techniques such as domain sharding, concatenation, spriting, and inlining are all ugly (but necessary) hacks that we have to live with due to limitations of HTTP 1.X - as web developers, we shouldn't have worry about any of that. HTTP 2.0 will make our applications faster, simpler, and more robust. I have several chapters on these topics in the book...
Now That You Have Some Free Time Again, What Are You Going To Do With Your Life?
Well, now that I've documented all the best practices, the plan is to focus on helping web developers put them into practice! As an industry we can do so much more in terms of better diagnostics, tooling, and automation - an area I've always been passionate about and see myself focusing on even more so in the future.
