“The future is already here” – Interview with Google’s Ilya Grigorik

Wonder what technology innovation to expect within the next few months? What’s going to change? What are people in Google working on right now? We conducted an interview with one of Google’s most iconic representatives who shares a powerful message – The future is already here.

Ilya Grigorik is a web performance engineer at Google and co-chair of the W3C Web Performance Working group. He was also one of the speakers on this year’s two major conferences: Google I/O conference and SmashingConf. Ilya possesses great insight on what’s happening now and we asked him to share some of his technological insights. We’re delighted that Ilya agreed and we could  make this interview happen.

What 3 technology innovations or innovative development techniques will have the biggest impact on web developers in the next year or two?

There is a lot of really exciting and very important work happening at the transport layer: HTTP/2, QUIC, TLS 1.3. We could spend hours on each one, but in the interest of time, I’ll just mention a few highlights…

First, HTTP/2 adoption is growing rapidly, which is really great to see! However, while the RFC (7540) is done, there is still a lot of implementation and optimization work that we (the web perf community at large) need to do to make the most of it. For example, we need to build new benchmarks and testing suites for servers that actually exercise the new prioritization primitives (hint, it’s not just number of requests, but also how the bytes are sequenced); browsers need to get better at communicating priority information to servers; we need to develop new best practices and common APIs for server push; browsers need to rationalize how they treat and expose pushed resources to applications; we need to revisit our old “best practices”around how we deliver resources (bundling, etc), and so on. In short, there is still a lot of important work to be done here.

TLS 1.3 is nearing completion and—fingers crossed—we may actually see it rolling out by the end of the year, and worst case early next year. The spec contains a lot of cleanups, improvements around security and privacy, and of course… 0-RTT handshakes for repeat visitors! For the curious, check out the ekr’s talk for more details. Finally, IETF is kicking off a new working group for QUIC (soundbite summary: HTTP/2 over UDP), which opens up yet more optimization opportunities for improving mobility, performance in high latency environments, and so on—see Chrome’s experimental results.

Popping up a few levels, there is also a lot of really exciting work happening in the browser that will change how we build and deliver applications. For example..

1. There is ongoing work to enable better “defense in depth” mechanisms to help deliver more secure applications: HSTS, HPKP, CSP, SameSite cookies, Feature Policy, moving existing and new powerful features under secure origins, and so on.
2. The combination of ServiceWorker, Fetch and Cache APIs, push notifications, and a large supporting case of other smaller but no less important APIs is enabling us to build and deliver performance resilient applications: all critical resources live on the client, the applications are offline and poor-network friendly, background sync, push notifications, etc.

Best of all, much of the above is already available and is being used with great success in production— the future is already here, it’s just not even distributed across all the browsers… yet.

IPv4 addresses have been depleted some time ago. When do you expect the internet to go fully IPv6?

Soon™. Of course, that’s what we’ve been saying for a couple of decades now, but the data shows a clear trend up and to the right: IPv6 adoption has been doubling every year. You can extrapolate from there.

Where would you like to see the Content Delivery Network market shifting in the next year or two? What would you like the product to look like?

I don’t have a crystal ball to see where the CDN market will head, but I can provide a few items from my own wishlist: 

• Free and optimized TLS on by default for all customers: TLS 1.3; integrations with LetsEncrypt; TLS to an origin.
• Optimized end-to-end HTTP/2 deployment (client to edge and edge to origin), with well-tuned support for prioritization, server push, etc.
• QUIC…

What projects are you currently working on?

The bulk of my time is spent on making sure that web developers have the right tools and APIs to measure the performance of their applications. A big part of this is maintenance and improvements to existing APIs developed by the W3C WebPerf working group. The other half of my time is spent on debugging production applications to understand where the problems are, and then working with browser developers to figure out where and how we can fix these problems, whether we need to expose new APIs or primitives to help developers resolve them, and so on.
One big area of focus right now is on understanding how we can improve “post-load” experience: fast response to user input, smooth scrolling, energy efficiency, and so on. We have a fairly robust toolkit for optimizing the initial load, but not so much for the experience afterwards. Projects like requestIdleCallback and Long Task API are a couple recent examples of these efforts.

Which technology innovation, be it software or hardware, will have the biggest impact on the speed of the web itself?

I think each of the efforts I mentioned earlier will have significant impact. That said, I’ll call out QUIC once more from a different angle: one of the often overlooked properties of QUIC is the fact that its a user-space protocol, which means that we can experiment and ship new versions independent of the OS network stack. With QUIC we’re no longer limited by the ~decade long kernel update and upgrade cycle! This is a huge win, as it means that we increase our rate of learning and experimentation. We can learn how to make the web faster, QUICker…

If you’d like to read more of what Ilya has to say, we recommend reading his book: High Performance Browser Networking. It’s full of practical hands-on advice you can apply during the development process to build not only fast but also resilient apps.