 built a PWA for Ola. So I am excited to share my experiences that I had while building those PWA at JS food today. So the first thing that comes to anybody's mind when you have to build a new website is which framework are we going to choose this time. So I think, yeah, is it good. So at Ola we were interested in, we were very much in concerned with the building a highly performant application for low end mobile devices which are running on a low 3G network. So we considered couple of frameworks. So first was Angular and then was react. So Angular was a framework where our entire team was very comfortable with but it had some problems in terms of rendering large lists. It had problems with the digest loops. So we thought about react. React was a very good framework you know with its one way data flow and its virtual DOM library. But then Angular 2 came out which had one way data flow and two way data binding between its components. So we went ahead and built a POC. So and then we measure the performance and we found out that it required a 30 kb polyfill around 198 kb of framework and associated libraries and about 50 kb of just a POC application. So and also the rendering performance was really poor on a mobile device. So next we wanted something lighter. So we went ahead with view and polymer. So view and polymer were very similar in terms of their development style and even their performance characteristics. But polymer was based out of web components and it had a slightly edge over view js. So that is why we chose polymer. So what is polymer? Polymer is a JavaScript library where you can create your own web components. That's it. It's just a wrapper around web components. So it basically gives you a syntactic sugar around web components. It provides you a data system. So basically it allows you to declare variables and bind it to the template. It also gives you an event system which allows you to communicate up the element custom element tree. So why did we choose polymer? Obviously it was because we needed a performance framework for the mobile but also because it was based on web components and it had shadowed on. Laser register was a feature that we utilized fully. So let me tell you what laser register is. I would define some element somewhere along my, anywhere in my application and I would import it much, much later but it wouldn't break the application. And the best thing is once the application was, once the custom element definition is downloaded it would then instantiate all those references that I did beforehand. So that was a feature that allowed me to utilize this over GA, Google Analytics tags. So basically I included them with my top level component OLA app and then I would import it long later because I didn't want to hurt my first pain time. So finally there it was. It was a collection of 88 reusable components and polymer being our library for web components. It didn't have any specific guidelines for building up PWA. So we at OLA we created our own guideline. So we went with props down and events up model and use redux to store data that is shared between the various components. Polymer also provided us a way wherein a child could reflect values back to its parent. But this was a pattern that we specifically didn't use. But we used two way data binding within the data within a single component. So that we didn't have to do any DOM manipulations manually. So polymer provides you things like a DOM if and etc. DOM if and DOM repeat. So let's see how polymer helped us in performance. The first thing was shadow DOM. Shadow DOM scope CSS and isolated DOM obviously provided us a lot of performance benefit. But I'm not going to talk much on that part that is very obvious. But I just want to highlight a small problem that we faced while using shadow DOM. So this is the only caveat that you should probably keep in your mind before using shadow DOM. So I was using recapture JS and found out that it is not compatible when it is included inside your shadow DOM. So what was happening was recapture JS was whenever I used to try to say that I'm not a robot it was not recognizing it. So I had to find a workaround and get it working. So the only thing is so the problem for me here was I couldn't rewrite the recapture JS on my own right. It is a third party service. If it was any other third party library I probably would have written it in house. So that maybe if you're using a third party library you should just keep in mind and probably build a POC before you try it out. Polymer CLI is a tooling that polymer comes with which helps you create either an element repository or a single page application. So I'll walk through some of the features and I'll tell about what are the enhancements we made on that. Polymer JSON is a input wherein is a input file wherein I can define my entry point my app shell and my routes. It also allows me to prepare my production build wherein I can define how do I want to compile it like you know minification aglification etc. Or you could use the best practices presets that polymer recommends. So you could generate something like ES6 unbundled wherein you would create a disk of ES6 and it is unbundled and also simultaneously create a ES5 distribution with bundled. All of this comes out of the box. You don't have to write any configurations for this. Now let's say you wrote a PWA. I mean you want to make a PWA right you just created a single page application out of polymer and now you could just say that you know add service worker as true and you you got yourself a PWA. Do you want to make your app purple then you just add the push manifest. So once I add service worker I would also have to give it SWA SWP pre-cache and runtime configurations for it. So at OLA we pre-cached all of our index.html and all of our ATAID web components and when it came to runtime caching there was only one API we could you know cache it because OLA being a highly transactional and real-time application which provides cab services. It was not possible for us to leverage runtime cache on any other APIs and of course we used it to you know like cache the images which is a no brainer. So this is the OLA offline experience that we have wherein you can book a cab via SMS. So this page kicks in any time you have a poor bandwidth connection. So this is the most you know innovative thing probably and polymer introduced distribution of unbundled code. So have you ever heard of you know without doing anything you are just shipping code. So that is what we did actually here you could you can see that I am all my web components are distributed individually over HTTP to doing this gave me a freedom that if I updated a particular component let us say which is of around let us say OLA app which is on 6.3 kb only that would be updated on the next service worker update. Otherwise rest of the components are untouched which probably does not happen when you bundle the code all together. Polymer also provides you a programmatic hook wherein you can do which it where it provides you a call back where you can hook certain functions after next render. So basically this allows that says that you know you are it gives your browser a breathing space so that all the painting is done and you can do some schedule some JavaScript tasks. So basically we use that to do the lazy loading. So over here you can see that we at first what we did was we just lazy loaded all of the components. So some components were loaded at the beginning and then everything was lazy loaded and I can show you that over here the content download for one of the component was one second and this was a relatively important component for the page and it was actually creating a block in our parsing. So what we did was we thought let's you know let's get crazy and try breaking this lazy load into couple of chunks. And once we did that we saw that from one second it in decreased to 100 milliseconds. So that is a 90 percent increase 90 percent improvement in my download time because of my staggered loading. So let me explain how we did our staggered loading. So Ola is basically a location centric company. So location is very important for us to serve you. So we show a model wherein we ask for a user's geolocation permission. So we use this and made sure that whatever was required to paint this would be rendered greedy. We don't make any deal as soon as the index.html is served we make request to download this. Next whatever comes after the click of this any user action that comes after this will be downloaded later. And in the next cycle I will make sure that whatever is required for the for the home page is downloaded. And finally those pages which are generating finally those pages which are generated as a click out of those first page are downloaded in the final cycle. So that is why it was we called it ahead of time staggered loading. Next we measured performance after all this. And we were doing pretty well in service worker supported browsers. And we were actually doing well in Safari as well. But its Safari's repeat load was not at all different from its very different from its first load. And we were wondering why and we dug deeper. And we found that we since we were not doing versioning on our polymer components it was resulting in around 80 plus network calls wherein it just says and ask am I changed and says no you are not. So this created a performance bottleneck for our Safari browser. So what we did was we added file revisioning and added set long expiry cache headers. With this this enabled us to do this enabled us to go a step further. So in our in our SWP service worker pre-cache this is how it would look like. And this is how the network pre-cache call would go. So it would basically append a cache bursting parameter at the end. So imagine now I have a file revisioning enabled and when I am doing a pre-cache service worker is making the request to the same resource which was downloaded couple of seconds ago. Don't you think that was that is a waste? So once with this enabled we could directly ship the code like this wherein I didn't have to depend on service worker to burst my cache and I was responsible for managing my own application cache. So this gave us a tremendous performance boost and not only in Safari but also in service worker supported browsers. So we had a couple of more things that we did. So basically our index dot html was generated out of an index dot pug which had configurations injected into it at run time. Now the problem as you can imagine is that the first time I serve and I pre-cache index dot html is cached and index dot html it it doesn't have its hash written in service worker because the service worker hash is generated by reading index dot pug. So index dot pug basically has something like square bracket and dot config dot something and whenever I change my configurations in my docker that will not service worker has no clue that it has changed. So I thought what are we going to do about this because we wanted config only redeployments. So what we did was instead of versioning our pre cache directly as you know v1 v2 etc we put we replaced it with epoch timestamp. So basically this enabled us you know to deploy as many every time we deployed service worker would know that there is a update and it would reinstall. So you might think now because every time you deploy if you are going to delete service worker and etc isn't it overhead no not really because we have file versioning enabled. So that would you know pick up from the disk cache itself. So that way we are not we are only making a extra network call to fetch the index dot html again. But rest of my custom elements are safe in the cache. But with this pattern we were all RPL we didn't have push and we thought let us let us introduce push to our application and we used we took the help of cloud flare in our infrastructure to make this happen. So we had measured our performance before the TTFB time to first byte was around TTFB was around 1.7 seconds. But after we added cloud flare we were server push it increased to 3 seconds. So that was around 1.3 seconds performance penalty after introducing push. So we stayed RPL. So if anyone of you guys in the audience have a success story around implementing purple pattern using your infrastructure please reach out to me after the talk I would be interested in listening you know to the success stories. So now let us have a demo on using Chrome extension. I was coding in AngularJS and I was very much used to using Batrang a Chrome extension which allowed me to inspect the scopes in my application. So whenever I used to do application programming which had a lot of conditionally rendering UI it helped me debug complex use cases. So Polymer didn't have a support for such feature. So I went ahead and actually built one so that I could debug my applications just as the way I did in Angular. So basically here you can see that there are various conditions that enable and disable certain features in the application. So this basically allows us so basically this shows the data associated with your Polymer element. So if you are you know building a Polymer application then I think this will definitely come to your help. So while measuring performance we use various tools. I just want to know how many of you guys in the audience have used Lighthouse. That's a good number and what about web page test are you using it actively. I think less people there are less number of people using web page test. So web page test is a website where there is developer tools integrated. There is even Lighthouse integrated and it gives you a lot more features over that. I think that is a tool which we all of us should use and while you are using it make sure that you test your you emulate a mobile browser like Moto G4 and also use a network connection called emerging markets 3G which is a which is a benchmark against which we measured our Ola app against. So there it was we had a application size of around 200 KB, a Lighthouse core of around 100 and our first load time on low 3G network on a Moto G4 phone was 3.4 seconds and a repeat loads were within 0.4 seconds. So this was the you know metrics that got us selected for Google IO. So this was all about you know how we built PWA at Ola. Now I want to compare and contrast you know like you know how why would you use basically polymer. So recently polymer 2 was released and it was it came out with support for ES6. So before I start with the advantages of polymer I will talk about the disadvantages. Polymer is a lightweight library polymer 2 is basically around 10 KB but if you are using it on unsupported browsers that would require a polyfill of around up to 28 KB and if you are concerned about IE support then there is only IE support above IE 11 and it also it also has some flaky support in UC browser and older versions of Android and web views. And if you consider and if you are concerned about SEO and also server side rendering polymer 2.0 does not have support yet polymer 3.0 is on its way and it has support it is in the recent polymer summit they have announced that they will be supporting server side rendering and other SEO benefits. So now let us come to the advantage. Polymer is a lightweight library of around 10 KB and because it is using web components it is the fastest library that you can get in terms of web components. And you saw that it had a very simple data system and event system and a little bit of syntactic sugar. It is very simple it takes just about a day to learn polymer but it is though it is so simple it is very powerful and I am sure that all of our use cases most of our use cases will be you know it is good enough to support most of our use cases. And by CSS pre-processors I do not know about you but I am just glad that I do not have to work on less or SAS anymore with shadow DOM enabled and configurable build. So basically polymer build is highly configured wherein you can create multiple distributions like you know you can create a various bundles wherein using presets you can even override the presets themselves. And these were the benefits if you are thinking it in terms of a single page application. But it does not matter even if you want to use it as a standalone web component library it integrates well with any framework. So if you want to know how many people are using polymer in production this is a slide which was presented in polymer summit recently. So EA basically they created a set of customizable UI elements and used it across all their various gaming content websites. Predix they built a library wherein were created components and they have successfully integrated with angular and react. And McDonald's the menu that you see is actually powered up by which is actually now powered up by polymer. And last but not the least Ola which built its PWA completely with polymer. So we got featured in around seven talks in Google I O and also got featured in polymer summit. And these are some of the encouraging tweets that we received that would be all. Thank you. Hello. Hello. Hello. Hello. Yeah. In the first slide you mentioned that the bund ES5 and ES6. You are talking about this slide is it? Yeah. See so basically a preset comes with the lot of options. So it basically allows you to minify and ugly fire. Yes it minifies your CSS it in line it minifies your HTML. It so basically polymer CLI also does a sort of dependency graph and creates a distribution file. So you could also create it analyzes all your packages. So especially when you say bundled right so it creates a dependency tree and creates automatic chunks of it. So it would do the chunking for you is that so you have used webpack. So basically it creates chunks out of your chunks for you right. So something that is common and then some chunks which are specific associated with the route. So basically bundled does the same thing for you. But the recommendation is using unbundled along with HTTP to because that gives you a huge performance boost as opposed to using HTTP one with bundled code. Can you hear me? Yeah. Can you hear me? Yeah. So my question is so you talked about polymer and a lot of features of PWA web components etc. So firstly before polymer came in Google was pushing a lot in terms of Angular as a framework. So polymer seems like a competing technology. What do you think are the key considerations for going taking polymer over Angular? Or other technologies? What is one key consideration that you think that is number one? Number two, a lot of what you mentioned PWA HTTP to in retrospect. Do you think you would reconsider the decision to use polymer and perhaps you know just go with the pure web components along with the PWA? So he has he asked me two questions. So what was the main consideration for using polymer? And second one was would I go use you know vanilla web components? So to answer that first, see so there is a talk by Alex Russell in Chrome Dev Summit last year. So basically what he says is we don't understand mobile net mobile works. So for a mobile web to be useful, it has to have a very less payload size. It has to you know load things in a certain pattern so that it doesn't overwhelm a low end mobile device using a flaky connection. So that is why we went with polymer because that only that had the performance characteristics that we were looking for. So we try so just to show you something you can take a look at this actually. So because any framework that is not web component, they have a lot of abstractions above them. So this abstraction translates into downloading that abstraction and then parsing that and browser also has to process that in run time which makes it much more difficult for a mobile browser because it has a very limited CPU as opposed to your desktop CPUs. And to answer your second question polymer is basically providing me like I mentioned in my slide. So it provides me with the syntactic sugar around web components and it provides me a decent data and event system. So I wouldn't think you know unless I am I don't find any compelling reason to use vanilla web components as such because this is really a lightweight library around 10 kb if you are using polymer too. So more questions. Hi, I used web component using polymer but that was back in 2015 when 0.5 version was there they were not even 1.2 and we actually took the risk of going ahead with the production application for that. For our POC it was working fine but as and when the application got complicated for Chrome Firefox it was working well but on I think we are using 11 at that point but it was taking 10 seconds to just come up with the initial screen. How is the performance now? Have you tested it on IE? Yeah, so that there is this point right. So we are concerned with building a performance mobile web experience for mobile. So that is why we could go with polymer. So we are not concerned with desktop performance as such because if it is performance on mobile at this level then its performance in desktop will unquestionably you know similar. So if you are making it work for a Moto G4 on a low 3G end connection. So the performance in non supported browsers on desktop would definitely be you know may be a little bit degraded but it would not be that bad.