You don't need AMP for that

0 0

[Music] [Applause] [Music] good afternoon everyone my name is Senne che and the software engineer on the amp project and today I'm going to share with you our secrets for making web pages stuff and hopefully you learn some of the best practices and apply them in your own development process but first let me show you what problem we're trying to solve this is a typical mobile page and I as a user want to see this page I have just clicked on a link to open this page and read the content but I can't because there are things that are preventing me from doing so the first is that it's extremely slow to load in fact does anyone here in the audience know how long it takes the average mobile page to load 15 seconds 15 seconds you know that after 3 seconds half your users are gone after 10 seconds nobody's there 15 seconds is horrible the average is 19 seconds so after I finally loaded my page I have this flash of unstyled content which is very jarring and could possibly give you a Pepsi and after I takes forever to load I have a flash of unstyled content I start reading the page in 20 seconds later when it's just that the best part and I want to see what happens this ad loads out of nowhere and fix my content around and I lose my place and I don't know where I am anymore and I really want to know what happens next so then I try to look for where I was but now my browser is kind of frozen or it's janky and I can't find where I left off this is a horrible horrible experience we have all been here before but why should you as developers care about this you have a million things you could be doing with your time why is it important to fix these issues well my answer is that it's important if you want to keep your users and your revenue today I'm going to take you under the hood and show you what's going on that's causing all these issues I'm going to show you the 10 sets that we take with amp to address these issues to make the web experience much better and hopefully you'll be able to apply what we do in your own development process to make your pages better in faster so first let's look at the first problem which is that it's very slow to load and what's happening here is that there are things that are blocking the render and these things happen to be files that you have to download before you could see anything on your page they could be the assess files they could be JavaScript files and they have to download and it takes a really long time and to solve this we decided that we need all scripts to be asynchronous so that you can see the HTML on your page you can have the page load and the script will load in the background and they don't have to block the render of your page the next thing is that we only want to download JavaScript that you need on your page so here for example is a carousel not every page will have a carousel so not every page should download the JavaScript of a carousel so we break the page up into components and we tell the browser specifically what JavaScript we want to download so that you only download what you need for your page the next thing is that we inline CSS so external stylesheets tend to be very large and they take a very long time to load so in lining it means that you don't have to download them separately and it's going to be a lot faster this is like taking a carry-on luggage with you when you fly it's going to be a lot faster than if you check in your baggage and end up being one of these people waiting at the carousel nobody wants to be here because it takes forever so check in your don't check in your luggage carry it on with you inline your CSS now when you fly and you take a carry-on suitcase with you you have to limit how many things you bring right because you don't have room for your entire house in your carry-on luggage and we decided that we're going to limit CSS by 60 kilobytes and 50 kilobytes is just like the space in your carry-on luggage it's just enough for all the things that you need but you're not going to bring a bunch of junk that you don't need the next thing so also the 50 kilobytes what it forces you to do is clean up CSS that you don't longer need now around wintertime a lot of us have these promotions for for Christmas or for the holidays for certain sales and we have CSS for it and then we get rid of the we don't show it anymore because you know in January Christmas is over but someone forgot to clean up the CSS it's still there even if your users don't see it but they're paying for it with their time because it takes longer to download and their wallets because this takes up data so limiting CSS to 50 kilobytes means that you're going to have to clean up these things and it's going to give your users a much better experience the next thing I want to talk about is third-party JavaScript and mainly in relation to ad so ad have not all kept up with the time and a lot of them think that they need third party JavaScript for their execution and because ads are important and they make money we have to allow them to exist and so they use third party JavaScript but we we have to tell them they need to be in sandbox iframes because third party JavaScript does horrible things first they write think script so again you have this issue where you have to wait for these scripts to load before you could see anything on your page the next thing is that they document dot write more things script so you have a lot more Singh script that you have to wait for and it all adds up and the third thing that they do is style recalculations which is very heavy on the CPU because they have to scan your entire page and it also might be wrong because if you name a CSS class the same thing an ad could potentially change the style of something on your page such as your logo and you don't want that so by limiting third parties to these sandbox iframes they're still going to do these bad things but they're not going to affect the rest of the page they're not going to affect the load and they have their little box where they can play and also doing salary calculations are going it's going to be a lot cheaper because it's only going to scan the content of the iframe rather than your entire page this is like allowing your toddlers to play with paint and you know that they're going to make a mess you just want to keep that must away from other parts of your help the next thing we do is resource prioritization so a typical mobile page is a lot longer than then your viewport then your first viewport of a phone and sometimes we don't actually download the entire page when a user taps on it but the our perceive the load to be instantaneous because we load the content in the first viewport before we load the rest of the page and this makes the perception of the load instantaneously even if we didn't have the time to download everything and we also do something called pre connect so for example here's a YouTube video and to lo the contents of a YouTube video there are a lot of things going on but one of them is we have to connect to the source right we have to connect to YouTube and that takes up time so by connecting ahead of time as we know that there's a YouTube video or an image or for example with Twitter to load the you know the content you have to connect to one server to load images you have to connect to another server by doing these connections ahead of time when it comes time to load the content it's going to load much faster so now we've gotten rid of this slow loading problem but we're not done because we have this flash of unstyled content and we don't want this and what's happening here is that the page is loading but then the styles are being applied after the page has loaded and to solve this problem we use an invisibility trick and we set the opacity of the body to zero so it exists but it's invisible to the user and then the styles are applied and eventually the JavaScript will load and unhide the page so to the user it's perceived as being loaded like this first but what happens if there is no JavaScript well we have this no script to unhide the body if there's nothing there to unhide the body and then finally what if JavaScript servers go down which can happen everyone's in a couple of years right and to address this issue we do a CSS timeout animation timeout so for some reason the page thinks that there is a JavaScript that the server times out then we will have a timeout that will unhide the body if the JavaScript never arrives now what I just described to you it's what we currently do but there is a bit of a time delay and we're currently working on doing server-side rendering so that there will be zero time delay so now we reload fast we got rid of the flash of unstyled content but we're not done because 20 seconds into reading this ad loads out of nowhere and shifts the content all around and nobody likes it and what's happening here is just like I talked about earlier is that I'd use these third parties Java scripts and they're really slow they take forever to load we can't force all the ads to be implemented in a way that they're going to load fast right we can't force them to do that but we have to allow them to play so to solve this problem where we let them exist but don't punish our users we put these placeholders because we know that there's going to be an ADD and we have static resource sizing so we know the size of the ad and so the user can read the contents of the page and then it's up to the ad to load on time and eventually the ad will load and it won't shift the content so the user can continue reading and have a pleasant experience and we've solved this content shifting issue but we're still not done because we need to address this frozen janky problem that's happening and what's going on here is that the CPU is overworked and overloaded and to address this we do a few things first is that style recalculations are really expensive so we want to minimize style recalculations and we do so by caching the coordinates so we know where all the things our and then we know when things resize and that's the only time that we're going to recalculate the style also we batch the dome access so for example I have this code sample where we measure something and then we set the height we change the zone and then we measure something again and then we change the zone by setting the width and then we measure something again and this is a very reasonable chunk of code but what's happening here is that the style is being recalculated every time you measure something because the dome has changed so by batching the dome access we can schedule a read for the first animation frame and then we can schedule a write for the next animation frame so that you only recalculate the style one time in this example and this is going to be a lot less expensive for the CPU so we have a max of one style recalculation for spring and this is the main thing that makes amp pages fast when you interact with them this is really the only thing you can afford if you want to get to 60 frames per second and we only do two style recalculations for a page load which is very low compared to other pages the next thing is that we want to do GPU optimizable animations only in our in our amp components so animations are very expensive for this CPU and we want the CPU to the handover the work to delegate the work over to the GPU because the GPU can do animations really quickly and really cheaply and so in our amp components we only allow animations that the GPU can perform in this case it's transform and opacity so if you wanted to animate the width the GPU is not going to know how to do it and it's going to say CPU you go ahead and do this so we don't allow width or height animation but we do allow transform and opacity because the GPU knows how to do this and it can do it very cheaply so now we've gotten rid of the frozenness and janky nice but I want to take a moment so everything I talked about now any developer can do you can apply in all of your development processes but because we're talking about amp amp also uses a cache so if you wanted to build a system it's a little bit more complicated but you can optimize with cache and what we do is first of all the cache we have servers that are located in lots of places all over the world so they're physically located next to you and that means that delivery of the content is going to be a lot faster when these servers are located next to and these servers they could be Google servers or they could be CloudFlare servers it doesn't matter but that's going to give you that real boost of speed is to have this cache and some of the optimizations that we do on the cache is the first is efficient pre-rendering the browser is used to have this thing called a rel equals pre-render where you could tell their browser you could have a link on your page and you could tell the browser hey download pre-render this link so the browser would download all the contents of the page and and then when the user would click on the link the page would load instantaneously but the problem with this was that it downloads the entire contents of the page all of the images all of the ads all of the analytics so the third party JavaScript and it would R execute arbitrary JavaScript in the background and that's very heavy for the CPU so instead what we did is we pre render only the first viewport and we don't execute any third-party JavaScript so none of the analytics and all that stuff and what this does is it makes pre-rendering extremely cheap and non expensive the next thing we do is resource compression and by resource I mean all the things all the files that the users are going to download on to their page and some of these files are JavaScript files and so we use a closure compiler to compress our code and here's a chunk of code on the list and if you run it through the closure compiler it's going to compress it to the chunk on the right and on top of that oh it also does tree shaking so it gets rid of dead code and methods that aren't being used and so on and we have our own optimizations that we do on top of the closure compiler so we get rid of developer codes such as blogs that you only use for development but your users they shouldn't have to download those lungs because they're not going to be useful so we get rid of those as well on our main page on the HTML we use a compression algorithm called brought Lee and that saved us 8% over gzip which is another compression algorithm and then finally I want to talk about images because images make up 64 percent of the bytes of an average mobile page that's huge so if you can effect images you can have a huge impact on the size of the page so we compress images the first thing that we do is we remove invisible data this is metadata that your users don't see such as geolocation and so on and we also we reduce the quality of the image and we try to have one color sample for every four pixels and this reduce the image size by 40 bytes on top of that in for browsers that support WebP II which is another image format such as JPEG we convert the images to WebP II and that reduces the images further and then for Chrome users that have data saver enabled or places in the world where data is extremely slow we lower the quality of the images even further to save more bytes so now when we apply these three things on an image let's look at the before and after so before we have two hundred and forty thousand bytes for the left image and the right image has 25 thousand bytes that's about a 90% reduction in bytes and keep in mind images make up 65% of your page so that's pretty big and you might look at it and say you know what I don't like the image on the right it's not as good I could tell the difference but I want to tell you that actually I switched them so the image on the right is the before the image on the left is actually the after so now to summarize everything if you haven't paid attention or if you just walked in to make webpages faster we want to unblock the render by making sure that scripts are asynchronous so you don't have to wait for them you want to bring your CSS with you you want to inline it and you want to limit it to 50 kilobytes and third javascript is third-party javascript is okay but you want to put them in iframes so they don't affect the rest of your page and you want to prioritize your resources you want to load the things that the user is going to see first also we use opacity magic to make sure that this doesn't happen and we're going to do server-side rendering in the future so that there isn't even a tiny bit of a delay and you want to stop shipping by having placeholders and static resource sizing so that your users don't suffer from this atrocity that I'd usually commit and then you want to unfreeze your page by giving your CPU space to breathe so less cell recalculation and let the GPU do the animations and then if you can do cache optimizations and do cheap pre-rendering and compress your page so let's see how we're doing 19 seconds for the average mobile page to load and less than one second for Ambon search and what does this mean well it translates to 10x less data we have higher CTR publishers are saying higher CTR and higher ad viewer ability and today there are about 2 billion amp documents from about 900,000 different domains so hopefully if you apply some of these things you can see similar benefits as well and if you don't want to do all of that work you're welcome to use em now I know this is Jay's cons and you all love JavaScript so you might not want to use em because it doesn't involve writing a lot of JavaScript so I'm here to tell you that you're welcome to write progressive web app and use em for content delivery and that way you can write lots of fancy JavaScript and if you're passionate about what we do and you want to help out amp is an open source project and we welcome contributors there you're welcome to work on the project with us and create m components to learn more about the m project please go to EMTALA org visit our youtube page if you want to contribute bitly slash health amp and right after this we will be at the am booth if you'd like to meet our team thank you [Applause] [Music] [Applause]