Google’s Ilya Grigorik Talks PageSpeed and Service Worker

Visit our Marketing Nerds archive to listen to other Marketing Nerds podcasts!

In this week’s episode of the Marketing Nerds podcast, I have the pleasure of talking with Ilya Grigorik, Performance Engineer at Google working on various projects such as PageSpeed, Chrome, Analyics, Google+, and Service Worker, which you will hear a lot more about in 2016. He also founded PostRank, which was acquired by Google in 2011, and wrote the book on High Performance Browser Networking.

However, it was one of his recent presentations about Progressive Web Apps that really caught my attention and got me following Ilya’s work.

In our discussion, we talk about two really important topics; 1) how important the PageSpeed score really is and whether or not a higher score results in a higher ranking, and 2) what Service Worker is and how it could change the way we develop websites completely over the coming years.

As a webmaster or an SEO, this is one podcast you do not want to miss and if you are not following Ilya’s work already, you definitely should start.

Here are a few of transcribed excerpts from our discussion, but make sure to listen to the Podcast to hear everything:

Ilya’s path to Performance Engineer at Google

I founded and ran PostRank. This was back four or five years ago where our focus was on social analytics, marketing and helping publishers understand where their topic is coming from, from the social web. Anything from Insights into where your content is being shared to who’s sharing it and how you can do better at getting that content out there. We built a couple of different products around that and eventually through various engagements, started chatting with the Google Analytics team which at that time was also trying to come up with their strategy for social.

One thing lead to another. We ended up joining the Google Analytics team and building a couple of social analytics related products within there, a couple of reports, helping some other teams within Google. At that time Google Plus was just coming about so we spent a lot of time with that team trying to help them define metrics and things they should track, both internally and exposed to the publishers. That was a very good, educational experience.

As part of that, I’ve always been passionate about performance as a general topic. I guess one way to look at analytics is performance. Performance is about getting your content out there but also performance is the more nuts and bolts way of how fast are my pages loading and we know that the more steps you add to your check out funnel, you drop the engagement rate, the slower your pages load, so all of those things combined, to me, they all fit in the same bundle.

As I was working on the social analytics within Google, I also started branching out and started working with a few other teams. At the time, we had an effort that was called Make the Web Fast within Google. As it’s name implies, that was precisely it’s goal. The goal for the team was effectively to make the web fast as a whole.

That included Google products and just the general infrastructure so under that umbrella, we had a number of different projects, anything from how do we improve performance on mobile networks to how do we improve performance of browsers and of Chrome and others came. Then there was PageSpeed which was a collection of different products from how can we help publishers automate some of the performance practices.

To some extent, my role is to float above and between different teams and help them identify problems, help them connect to other problems because that is often the case as you well know with any sort of organization, there’s one team that really solves the problem that the other team is struggling with. To some degree, it’s being that connector and also identifying opportunities where we can do better.

I work very closely with the Chrome team in particular where our goal is to figure out what do the developers need to make their pages faster and what can we do in the platform to also improve the performance as a whole.

By working with individual products, both in Google and outside of Google, trying to understand what the issues are, we can then bring that back internally, discuss what we can change in the platform and also if needed, define new APIs and capabilities that work across all the different browsers.

I’m also involved with the W3C web performance working where our mandate is effectively that, to provide, specify and help implement that necessary infrastructure to make the web better and faster.

How important is it for webmasters to pay attention to PageSpeed insights?

I think it’s very important. You said that there was a push, there’s still a push. Certainly just observing the traffic trends and what I see for products within Google and just seeing where the audience is going. It’s just very, very clear when you look at any analytics that you gather, that most of the traffic is migrating to mobile. Of course desktop is there, the tablets, but there’s just a tidal shift in how people consume content.

You have to think of it mobile because mobile introduces a different way of interacting with content. You don’t have a keyboard, you’re using touch, the size of the text matters, everything matters. It’s just a different user experience.

Similarly performance is also very different because to some degree a lot of the devices are not very powerful at all, on the other hand, you do have your high end devices as well that are as capable as some of the best computers we had just a few years back. There’s a great dynamic range if you will of characteristics.

In the PageSpeed Insights test, we actually highlight both. I was really happy when last year we added the UX criteria because that’s something that’s been missing for a long, long time where we focused on performance in terms of the hard numbers of things like how fast does your page loads.

Then think of the experience where you access a page and it actually loads pretty fast, but has the tiny text and you have to pinch and zoom and pan around and all the rest. It’s just not great. As a user, you’re not happy because even if the page loaded fast, in order to get the information that you wanted, it took you so long.

This is what we mean by mobile friendly. When you open that page, when you click on that link, it should render in a way that is immediately presenting the information that you’re looking for in a way that you don’t need to do all of these extra actions or hunt around and try to click that two pixel link.

Areas of the PageSpeed Insights reports you cannot fix (easily)

In terms of the other criteria, things like lower scores on some of the pages because of some of the things you can’t fix, this is an interesting one. This is something that we’ve actually spent a lot of time discussing internally.

For example, say you have Google Analytics on your page which I’m guessing, especially in this audience will have a lot of sites. Well, if you do and you happen to run the PageSpeed Insights report, the PageSpeed Insights report will actually flag the Google script and tell you that, “Hey, this script is only cachable for five minutes.” You should be able to do better. There’s other similar examples. Google’s not the only one. Social widgets, things like Twitter, Facebook and all the rest.

This is interesting because on one hand, you’re right, it generates a bit of a noise, where you’re saying, “Well, I can’t really fix Google Analytics. The one way for me to fix it is to host the Google Analytics script in my site but there’s a number of gotchas that come with that and I probably don’t want to do that.”

At the same time, when we look at it from the PageSpeed perspective, we look at it purely from a performance stand point. We know the things that we want to optimize and we want to optimize things like caching to make sure you’re not re-fetching the same content all the time. Each one of these requests is extra data for the user, it does slow down the page so ideally, we’d like to have a long cache time.

Then the question becomes should we special case any of these scripts, say web fonts or other things. Our stance, at least so far has been to not do that. We don’t want to treat Google scripts or other big providers in any special way because they do come with a performance cost.

It is the case that you’re making a conscious trade off and you’re saying, “Yes, I understand that adding another script on my page is going to have performance cost. That’s just by definition because I need to fetch some additional content. The value that this thing provides to me is high enough such that I’m willing to make that trade off.”

We don’t want to just hide that under the rug and say, “Oh yeah, please install as many of these widgets as you like because they don’t really affect your UX.” That’s simply not true. It should be at the top of the pile and it should be visible for you to say it.

You can look at it and say, “Yes, this is a conscious trade off. I may not be able to get to 100 PageSpeed score because I have these scripts but that’s okay and I know that this is a conscious decision.”

Does PageSpeed score affect your ranking?

The intent of the PageSpeed score, the combination of the UX and the performance, is to reflect some, an approximation of the user experience. Our goal is to have that score represent how quickly and how comfortably the page will load across a variety of different devices and different networking conditions. We try to model out of that. Out of that, there’s also the observation that generally speaking, faster pages, optimized pages deliver better user experience.

I can’t speak on behalf of the search team but in my conversations with various people on that team and certain surrounding teams, it’s pretty clear that search optimizes to improve the user experience. You’ve seen blog post that went out and said, “Yes, we look at speed,” because it is a criteria that effects user experience so you should be optimizing for user experience and speed is one of them. PageSpeed Insights is also aligned with that. How and when they actually factor it in, I’m not exactly sure but it is certainly aligned with those principals.

What is Service Worker?

Service worker is a new API in the web browser, it’s actually a collection of APIs (that’s a better way to describe it), that come together to give web applications a set of new and richer capabilities that really bring it on par and actually consider better than some of the native experiences that you’re going to have. Specifically, we’re talking about things like offline capabilities.

Let’s rewind history a little bit, in the past, the web platform has provided some mechanisms for you to provide offline experiences. Frankly, those were not very good and they did not gain much adoption.

It is certainly the case that one of the big reasons that many developers are opting into implement native applications as opposed to focusing on the web is because it can provide a reliable offline experience. If you happen to be on shaky WiFi or on the subway or you don’t have blazing, fast internet connection, or you happen to be in a market where data is very expensive, you can serve an experience that is served directly off your device so you have very reliable performance guarantees because the data is coming from your device and you’re fetching the additional data from the network.

You’re able to do things like background sync such that the user can interact with the application, even when they are flying and then when they come back online, it is synced back. Think of your email client or Gmail client. Just because you’re not online doesn’t mean you cannot use the app. You can still compose the email and press send and the email goes out. That’s another one.

Things like push notifications. So it turns out that for many publishers, especially eCommerce, push notifications are a very, very important feature. We heard this loud and clear from talking to many eCommerce providers because they want to establish that relationship with the user where they can send them a nudge every once in a while to say, “Hey, we’re having a sale,” or, “You were interested in this product and it was sold out but now it’s available.”

That is, by itself, one of the key reasons that many applications have gone native. We can do that on the web. Service worker is an combination of features that enables that.

By itself, service worker is an API that you would implement that when you come to this site, it still loads as a web page. It is a webpage. This is the best part. You come to the website, you load the page, in the background, the service worker starts executing it’s code so it’s just another script on your page.

That service worker is able to register itself, it can download certain assets such as they are cached offline. Then in the future, when the user comes back to the site, all of the requests are actually routed through that service workers script.

Once you have service worker installed, everything is routed, all the requests I should say, are routed through it, which means that you can script everything. You can intercept request and if you’re offline, you can serve a cache request. You can rewrite it, you can reroute it to a different provider, a different CDN, and provide a much richer set of capabilities.

The key point here is this is still the web and we retain all of the great capabilities of the web, which is it’s a URL, it’s instantly sharable, you can just paste the link, you can still access it on any web browser, and that’s what we mean by progressive. It starts as a webpage, it’s that still femoral experience, secure experience. You don’t need to go to the app store or click the install button, accept a bunch of prompts, go through that entire funnel.

The potential for Service Worker to merge the mobile and web experience

Big red warning here, the technical bits, the many different bits that go into making all of this work are still very much under active development. This is something that we’ve been actively iterating on within Chrome for the past year, year and a half. We’ve been working very closely with the Firefox team as well. There’s two implementations that are working on it now. If you’re getting into this today, you are probably more of the living on the edge type of developer but there are some great case studies already.

Flipkart is a big, if not the biggest, e-commerce provider in India. They wrote a really interesting post on their experience of using service worker to enable the Flipkart site as an offline site. There’s some interesting history there where Flipkart was actually a website and then their website became an advertisement for their app and then they realized that they’re actually losing a lot of users that way because the install process itself, the additional friction of the app and all the rest.

To me, one of the most interesting aspects of this, because I do tend to focus on web performance, is that it actually changes architecturally how we build our sites. It doesn’t have to but I think if you assume that this is the right way to do it, that this is the future, then it changes how you think of it, the architecture of the site. Specifically, were talking about this concept of an application shell where today … Think of a typical web page. We have some sort of a theme or frame and then typically that gets composed on a server, the server generates html on the mark up and delivers it to the client. Then maybe use XHR is another that’s going to fetch dynamic data as it’s updated. The loading of that page is still subject to how fast does your server respond, how fast is the network, are you using a CDN and a whole bunch of other variables which is to say you’re at the mercy of the network.

With the service worker, because it can serve content locally, you can actually move the frame of the page, that constant layout, directly into the device itself. When the user clicks on the page, the logo, the navigation bar, some content is immediately displayed because it’s served locally and that’s regardless of the network speed. It doesn’t matter if you’re on really fast LT connection or really slow 2D connection, you can deliver reliable experience.

This is one of the key benefits that building an app gives you. It forces you down that direction. It assumes that you have your assets locally. That’s what service worker does as well. It forces you to re-architect your applications in such that you can deliver this instant experience.

This is critical because looking back to our earlier discussion on PageSpeed and PageSpeed Insights, specially there we’re focusing on one aspect which we call the critical rendering path and that’s things like CCS and Java Script and HTML, that you need, like the minimum set that you need to get something visible on the screen, get the pixels on the screen.

With service worker, you can actually move all those critical assets into the device itself, which means that you can guarantee that pixels will be painted within hundreds of milliseconds on users clicking, which is a big, big game changer. It’s just not something that you can do, even the most highly optimized CDN deployment today.

Will Service Worker be a big focus for Google going forward?

I think so, yes. I think this will change in a very large way how we build websites. We’re already seeing some early, very good prototypes of this. I know there’s a number of Google products that they’re already actively experimenting with using this, we’re using it internally in Chrome itself.

For example, your tab page is actually powered by service worker, the new tab page. We’re still actually learning in terms of what are the APIs that we need, what are the rough edges in the existing platform, but it’s very clear already that this is going to be a game changer for a lot of different applications.

To listen to this Marketing Nerds podcast with Ilya Grigorik and Brent Csutoras:

• Download and listen to the full episode at the bottom of this post
• Subscribe via iTunes
• Sign up on IFTTT to receive an email whenever the Marketing Nerds podcast RSS feed has a new episode
• Listen on Stitcher

Think you have what it takes to be a Marketing Nerd? If so, message Kelsey Jones on Twitter, or email her at kelsey [at] searchenginejournal.com.

Visit our Marketing Nerds archive to listen to other Marketing Nerds podcasts!

Image Credits

Featured Image: Image by Paulo Bobita
In-post Photo: Image by Ilya Grigorik. Used with permission.