A while ago Google introduced Google Web Light and I finally got around to have a closer look at it. So far this hasn’t gotten a lot of attention in general, but I suppose this might have to do with the fact that it’s only meant to be rolled out in some specific countries. Nevertheless it again underlines that performance is an important factor to consider when designing and building websites and I find that Google is going quite a long way here to provide a faster web experience for countries less privileged in terms of mobile bandwidth.
I believe that this should actually be somewhat taken care of by us, designers and developers of the web, but I’m not going to get into this, since it would be more than enough material for another post. And there have been many.
From the official Google Webmaster Central Blog:
In two weeks, we’re starting a field test in Indonesia to provide streamlined search results and optimized pages when the user searches on slow mobile connections, such as 2G. Our experiments show that optimized pages load four times faster than the original page and use 80% fewer bytes. As our users’ overall experience became faster, we saw a 50% increase in traffic to these optimized pages.
Update on June 11, 2015: Following the successful field test in Indonesia, soon we will be bringing this feature to India and Brazil.
I have tried it out on a few sites and it seems to do its intended job quite well. The results aren’t too pretty, but in the majority of cases you do get to enjoy the main content, since it is mostly readable. I’d even argue that the quality of the site displayed through Google Web Light is a good indicator of how well and how progressively enhanced a site has been built.
There’s quite a few things going on before a light site is shown to a user. For the most part it’s all about removal and compression. Following is a list of things which are getting stripped or modified, which I don’t claim to be complete, but it’s what I noticed so far:
- Main navigation and site logo gets removed (I think thi is usually the whole header, which even works if there is no
- Remove all media queries from the stylesheet – this leaves you with the mobile version (sort of), no matter if the site was built mobile-first or desktop down (media-query-wise)
- Remove class attributes and inline some of the original site’s CSS (I’m not sure what and why gets stripped here, since some rules containing e.g.
margin-bottom, but not the
margin-rightproperties. This behaviour doesn’t seem consistent, since not all properties get stripped the same way, as some of the observed pages have shown)
- List style is set to
none, removing bullets and thus even overwriting UA default styles
- Inline and base64-encode all images, resize and compress them a LOT. The compression for JPG’s seems to be around the ~10% quality mark. (In one of my tests this way a 340Kb image came down to <6Kb)
- Extract the main navigation links into Google’s own off-canvas menu
<style>tag with some Google light page specific styles for loading etc.
- Furthermore Google adds some JS around the Performance Timing API and I suppose this might be recorded for their own stats.
For some reason a small number of the sites I tried couldn’t be transcoded, but so far I haven’t found a clue to why that happens:
Transcoding test failed: Fetching from the origin site failed or timed out.
If you want to try this out and see for yourself how your sites hold up against this, you can add the full URL of your site URL to this link, replacing everything after the “=”.
Have fun and enjoy the light ride! ;)