What is common between Pinterest, Tinder, Uber, Trivago, and Airbnb?
All these companies experienced a surge in their product’s performance, user-engagement, and conversions by going mobile-first with progressive web apps.
Why did they go for PWA you ask? Legacy websites of these popular platforms were doing good for big screens but not so much for the small screens. Considering the ever increasing growth of mobile users and loss of potential market they decided to prompt users towards their native apps.
After seeing people bounce from their native apps too, they decided to go with progressive web apps.
This blog covers progressive techniques that Pinterest and other major companies use to build PWAs.
Pinterest reduced its Javascript bundle size via Route-Based Chunking
Code-splitting reduces time to interactive by loading only the code that’s needed beforehand while the rest of the code loads lazily.
Pinterest broke-up & shaved hundreds of KB off their JavaScript bundles weighing 650kb. Pinterest split it’s multi-megabyte JavaScript bundles into 3 different categories of webpack chunks (Vendor, Entry and Async). They used webpack’s CommonsChunkPlugin (replaced with SplitChunksPlugin in webpack v4) to break out their vendor bundles into their own cacheable chunk and added React Router for code-splitting.
As a result, Pinterest was able to take down the size of their core bundle from 650KB to 150KB.
Uber and Tinder also took a similar approach and….
- m.uber comes in at just 50kB and loads in less than 3s.
- Tinder took down its core bundle size from 166kb to 101kb and reduced its load time from 11s to 4s.
Faster loading for Tinder and Nikkei via Inline Critical Path CSS
The bigger and more css files you have, the longer the page takes to load. Inlining critical CSS eliminates Render-blocking scripts.
Tinder used Atomic CSS to create highly reusable CSS styles to inline all the critical CSS in the initial paint. Tinder used Google Analytics and CSS stats for each release to keep track of what has changed. It saw change in average load times went from ~6.75s to ~5.75s. Thus, removed critical CSS from their core bundles.
Nikkei, a Japan based media business, inlined all the critical CSS with 0 render blocking stylesheets. This optimization helped Nikkei to reduce its first meaningful paint by more than 1 second.
What else can you do besides code-splitting and inlining CSS?
Asset caching via Service Workers
Service worker is a lightweight net proxy which allows web applications to cache all of its necessary resources to load substantially faster for returning visitors. Essentially, it helps in caching main JavaScript, CSS, and static UI assets.
One way to generate a Service Worker file and a list of assets is via Workbox Webpack plugin. Many web applications take advantage of Workbox Webpack plugin for network resilience and offline asset caching. That further has helped these companies to speed up Time To Interactive on repeat visits and first meaningful paint.
Treebo saw 31% improvement in TTI and loaded in under 4 seconds, whereas Pinterest reduced its TTI from 23s to 5.6s.
You can refer to Google Offline Cookbook for other caching strategies.
The Future
Making speed one of the core metrics is an important step towards delivering a hassle-free and cutting edge experience to your customers. More and more websites are opting for an offline-first web. It’s only practical to adopt the ‘write once and use anywhere’ approach against writing natively for every other platform.
Google and Microsoft are also working towards a future where PWAs are available alongside full-fledged apps in app stores. It’s safe to say that PWA is in fact the future of the interwebs.
Progressive techniques can give your website a much needed performance boost like these apps that you just read about. Thinking about making the move to PWA? Talk to us here.