While working for Wilshire Law Firm our team had the privilege of being invited to Google’s Mobile Speed Hackathon. The premise is simple: Take a web page and make it load as fast as you can. Now, one could easily do this by only loading a blank gqzipped page from a CDN, but that’s not the point of the challenge. The point is to think outside of the box an come up with creative ways to deliver content to the masses. By focussing on speed we, as developers, can bring a better user experience to the world.
According to Google, the majority of mobile users (70%) until 2020 will connect to the Internet through a 3G network. In a “Think With Google” article, they state:
“Our research has been eye-opening. For 70% of the pages we analyzed, it took nearly seven seconds for the visual content above the fold to display on the screen, and it took more than 10 seconds to fully load all visual content above and below the fold.”
The bottom line here is that it doesn’t matter how awesome and/or pretty you think your website is. If a user ditches your site before they get to interact and make a decision on engagement then it doesn’t matter. Your site will just be another blip of frustration and the likelihood of them revisiting later is about 1 in 5 according to an online shopper survey conducted by Akamai.
Hackathon: What To Expect
Prior to the Hackathon, I must admit that I was intimidated because I wasn’t quite sure what to expect. I search quite a bit but couldn’t come up with a clear answer as to what I should expect. So, here’s it goes. Here’s what you should expect if you’re invited to take part in a Google Hackathon.
First, show up a few minutes early and enjoy some refreshments and a catered breakfast. The spread of food and drink is quite impressive. You’ll have time to get your laptop setup, plugged in and connected to WiFi. You’ll receive a badge and your team will be grouped together with a place tag on the table.
Once things get started, you’ll be given some great stats and info regarding the importance of mobile speed. A handful of useful online tools will be shared. These tools include Test My Site, PageSpeed Insight, and WebPageTest.org. The rules are explained and quite easy. You have about 6 hours to take your project and make it as optimized / fast as possible. You will be given a presentation template to be used to highlight the steps you’ve taken and the results.
Around midday you can, if you want, break for a catered lunch. This is followed by a short talk. The talk we received was in regards to integration on AMP on eComm sites. You can, as I did, work during the talk. . . and during the lunch.
After the “Final Countdown” is finished, teams are broken off into smaller groups. One or two Googlers accompany each group into a separate room. Then, each team is given the opportunity to give their presentation. Each team and the Googlers have their chance to ask any questions or give any input.
Once the groups are finished, everyone reconvenes and after-hack drinks are served along with some more catered snacks. Our group toasted with champagne and talked about what we accomplished. The Googlers discuss the various presentations and decide on the winners of each group. Everyone returns back to their seats and the top 5 winners are announced. Our team was happy to have been chosen as one of the top 5 teams.
Each of the top 5 groups is given four minutes to give a final presentation in front of all of the teams and Googlers. As with the previous round, other teams and Googlers have a chance to ask any questions that they may have. After the presentations are done, a final short talk is given while each participant of the Hackathon casts their vote for a final winner.
At the Los Angeles Hackathon, a couple of awesome developers at TrueCars.com earned the title of winners of the Google Mobile Site Speed Hackathon – Los Angeles. Their team did an amazing job in discovering an issue with a popular CDN and creating a hack to patch up the issue. I won’t get into exactly what they did as that’s a story for them to tell if they wish.
Our Team’s Site Speed Hacks
To start with, our project page was a landing page measured 1.6MB in size, had a mobile load speed of 13 seconds, and a Speed Index of 13,484. The page utilized bootstrap and had both images and videos. Our end result was a page size of 169KB, 3.8 second load time, and a Speed Index of 2216. How did we shave off that much of a page without altering the user’s experience?
We started by prioritizing our efforts by first going after the lowest hanging fruit. For us, that was the images and embedded YouTUbe video. We wrote a simple script deferred loading (lazy loading) where we use a 1 x 1 pixel image as the source and added the real image source to the data-src attribute. We added an onscroll event that would swap out the image source after the user scrolled 200 pixels since the first below the fold image was about 250 pixels under the first fold. This 1 x 1 pixel hack was applied to each below the fold image. We used a similar trick for the YouTube video except that we used innerHtml to added the YT code.
Images above the fold were optimized by converting png to jpg. They were then lowered as low as possible until a noticeable difference could be seen. All images were then added to a CDN. We decided to go with the Google Cloud Platform CDN.
While going through the collection of 3d party scripts, we were able to dump Google Tag Manager, get rid of Font Awesome for inline SVG and drop our 3rd party chat script (we coded our page inline to handle prompting for online chat). All-in-all we were able to drop our requests from 84 down to just 7.
We cleaned it all up by removing commented out code. After that we minified the page, double checked that images and files had a client expiration set to 1 month, and insured that gzip was properly running. Our time was up at that point and we were ready to record our results. Here’s a video capture showing the difference between our original page and the post-hack optimized page.
The following day I decided that little extra adjustments could be made and the final page was ready for production at 88KB, 5 HTTP requests, a Speed Index of 1800, and a document load time of 3.484s.