Google Search is now using Service Worker to cache repeated searches, loading results twice as fast. The tidbit was shared this week by Dion Almaer, Google director of engineering, and Ben Galbraith, Google senior director of product, at Pluralsight Live in Salt Lake City, Utah.
Galbraith and Dion spent the majority of their allotted time talking up modern web technologies and tools such as AMP, Service Worker, and WebAssembly — similar to what we heard at the state of the web session during Google’s I/O 2018 developers conference in May. But Google Search leveraging Service Worker, an API for running background scripts in the browser, is new (the change started rolling out in June and was completed in July).
“Google Search’s mission is to get relevant results to you as quickly as possible,” Almaer said onstage. “So they invested in the largest deployment of Service Worker probably out there by being able to [do] extra work on the fly and give you results sometimes twice as fast.”
While the 2 times boost is certainly a substantial improvement, we followed up and learned it comes with a caveat. Service Worker is only being used in Chrome for Android, specifically version 62 and up (We’re on Chrome 68 now). Therefore, only Chrome for Android users with the latest versions are seeing the performance gains.
“Service Worker has been available for several years now, but for Search’s requirements — we’ve been continually optimizing implementations of Service Worker and also waiting for broader coverage, as well,” Galbraith told VentureBeat. Only Chrome for Android is getting the treatment, because other browsers don’t support Navigation Preload, a latency optimization apparently critical for Google Search to run a Service Worker. If other browsers add the needed capabilities, the Google Search team will expand the repeated search improvement to them, as well.
But Navigation Preload support was added with the release of Chrome 59 in June 2017, so what were the Google Chrome and Google Search teams doing between then and now? It turns out the performance simply wasn’t up to snuff.
“A lot of it is to do with optimizing the Service Worker pipeline, how quickly can it start up and do its thing, networking stack — low-level stuff,” Almaer told VentureBeat. “Given how finely tuned Search is, there was just a lot of work with the team to really optimize all those powerful ways to give it a bigger bang for buck.”
The duo nonetheless see all this work, even if it’s limited to just one browser, as a big win for Service Worker.
“Google Search is one of the biggest sites in the world. Having them use Service Worker is something that we’ve hoped to see on the platform side for a while,” Galbraith explained. “This is one of many features that they’ve been working on. As they roll it out … we wouldn’t roll out anything at Google that would be a step backward for latency or cause any issues — as you can imagine, it has to be stable. So we view it as confirmation that Service Worker is ready for prime time.”
Once Google Search starts using Service Worker in more than just Chrome, developers outside of Google will probably agree.
Disclosure: Pluralsight paid my way to Salt Lake City. Our coverage remains objective.
VentureBeat's mission is to be a digital town square for technical decision-makers to gain knowledge about transformative enterprise technology and transact. Discover our Briefings.