Myntra’s Web UI Journey — AMP and PWA
Myntra has always been on cutting edge technologies especially when it comes to frontend tech. We were one of the very few early adopters of react.
Myntra’s Old Stack
However, our site was a multi-page app and in order to scale servers and development, the entire app was split into multiple micro apps which could run independently.
We were already using great frameworks like react, redux, redux-saga, css-modules. However these led to the problem of our js bundle being around 350kb gzipped, all of it was a single bundle. With this, our initial load time on a 3G network was extremely bad.
After moving to PWA, we were able to improve site performance by 2X in fast 3G connections and upto 4X faster in slow 3G. ( as per webpagetest.org)
Myntra’s Journey towards future WEB.
We started working on complete revamp of the site. After going through the https://developers.google.com/web/ We realised there are two key factors we need to focus on.
- Experience of First Time Visitors using AMP
- Experience of Repeated Visitors using PWA
While we wanted to build everything faster and deliver early, we had limited resources and lot to deliver.
So we took phase by phase approach where we release features faster in smaller pieces iteratively.
First Phase — Build AMP
We started working on the first time visitor experience with Google AMP. We took a challenge of building these pages as early as possible and hence, without wasting time we jump started. In this process we also made our AMP pages interactive with amp-bind.
Tech Stack
We wanted to keep the stack as simple as possible, yet optimal. Since AMP pages are similar to html with their own custom tags, we opted dotjs, the fastest templating engine. Using react would have made the stack complicated with no real benefit as it is not really meant for server side rendering anyway. All we needed was a good templating engine.
Our AMP pages were in production within a week. We couldn’t measure the impact precisely due to various issues such as multiple session per user (two different domains in single interaction), but we knew we were heading in the right direction. This gave us immense confidence, which helped to move on to next phase.
One of the great benefit of using amp is, google preloads the amp pages and javascript files using iframes in the background even before user clicks, enabling instant page render.
In next few weeks we built rest of the pages as well in AMP.
Second Phase — Speeding up existing website
While we started going through PWA and service workers, we found another quick win opportunity — Integrating service workers on existing site using sw-toolbox
Since our existing site was not fully on https, we first moved it to https and then, immediately pushed service worker caching layer to production. We used sw-toolbox. Implementation was quite simple but gave us great benefits of caching.
We also integrated amp-service-worker to improve the user experience even further with minimum page load time. In simple words amp-service-worker is an iframe loader for the site due to which all the site assets will be preloaded.
These changes resulted in some immediate gains business team was happy, we got further opportunity to start on PWA site from scratch. This helped us to take right technology decisions and put a right base for the future.
Third Phase — PWA Stack
So now we had tweaked existing site to it limits, which gave u some breathing time to focus and start from scratch. We knew what we really needed and dos and dont’s by our existing site experience.
One of the biggest issue of existing stack was its javascript size we couldn’t reduce it any further as huge load of libraries like react, redux, redux-saga ( (yes we started using it long time ago) in were baked into the system.
This was the biggest phase, and its going to a lengthy blogs. So i wrote another story on our PWA architecture. You can read it below.
Thanks for reading!
