Progressive Web AMPs: the Story so Far (AMP Conf 2018)

So, my, name is Eric, as we. Mentioned and I'm gonna be joined by some other folks here, to talk about progressive web amps. Exciting. Pattern that we're seeing more and more of and I'm, excited to tell you about so. Here. Is a modern website that, you see up here it. Is fast. Its, well-designed. Its. Interactive, and, engaging all, the things that a modern website should, be and. In fact it's very engaging, users. Spend 40 percent more time on this premium site than. Compared, to the sort of free equivalent, on the same domain and. It's. Also made. With amp and PWA. Which. Means that, users are spending 40, percent more time aand on. The. PWA. A name combination. Than the sort of standard HTML. Combination, it's, hard to ascribe exactly, what percentage you're getting from. The. Different, content. Or. Whether it's the implementation, or the type of content, on there but, this, sort of PWA. And amp combination. This type of engagement, boost, is it's exactly, what you'd expect from. Progressive. Web apps and amp, combined, this kind of boost so. So. You're going back a little we. Introduced a lot of folks to the idea of combining, PWA, and amp last year at amp comp and since. Then the idea has matured quite, a bit. There. Have been challenges, for. This combination these. Are some of the bugs we've worked through some of the ones we still have to work through. But. It's been worth it for a handful of developers, who have actually, implemented, these patterns, in the wild. So. Let's review a little bit for folks who aren't actually all that familiar with what these these. Things are hopefully, you have an idea of what amp is but. I can give you a little bit more background on what the combo is and what PWA. Is as well so. To. Summarize the basics, of what amp gets you. It's. Basically, a, turnkey. Format. For, fast loading pages, with. Some really great UI out of the box or UX out of box, that's. Kind of the core value of amp so. It's PWA well there are a few more moving parts to PWA progressive, web apps, if. You imagine two. Axes. For. The X that would define the experience on mobile devices. On. One hand you might have reach how, many surfaces can your content show up on and, on. The other hand you might have capabilities. What's, the experience, that the users get when, they land there well. The mobile web has always done really well with reach I can, work across platforms on, mobile desktop, tablet, it can be embedded and, easily shared and. Also found via distribution, platforms, but, they haven't historically had the capabilities.

Of, Native. Apps which are very strong than the capability, side but often. Are sort of locked, in and these, experiences. That don't have as far, reach you have to go you have to download these things, well. PWA. Sits. In. A position where it combines the best of both worlds the capabilities. Of native, apps with the reach of the mobile web. Where. Those capabilities, boil, down to a number of advanced, platform, features like Add to Home screen push. Notifications. Caching. Abilities that make it possible for. Repeat. Visits to load quickly. And. Then also better reliability and, offline. Experiences. Better reliability and, limited connectivity, situations. And the, ability to have a completely, offline, experience, and. Ultimately. It's, important to remember, when. Explaining, these two technologies that in. The end we're really just talking about web pages. That. There's. Not there's. Some special things that, come from it but in the end it's the the, web pages that you know and love just with some extra kind of special sauce on it and. That. These two technologies, are just complementary. Ways of. Achieving different goals they, each have their own strengths. And, some. Weaknesses, as well but. It. Should be no surprise from the title of this talk, when. They're combined you get to enjoy, the benefits of each and. They do combine well. And. In. The end you get a feature-rich experience, that starts fast and stays, fast kind of the best of both worlds. All. Right so it, hasn't always been in, as, great a stated as it is as it is today. This combination, of bringing amp together with PWA and there, are a few reasons for that. Historically. There have been kind of these three main issues first. The, ecosystem. We. Don't yet have an ecosystem of tools and, templates, and services, the kind of things that would help folks the. Web of course has been around for a minute but the, combo. Amp. And, PWA, are relatively, new to the web the combo, is very very new. And. So we don't have everything that you might need quite yet however, in the, same way that amps start which, you might have seen, in slides earlier today, provides, a good starting place for folks, getting started with amp with, tools and templates. We. Also, envision. Having, similar. Tools and templates for, amp and PWA and that's something that we're starting to work on as well. Second. Templates. Are well and good if you have complete, control of your own site the ability to just. Take. These templates, wholesale or implement, things directly and just sort of throw them up on your site, but. Not, everyone has the flexibility, to do this folks are anchored in specific, technologies, that they're built on CMS's. And that kind of thing so it's not the reality for a lot of folks, which. Is why we're also working, with CMS's. And other platforms, to bring a lot of these capabilities, directly to them so. If you saw, the. Presentation, earlier today, the. WordPress presentation, that's great if you haven't I encourage, you to go check out the video of that too, a bit more of what we're doing there but, again basically. Just want to make these technologies, available to, a lot more folks so. Another, key, piece of the, problems, that we've experienced. With amp, and PW a combination, is that. When you combine two technologies, you're. Bound to have to iron out some of the kinks of an integration. So. A number of things didn't work quite right in shadow Dom here. Are some closed bugs. That. We eventually kind of fixed a lot of these didn't work at first but it sort of went through them and. There's still more to do there there edge cases that you run into when you combine these things and it's important, that we're sort of upfront, that there are challenges but. Even. If most folks are in a pretty good state right now as, it is. So. Finally. One. Thing that was really lacking in the ecosystem, was guidance if. You've looked at our Docs and been a little bit confused, as all. Mentioned he was, you're. Not alone it's. Great to have options to choose from but one piece of feedback we've gotten repeatedly, is. Not. What can we do what are a bunch of options that we could potentially do to combine amp and PWA but. What should, we do what do you recommend have. Been more familiar, with these technologies.

So. We've done a little bit of thinking about what a well-lit, path for amp and PWA would look like and I'm gonna proceed, through a little, bit of high-level. General, guidance that. We think offers the highest ROI. Per. Step as you go through some of the options for for, how to combine these technologies. And. Before, I get into the detailed, recommendation, I do want to add one thing if. You have amp. Pages if you're publishing amp pages and if, you also have a PWA, it doesn't matter what it what it's built on I it. Could be. You. Know an amp based PWA, it could be completely independent one. Thing that you should be doing if you're using a service worker in your PWA is, using an amp install, service worker on your, amp page. To, install to warm up the service worker in the background, so when folks land on your PW a from. Your n page they're, getting this experience. That's already warmed up. So. Yeah, basically do that thank us later it's, pretty trivial to, do. So. Yeah highly recommended, another. Kind. Of side note before I jump into the main recommendation. Is that you know your business what. I'm going to present is a sort of general recommendation. For folks that. We think will work in most, situations. But. There may be different, pieces different functionalities. Different ways of doing things that as the. Person, who knows the most about your business, you. Might, identify and, say like I think we would do this a little bit out of order I think you, know push notifications. Aren't super valuable for us but like an offline experience, is because, most of our users are, accessing. Content offline, and. You. Should remember that as we sort of walk through this but. Without. Further ado, the. High level recommendation, is to, build your site with amp. And. Yeah. That's sort of big step one and then. Step two is to progressively. Enhance with PWA and. This. Is a sort, of sequence, do, one, and then do two and. Step. One breaks down into a couple things when you're building your site with amp the, biggest benefit, that you're gonna get from amp is on. Your. Sort of entry, points. Entry. Points being where you get the biggest speed benefit, where distribution. Platforms, can do clever things to get additional speed benefit, and. These pages are, essentially, articles. Product, pages learn, more these sort of entry. Points that people land on from. Search. Social, sharing those types of distribution, platforms. And. So once you've done that basically. Build the rest of your site with a framework of your choice this. Could be an existing framework, out there it, could even be with amp if, your, site, is supported, with the features, that, you. Really need in an that's fantastic, and we obviously think that speed benefit you get from that is really. Really worth doing, but. It could also be vanilla, Jas, there, are a whole lot of options for how to how to do the rest of your site like these, more. Advanced, checkout. Pages that, type of thing. So. Then once you build your site with am progressively, enhancing, with PWA is is the, sort of next step and this. Breaks down into a few different things again this is a kind, of general, sequence. And. Again you, may want to do some out of order based on what your needs are what your business's, needs are but. Here. We go. So. Step, one would be basic, caching to load up to. Speed up the load time for pages and it, could include for instance caching, third-party, resources and, that type of thing with the serviceworker and, i. Brought up the serviceworker a couple, times with no context. I don't want to get too, deep into this because folks we've presented, about this before and I don't want to reiterate, for folks too much there's.

Some Documentation online but basically it's. A client-side, proxy, that, can intercept, calls from the client and served for instance cash, content, instead of going. All the way to a web server, and. And, doing that run trip and, it. Also incidentally. Is what. Supports, push. Notifications, which. Is essentially. The next step in the sequence. For. Most votes. Though. It's worth pausing on, a key, aspect of, push. Notifications. That. This. Is often, not, done like, really tactfully, in the wild for. Instance if I were meeting you and, shaking, your hand for the first time and I said like by, the way can you help me move this weekend. That'd, be like you. You might want to know me better before. Like making, such a commitment, similarly. A lot of people's first time on a site they. Get a sort of notification that's like hey do you want push notifications, do you want us to like tell you anytime there's something new and it's like oh I don't really know you yet like maybe I'll check out the website more and then then make a decision. Better. Ways, to do this include, asking. When users have more context, for what. Push notifications, might mean for a given site, and. Maybe even after they've they've, indicated a specific, user. Intent, or. Even checked a box while going through a checkout flow or something like that but. Yeah, Wednes respectfully. Done this can be like a really valuable thing for publishers. And users and merchants. So. For. Some, developers, you're. Actually done at this point the, rest of the features in, this sort of box. Here are really to optimize, for users, who are returning to the site again and again kind of frequently let's. Say daily users, due. To the amount, of effort that it takes to do. The following things as well, so. But. If you do want to take that steps if your users are engaging on a more daily basis you. Can add an app shell which manages, navigation. And and page transitions. Implemented. Via serviceworker, or cookies and you. Can use what. We call an aunt in PWA, pattern where, an is the, content, and sort of a PWA shell where, potentially, just a standalone PWA. The. Next step that we'd, recommend is, adding. Offline, support either full. Or selective, offline, functionality and, access to content, and then. And, only. Then after, doing these things, adding. The, app, manifest, to trigger that add to homescreen prompt. So. Here's, the manifest just. A brief aside, to sort of talk about this. The. Manifest, among other things describes, how your page should look when, installed from a devices home screen and. When you have the serviceworker and the manifest, that makes your. Page eligible. To. Get this nice add to home screen button and really have that more of that app like. Functionality. That folks can tap on and open the app the. Thing is when, folks, can just tap on this thing in any situation, they, they. Might be offline they might have limited connectivity, and it'd be nice if weren't just greeted by a blank screen or something, like that and so, that's, why this sort, of manifest. Step comes at the end of these things that, you'd really want your users to have a good experience when they open this even. If they're in context where you wouldn't really they, wouldn't really expect that they need web connectivity, potentially. So. That's it. These. Sort of stats, are, our, current, idea general. Recommendation. For how to get the best out of combining, amp and PWA a little, more on the rails general, guidance the I really, hope is helpful to folks. But. You may ask how do we actually know that, this works this is good that even the, combination, of amp and PWA itself, is. Worthwhile, and worth doing well I'm excited, to invite some folks who are creating amp and PWA combinations, in the wild, so, please welcome Madison, miner from womp Mobile. Thank. You for the introduction, Eric my, name is Madison I'm with womp mobile. First. A little bit about our company's. History we. Started in 2010 with, the goal of helping other businesses optimize. Their websites for mobile and we've been through a few different iterations, at first, we were building MDOT, sites. Which. Had some, problems, being, served from a different domain later. We switched to making, JavaScript adaptive, sites which was a big step forward in 2015. We. Dovan. Headfirst into amp when we first heard about am a google led initiative, to speed, up the mobile web and solve mobile, performance we, got really excited mobile. Speed, and performance has always been one of our core goals and an. Opportunity, to guarantee. It and validate, it with a Google, product. Was, a right, up our alley so. We'd OVA in headfirst, in the amp and, it's been a success, today, our platform, serves five million ecommerce, amps, every day for, some of the largest companies, in the world our our, amps, thanks, to, aunt Biden, amp lists and other amp components, have feature parity with, their canonical, counterparts, they're, fully featured amps.

That Look and feel just like the canonical site the, only difference is they're faster, which everyone. Loves our clients, love their customers, love and they see the benefits. We've. Started. Experimenting, with some of the technologies. Under the PWA, umbrella, including. Service workers and manifest, and push notifications payment. Requests but, we hadn't really discovered. How to work, the app shell into, our platform. Until. I saw Paul's, presentation, last year at i/o where, he. Showed. Off the new PWA, plus, amp pattern, or plant progressive. Web amps, and. When we saw this we got really excited we, actually started engineering later, this day after the talk. Building. PWA, and app shell and using this pattern in our platform. As. Eric. Kind of showed this is this is how it works the PWA, app shell is comprised. Of the header and menu. User. Interface elements, the app shell can also have complex. JavaScript, that you might need that's not amp compatible, maybe, you have some complex analytics. Or website monitoring, or chat or payment requests that, can be loaded in the app shell and only loaded once per. User visit. And. As Malte said earlier amps. Are portable content, units they can be cached they can be served via the, serviceworker, they're, lightweight. There. Are standalone units that we can load into the app shell as usually navigates the site keeping. A persistent, header and menu and, having nice smooth, transitions. To, make it feel very app, like. The. User journey plays out a bit like this they, do a search. For. Something. That you'll show up for the. Amp are the listing in the search results page has the amp lightning bolt badge before, the user even clicks on the, result, Google. Is pre, loading the, amp page in the background, which is the benefit you can only get amp pages when. The user taps on the amp listing, it loads instantly while. The users viewing the amp page we're, using the install service worker component, to install, the PWA, the app shell and the associated, components in the background so, when they click on the. Next link in the user journey the, PWA, loads. Instantly and shows, the next amp page that's associated with the, clip the. User can continue to navigate the, site and, we. Load in amp pages, as they do, when. We go to checkout we can have the rich functionality have a payment request after. They've done their. Finished checking out we, can prompt them to add the, app to the home screen. This. Video is. Showing. Showing. How that plays out in real time is, for our client. Carp that I'll be showcasing. Throughout this presentation, they make these really cool wooden. Phone cases. Wooden. Folk case is their top, search term. When. You do a search. You'll. See the amp listing. It'll. Load instantly. Lightning. Bolt badge we've measured, increases. Click-through rate about 25 to 30 percent. During. The amp page now the PWA. Is being loaded in the background now they're in the PWA loaded. Instantly. The. Header menu is persistent, as they navigate the site another. Amp page loads in. Allow. Them to check out with just a few clicks. And then, they're prompted to add the app to the home screen that. Whole video is 20 seconds long starts with search goes through checkout that's real time that's how long it takes. However. It always been hasn't, always been easy during, this process we've, encountered a, few challenges. And learned, a few things I'm going to share some of those with you today. First. Is how do we display non amp pages in the app shell. How. Can we prefetch amp pages and how can we reduce duplicate. Wean, our mobile website or app shell and our amp pages. So. First is loading non amp pages this example here you can see it's, it's. A complex app I've uploaded, or, selected, a, map. Of Amsterdam, you can resize the map you can position it you, can choose the type of wood you'd like it laser engraved, into it's, a complex, JavaScript, rich, custom, made app that uses canvas to, allow the user to customize their, phone case probably.

Not The best application. For amp might be possible, you can do some pretty cool things in amp. But. It's. Pretty complex and, uses canvas most of our clients, have a few, pages like this that use, allow. For rich, customization. Or. Have. Interactive, charts or have other components, that are going to be difficult, to convert. To amp we, wanted these pages to load into the app shell smoothly. Feel, like as part of the experience we didn't want it to be separate so our challenge was how do we load non-m pages, in the app she'll. Discover. Three options using, the shadow Dom, good. Old trusty iframe, and HTML. Imports. Shadow. Dom was the obvious first choice that's, how amp pages are loaded into the app shell and this, works this, is actually we have this working in production but there's a few things to be aware of the. First is the window, dot onload event, only. Fires once when you load the app shell it does not fire again, when you load child pages into, your shadow Dom so if you have scripts in your child page there. Depending on the onload function to, fire to, execute. Some code you, have to find another way to fire. That code. Mex. Is document, outright if any of the scripts that you're, in. Your child document. Use. Document, dot write that's gonna overwrite your app shell which is obviously very bad we, worked around this by overriding, the, document, dot write function, which is the fairly, common hack that a fair, amount of libraries, do it works pretty well. Next. Is any, references, to. Document. Dot body or head in your child document, are going to reference the head and body of your, app shell which. Is not the. End of the world the most common. Artifact. Of this is that scripts, add other, scripts, to the document, and so your app shell ends. Up with extra, scripts in it that are meant, to execute. Against the child document, these, scripts can do what they need to do they can still find what they need to find it works ok. What. We've done to work around this is we've marked everything we want to keep in our app shell with a specific class then. When we navigate, away from a non amp page we delete everything in the app shell that doesn't have our class to keep our app shell for being littered with scripts.

And Other components that might have been added by the child, document, so, again there's a few things to keep in mind but, this does work we have this working. Live in production. Next. Is the iframe, iframe. Is a handy. Tool that should be in every amp developers, toolbox. This. Also works we have this working, in production a couple. Things to keep in mind the. Document, that you're loading into, your app. Show, might already have a header and a menu present, you don't want to display this twice since, it's part of your app shell. It. Can be difficult to hide this with CSS, and typically. When you load a document, into, an iframe you just set the source attribute and then the document streams in so, you don't really have an opportunity to remove the duplicate. Header what, we've done to, solve this problem we simply mask the iframe we wait for the document to finish streaming in we. Remove the header in the menu and then we show the iframe we lose a few milliseconds, on our first paint with this but these are non amp pages, that aren't. The fastest pages anyway we only do this for complex, heavy. Pages, so. In actuality. The, difference, in page load time is trivial. You. Can solve that by removing the head and met our. Header. And menu and. Then loading it in line using, the source dock attribute. The, challenge, with that is that any scripts that run inside, the. Child. Document, inside the iframe will, see its origin is about blank, which, can be very problematic for. Analytics. And other. Scripts. That make use of the origin. Another. Challenge with this that we have yet to overcome is if there's a script, that sets, the document, location, to. Another. Origin it will load inside, the iframe for example if there's a script that's loaded inside of, your iframe, that, directs. To. Google.com. Buggle. Will load inside of your iframe in your app shell which is obviously undesirable. If. It's. A click that, instigates, the. Navigation. You can intercept, that or if it's a. JavaScript. Navigation, to the same origin you can intercept, that but if it is a, redirect. To another. Origin, we have not yet found a way to. Make. Sure that page loads fullscreen, not in the iframe so that's something we're still working on.

The. Third is HTML, imports, it's a less known, element. It, is designed, to load one document, into another document so at first this seemed perfect however, it does have some, of the same challenges as. The. Shadow root namely. Windowed on load, doesn't fire and head. And body will reference the parent document also. It doesn't work in iOS so this was sort of a deal, breaker on that one out of the three, potential. Solutions this is the only one we're not using in production. So. What are some of the challenges what, are some of the fun things you can do. We. Found a way to make. Our, app. Shell. See. The future and download. The amp page that, you're likely to click on before, you click on it. What. We're doing here I'll show in a second is when, we scroll a link into the viewport we. Are adding, prefetch. Link tag to. The app shell which, will tell the browser to, download the amp. Page before the user clicks on it the cool thing about using a prefetch link, tag is the browser will look at how much resources. Are available, is there enough battery, is there enough network is it a good time to prefetch. An asset if it is the browser will download it if not it won't. Though. The reason we thought this was kind of cool is normally when we've used prefetch, tags we put them at the top of the document and, we, prefetch whatever we want to do we, weren't sure if adding them at. Runtime due, to a user, action would, have the desired effect turns, out it works great so we thought that was pretty cool and we're sharing. So. Hit play will. Scroll some links into the viewport in the bottom right we can see console. That pre fetch links, are being added to. The. Document. And then. The upper right will, see the. Amp pages are being downloaded. An. Additional benefit of this technique is that if you're using a serviceworker and then you lose. Internet, access the. User can continue to click on any links that they'd scroll past and they'll still load. Even. Without internet access and they haven't viewed the page before. The. Code to make this happen is pretty simple we're, using an intersection, observer to monitor all the links, on the page as, soon as the link is more than 50% into, the viewport, we'll, check to see if we have an amp version of this page we do not pre, fetch non amp pages because they are not as friendly. Portable, content units. And, then we add the prefetch, link tag. So. Now we have a. Progressive. Web amp that. Can. Load non amp documents, into the app shell when I'm required and I. Can see the future and prefetch amp pages how do we make it easy to update. Challenge. We ran into is that. With. Amp pages you, can use amp, components. For. Rich functionality, like showing the menu and showing accordions, with. The PWA app shell you can't use M components, you, have to use JavaScript we, tried to use the, amp runtime, and the amp shadow runtime, which is used to load and documents, into the shadow Dom both in the same document, those. Two libraries collided. And we had a bunch of trouble with that so. We can't use have components in the app, shell. And we can't use javascript and amp. Pages, so. It's, a bit of a problem because we need to make changes we have to update it two places which is cumbersome. Which. Might be what's required if you have rich. One. One case we've ran into is if you have a search bar that does autocomplete. Or something like that it can be pretty tough to do that without JavaScript, but. If you can get away from that what, we've done is start building, our App. Shells. Header. Menu with no JavaScript. At all we're, using the check box hack which you guys might be familiar with the, idea is that you have a label that's associated with the check box you click the label stay, at the check box Changes and then you have some CSS that. Will hide or show some, components, on the page based. On the state of the check box so, it works really well to hide, or show a menu or for accordions, and if you can. Reduce. The functionality, for a header and menu enough, to, where that's all that's required you, can get away from having, two separate versions so, you can have one version of your header menu that's used boasted in your amp pages when, they're shown in Google search and also, in your PWA that.

Loads Your amp pages. That's. Header and menu a nice thing about this. Technique is. We. Also no longer have to maintain the, mobile website there, might be a couple pages on the mobile website we need to maintain if they're not amp compatible, but, this is an easy way to, move. To canonical. Amp, this. Allows you to check to see if there's an amp version available and, load, it. Which. Reduces. The. Maintenance on your standard website since it's now just amp previously, before we start a building progressive web apps we'd have the standard mobile website and then the amps that we're showing in Google search we, had a design change we need to make it two places now, that we're using the amp pages everywhere it's reduced our maintenance. So. The last couple years we've. Had the same recurring. Question, come from our clients, or complaint. Come from our clients and that is they, see the majority of their traffic's on mobile Mobile, is the biggest growth opportunity, but the majority of their sales are coming from desktop, and, there's, a conversion. Rate Delta. Between, the two platforms and. It's. Been our goal to close that Delta and. For, the first time ever with progressive Web Apps we're seeing conversion rates that finally rival the desktop, and. It's no surprise it's, a it's a great solution has everything you'd want has all the benefits of a native app has, all been with the discoverability, and all the benefits of a mobile website the. Payments, are easy you can now tap the home screen it can open full screen it, can run offline it's. Super, fast, awesome, transitions, it really has everything you could want in a mobile experience. When. We launched this. Progressive. Web amp for our client car which I encourage you guys to check out carve calm it's probably the fastest. Ecommerce. Mobile, website you've ever seen. We. Did a two-month, AP, test where we directed, half of the mobile. Traffic to, the new progressive web app and the, other half the mobile traffic to they're really. Nice already, responsive. Magento. Mobile site and. The. Results were pretty impressive, we saw improvements. Across the board. An engagement. Pages. Per. Visit time. Per visit and the, most important metric conversion. Rate went up 75%, which, is bringing it close. To where the desktop conversion rate is. So. It's, been a fun. Ride. Thank. You guys very much, no, I'll head over to JVM. Yeah. Thank. You Paula Malta for having us here cm conference, in Amsterdam. So. We. Are from young format. We. Are.

We. Are the second largest independent. Agency, in Germany and we, are proud to be over 25 years old, but even prouder of all. The projects, with it already, so, check out our short, for real. Yes. That's me I'm Thomas, I'm one, of the managing director, at young vomit in Hamburg and I like single. Speed bikes and, road bikes and also, the album web. But. Today. I want, to talk about how, we have built a new BMW, com. So. What. A nice challenge, that, was my thought after, the client quarters, so, here at the m conference, we, want to show how we have built the new BMW comm. The. Job was to relaunch the BMW, comm website, completely. From the bottom as a new new digital, home for the brand, so. There's. A long project, history but, finally, we made some bold decisions, focusing. On a new platform with. Three goals make. It content driven, high-performance. And highly, innovative. So. Our first goal was. Conceptional. So we wanted to create a website that is user and content, focused. Content. That, pulls you in from, search social. And the open web saw. The right content, for every, for, every user. So. Both. Jesus guides, the user deep, into the, into. The website and content and spoiler. We invented the first M story module without the. Story. Component. So. But. The number one goal was really to make the website really, really fast and I'm, really proud of this goal because, after, 20. Years of fighting for it on every project it, was the first time that it was the number one goal. So. Following. BMW. Latest claim sheer, driving pleasure we would like to say speed. Matters more for sheer surfing. Pleasure, so. Nothing. Is more annoying that, a slow, and web ads. And a slow web, mobile experience. And. Speed. Also matters in the, sales funnel so, you. Definitely want, raise awareness with, a slow website. The. Next, main. Issue was innovation so but, innovation that, not does not always mean to do big things. For. Us the goal was to, bring the app user, experience. To, the mobile web so everything. Was the Sun and the. Next article only his wive away. So. As we. Started, to, think about the project we thought we, need three code bases, because. The, mobile and the responsive. Behavior was, so. Different and, we. Definitely want em for the first search access. So. We did some deep dives into, frameworks, check, out other for sites like The Guardian and. The. Deep dives into the M component, world and found a great set of components, but, with strict rules. Regarding. Third party our script, and the 50k, CSS, limit, so. At this stage of the project we, did not think about using, em as our, own search framework. And. In. That time period, I saw, miter talking. About a mix of amp and progressive. Web app in Hamburg and we. Figured out to met Paul, in, Berlin, and he is talking about pushing. These boundaries, easily, or the P, is already missing. But. Its. Meaning its amp and PD Abu a so we've, talked to Paul, about this combination and. How. We built the, canonical amp set the. Connection, with the progressive web app is what, pair will show you next. Hi. Everyone oh it's. My Khan yeah, okay, perfect, I'm Pia, senior developer on the team that built. The all-new BMW comm, content, marketing platform, and I'm, really, into electric, mobility as you can see here.

So. Our. First goal was, to create. A fast entry, point so we decided to use amp as our canonical. URL. Every. First-time. Visitor. Regardless, if a if he is a search visitor or, has. Had, a link, share to him will, always see, the impression, and we. Use, apps installed, serviceworker, the, amp install serviceworker element, to. Bootstrap. Our pwho. As the. User is initially, visiting, our site. After. That we can deliver, with, the next click or a reload, or for, returning visitor our tailor-made experience. For desktop and mobile where, we provide. A custom scroll or. Swipe. Navigation, and dynamic. Loading, behavior. So. This. Is what you, see when you load, our pwho. It's a reduced, set, of markup that use very similar, techniques, to, what one mobile did to, provide. A. JavaScript. Free entry. Into, for. Our header. We. Also deliver, our JavaScript, to bootstrap. The application loader. Which. Means that the amp shell you're seeing is not actually valid amp, whereas. Our. Stage, here the, bolt media. Component. That's supposed to draw the user into the article actually. Is developed. And document, it's a partial, from, our canonical M document. Which. Uses, the amp shadow dock API in combination. With the article. With. The article body to. Form. Our. Ballot. Amp document, which is delivered to the first-time visitor. What. We are trying to do is we only want to load the part of the page that I actually needed, to. Save bandwidth, and resources for the user. As. He continues. Through the content and the. Next stage becomes visible, we're using the, amp. Shadow, dock API set. Visibility state visible, to, trigger. Content, initiate initialization. For our, next stage so. That we can draw the user seamlessly, into more. Articles, and remove. The friction, during. Transitions, from content to content and improve. Our content, discovery. So. You might ask is that F everything, our PW. HL is good for and, spoiler. Alert yes. It is so let me show you why, we took, this approach. You. Might remember the sales funnel that Thomas, already showed you and. In. In the beginning we thought amp was only good for, the, the entry, for the content discovery. Research. And social, media but. As. It, turned out we. Were we, thought. We. Had to fire up our pwho. To provide, all the engaging. Features. Like social sharing parallax, scrolling, sliders. All the enjoyable, stuff but, as it turned out. Perfect. We. Were able to push, the limits of amp. In the, amp shadowdog. API and include. More and more features and, at. The same time we, pushed, the empty. In by providing. A lot of back reports so that they they could make. Everything work, so. For, us during, the process of development. The amp frame framework, really evolved. We. Were able to integrate, almost. All the, features we initially, thought, had, to be. Developed into the PWA shell into, our, core, amp. Document. Which is loaded, which is loaded, as split, up stage, and. Your body so. This means we could use one single, codebase we don't have to develop the two different. Versions, that, we actually did for, the pitch we, were able to develop one article, save, a lot of. Resources. Because we don't have that, much duplicate. Code to maintain and, we. Don't have to. To. Implement. The basic amp features. Like the loading behavior. We. Were able to just add the custom. Code we need it for, our. Loading. And sprawling behavior, and slide. Content, discovery, with, the PWA, so. The. Speed of, the amp project. Moving forward was. Really, one, of the benefits of the. Project but. The. Of course a lot more actually. The, amp components, basically gave. Us the rocket fuel we needed to concentrate on. User experience instead. Of rebuilding all, the coal loading mechanics, for multiple, versions, of the site. Another. Benefit, was that we, were able to combine. Multiple, pre-existing. Amp components. Like an image and video and animation and, amp. Position, observer to, create, our bold, immersive, stage. Which. Then was the help of our pwho. Became. Our, custom-built. Amp. Story. Module, so. Now. We were able to enable, swiping, through the content for mobile users and. Yeah. Push them further. So. Another, benefit you get of course with, em and that's awesome or often, the main. Decision. For for. People to actually, apply. Em to their project is the. Of, course the, benefit. In the search results, where you. Get the, shiny. Amp. Icon, which, really sets you apart from, from, other search results, but we sort, also. Saw other. Improvements. With. Search, results where em forced. Us to create. A very. Strict, content, module. For. The article without any bloat of different. Articles that would, bleed into, our index. Content, since. We're using em as our canonical pages. But. With every project you're. Doing there, or with every framework you're using there also, pitfalls. And one. Of the pitfalls. We. Encountered were the limitations, you, all know that you can't use any custom. JavaScript in em and you. Know that if you, want to develop a rich, responsive. Website working.

In The limitations, of a, 50 kilobyte, CSS. Boundary, can, be challenging, but, for me personally as, a developer, it. Rather felt like a. Tool. To, argue with designers, that it's, not just important, to improve, the look. And feel of the, site but build, a beautiful page, and at the same time remain, fast. The. Second pitfall is that you really have to check your limitations, so. Amp. As if, we use temp as a framework and with every framework you, apply you have to use the right tool, for the right job so, if your goal, is to build a. Single. Page application, then. It might, not be the right choice for you but. For. Us with, our content segment, and for content, marketing platform, it definitely was the right choice. The. Last part is. That. You. That, you're working on a living, project amp. During. Our time when we used amp it evolved, quite a bit we, ran, into issues and since. The. Verse the components, are updated. And you. Have a single version for. That you're embedding into your site the, code, can change and that, can render your, amp page invalid. At times but, as long, as you check, the release notes and maybe, include. Validation. Check in to you into, your tool chain then, you can prove and your, page, from becoming, invalid, and at the same time you still profit, from from, all the advancements, the empty actually does to the components, so your, page is, getting better and better and faster, without. You. Doing, any changes to it. So. To. Wrap, everything up I'll, hand. Back to Thomas. Yes. Thank you yeah. Yeah. So. We are almost almost finished, but to bring the project on point we have a small case with you for you to have. Everything, in it. How. Do you excite people for, a car brand but. Not interested, in cars at all by. Listening to their needs and telling. Them stories they, actually, want to hear data. Driven, entertaining. And, helpful, for. This purpose, we've, developed a central, stage a new, home, for the BMW brand the, all-new, BMW comm. For. A web experience, just as dynamic, as our cars we. Used Google's high-speed, amp framework, and. Dramatically, increased, performance and, thanks. To another web technology, called PWA, ultra. Smooth full screen videos enrich the experience and. The next great story is, only a swipe away. The. Result a. 30%. Higher click-through rate from google search and up, to three times faster website, loading compared, to competitors and, a. High, performance, experience that, you would only expect, from, a native app and, of. Course the, configurator, or a local test-drive, are, always just one click away the. All-new, BMW comm. The. World's fastest, automotive, content marketing, website. Yeah. So. Today, I want to thank our client, BMW, so specially, Christian, who. Was the best agile, product owner ever and Urich who made the, project possible and for sure so, much, laughs for all the passion from the best team at JVM, so these. People are happy to invite you to have a look to. The new new BMW, comm. Thank. You very much.

2018-02-19 11:32

Other news