 Hello Welcome to getting content to a phone in less than a thousand milliseconds My name is Ian Kerco I am what I refer to as a back-end of front-end development So I do all of the things on the back end to make the front-end awesome that includes dev ops performance content strategy things along that lines you can find me on Drupal.org at I am Kerco or GitHub at I am Kerco or Twitter at I am Kerco or my website I am Kerco.com Pretty much if it's online, that's my username And I work at four kitchens So first of all what this session is about It's all about what affects the front-end performance guidelines to better page loading as well as the protocols that we utilize things like HTTP TCP, SPDY or speedy affects our slides You can find all of these slides They're all up on github at I am Kerco slash a thousand milliseconds You can also file tweet this out later and I'll do it at the end of the form presentation as well So first off, why is this so important that we have fast sites? Large companies like Google Amazon Bing have done many studies into User behavior when sites are fast or if they're artificially slowed down in any way shape or form We find that when our sites are slower bounce rates increase drastically We have mental context switching happens after about a second So if a user is looking at their phone and clicks on it and says I want to go to this page And it takes over a second then instead of thinking about the content on your site they're thinking about did I leave the gas on or is the oven still running or What do I need to get for my girlfriend boyfriend partner etc for Valentine's Day, which is coming up There are many countries that are mostly using mobile devices now in the United States, I think we are at almost is it 40% of the internet usage is on mobile devices Everywhere else around the world. It's much higher than that. I think India is close to 55% I could be wrong with that But if we're working with international work, we have to work with mobile devices And we can't just rely that 4g is going to roll out everywhere across the globe and solve this problem for us There are a multiple reasons for this not least of which is it's not gonna happen anytime soon guys. Sorry it's not even all over the US right now and It won't be enough to solve our problems So first of all, well, we're talking about front-end performance the first rule that you need to remember And this is by far the most important rule is that all of these rules are more like guidelines There are very few steadfast if you do this your site will be faster The one I could always pull out is Jesus Coding which if you do on your site your site will generally load faster except if for whatever reason it would be faster to Load in a single packer response therefore causing unneeded in G-zipping Which is a very very rare stance But even steadfast rules like G-zipping also have their little footnotes of except in certain situations So with that in mind test Everything everything you do needs to be tested you need to look at When you're starting to look at upping the performance of your site do a baseline set of tests know where you're starting at So when you start changing things whether your aggregation G-zipping server configurations, what have you you can see how much it is helping your site or if it's helping at all Sometimes you might do something you think oh this will definitely help Performance and you might find out it actually hurts it in some places. So make sure you are testing constantly There are a bunch of tools for this online You have web page test y-slows paid speed Chrome's dev tools Casper J s all of these are various tools I can do various different forms of front-end testing. I Love web page test they can test your site from multiple locations across the globe with multiple browsers and OS's So you can quickly launch a test that will Load your site five times from Chrome and Amsterdam and then another five times with Internet Explorer in New York and other five times with Firefox and Rio de Janeiro what have you so you can test internationally Quite quite simply Page speed and why slow are both browser extensions that you can load up and will give you instant information about things that will help your performance The important thing we're talking about testing is that if all of your users are Let's say your entire user base is in Brazil and they all use IE 8 Do not test from Amsterdam with Chrome because that's not to your user base Test with what your users are using so look at your Google Analytics or whatever analytics program you're looking at Find out what browsers are being used where they're being utilized from and test according to that not according to What other people use so when it comes to this Every single site will have a different set of testing requirements depending on where your site is and what your user base is You could easily go into an entire presentation just on automated front-end testing In fact Chris Ruple has done it and instead of going deeply into all of those tools right now There's a presentation and the links here. It's from Drupalcon Amsterdam called automated front-end testing Go watch that later. It is fantastic He goes over all the tools and has great code examples on how to automate your front-end testing to be beautiful so The first thing we're going to try to do when we want to load a page fast is to remove render blocking resources So the idea here is to at the very least make it seem like your site is loading very quickly If you ask yourself, what is a render blocking resource? It's kind of hard to see but we have a picture of Gandalf the gray and the ballerog and The ballerog is trying to get past this tiny little bridge and Gandalf the gray is our render blocking resources saying you shall not pass It is something in the header usually Things like CSS files or JavaScript in the header that the browser will wait until that loads before loads the rest of the page So if we have Five very large CSS files before the page will even display all five of those CSS files needs to load We want to try to eliminate that as best we can It's kind of the the technical house is working This is the very basic version of how a browser builds a web page in a browser courtesy of either your gorg So we have our network connection which we create a Network connection server and then our network will grab the HTML and our CSS I have the HTML It starts create the DOM which I'm sure we're all very familiar with and from the CSS It creates the CSS on or the CSS object model or the Psalm. So I refer to it as It is not until both the DOM and a CSS object model is put together before it will create your render tree and Paint anything so before anything can display on a page before it goes from white to anything else You must have both the HTML and CSS So if we can reduce the amounts of time that it takes to get either one of these two files The better it can be There's also kind of a side note JavaScript is also in there But JavaScript will not necessarily block it unless it's in the header of the file without a asynchronous for tag Which we're gonna get to a little bit later As in right now So our first thing we do to eliminate these render blocking your resources is with JavaScript Move all of our jobs to the footer. This is the quickest and easiest way the farther it is in the footer It won't block our rendering everything is happier You can also start utilizing async and defer. They're both actually very well supported It will instead of blocking a resource it will load it asynchronously or defer the execution of the code Asynchronously so that it will not block the rendering of a page defer is actually fully supported in triple seven and I think is not yet You can also inline critical CSS. So any CSS that is Important it needs to run immediately while the page is loading or any JavaScript Sorry, it needs to load immediately while the page is loading just in line Don't add it to an external file put it directly in the file and html To do the moving your jobs through the footer and using both async and defer the magic module does all this Magically you can enable the magic module click a single button and all of your JavaScript will be in the footer immediately that includes all of your Libraries jQuery everything of that nature. There's also an option to leave jQuery and Drupal once and some other Drupal core code in the header, which will be required if you're using a whizzy wig If you're using c8k editor, it's not required anymore, but if using whizzy wig it will be When it comes to CSS we have a similar idea We want to inline critical CSS so any CSS that is required for a user to view the page immediately is Inlined it's a lot of tools to do this A lot of tools and grunting gulp that can help do this. There are two different ways of Inlining your CSS you can either Take the CSS that's required to view a mobile-sized viewport Or like anything above the fold and inline that or you can also optionally inline Manually things that are important the header of the footer or the header the content area things that are required at the very beginning Both work fairly well The rest of the CSS we can load asynchronously with something called load CSS this will Asynchronously load all the rest of the CSS is required for the page after the emissional paint has already happened So you can quickly and easily Display a page and then have in the background everything else be loading in And if you use load CSS it will still keep it in your browser cache, which is great There is no Out of the drop out of the box Drupal solution for this yet. I Look forward to all y'all contributing something that can do this It's a little bit more complex than just moving something to the footer But there's a lot of grunting gulp tools that will help with this as well so If we go back to our here Our little chart here of how the browser builds everything obviously we need the HTML and CSS But it's also reliance on the network The network is the one layer that will always hamper our website loading So when we're talking about loading a page, we use something called we use the ACP protocol, which is based on TCP and When we talk about TCP the issue that is always comes to mind is actually I use Apollo 13 as a reference but it's a great scene where Houston is trying to talk to the Apollo 13 module this landing and they're saying odyssey. This is Houston Do you read and they're waiting a long time because they're a far far distance away not really saying much They're not sending a lot of data doesn't matter that they need to encrypt this or gzip it or what have you It's just a matter of that. It's traveling a very long distance to the moon back So there is a delay there the same sort of principle applies when we're building website It's not necessary the speed of the connection. That's the issue when we're building websites It's the latency So we have two charts here our top chart is the page load time for a basic site and As page and compared to speed of connections, we have one megabit per second two three four five As our speed increases we hit a point of diminishing returns It doesn't necessarily load that much faster once you hit three to five megabits per second Speed isn't a factor here. However, we talk about latency the amount of time that it takes for a packet to go from a user's computer to your server and back The more and more we decrease latency. It is a direct course on Correlation to page load time so the more that we can decrease our latency We have a direct effect in loading our page faster A good way to think about this is a single round trip. We're talking about a fiber-based connection or Google fiber When a page a TCP connection is created You have an initial DNS lookup where it says, okay, I want to go to Google comm What's the IP address for this? It takes about 40 milliseconds more or less Then you have a TCP connection is created. So this is when your client goes your user goes, okay I need a web page from you guys and the web page says, okay, what do you need? if you're using TLS or HTTPS that will add on an extra 600 to 120 milliseconds, depending on how your server is configured of back and forth of okay, I Want this web page cool. This is our security protocol awesome. This is my key cool. This is our key. Okay, we're good And then finally we have the HTTP request where the client can finally go. Okay. Give me index.html And that takes another 60 milliseconds So all of these round trips just to grab an initial page or initial response from a server Takes between 220 and 280 milliseconds not bad We have a lot of wiggle room to get it under a thousand milliseconds with that our problem is wireless LTE will take about a hundred milliseconds to go from a phone To your server and back So that puts us up to 400 500 milliseconds just to get an initial response back from the server With 3g That's up to 200 milliseconds. So just to get an initial response back Just the server setting back the dock type at the very beginning will take 800 to a thousand milliseconds So for us to load a site in less than a thousand milliseconds on a 3g connection using HTTPS You have to return the site in the first pack response So there are a lot of ways that we can work with our latency issues the first and most obvious our content delivery network CDNs Delivery of data is limited by the speed of light We can't go any faster than that and generally by rough the cable is about speed of light roughly So we're gonna put our content closer to the user Physically closer will make it a little bit faster So, you know my user base is in Bogota and Texas and New York City have a CDN that has content and servers in New York City Austin and Bogota Don't put one in Amsterdam because that will make it slower The other thing we can do is reduce redirects So we go back to that chart where we have all these back and forth to create an initial connection Well, if we are redirecting our site to be something else then immediately that increases by another connection needs to be made So I really don't say reduce redirects. We should just remove redirects get rid of them as best as you can Links that get shared out should always be the full address Redirects are very very bad and We also would like to respond everything in the first packet response So what this means is that we need to respond with an entire complete web page that the site can load with the CSS object model and the dog the HTML in According to RFC six nine twenty eight ten packets of data Which is about fourteen point six kilobytes including headers This is our ultimate goal is to have all of our sites load in the first packet response A good example this happening in the real world is my blog HTTPS slash I am care for calm will always load in the first pack response no matter what It has a actually we'll get into all the rest of it But it loads all of the HTML in line the first time and every time else it will load it But it loads everything else asynchronously We also have some tricks that we can do with HTTP 1.1 or what we are referred to as just HTTP The first one is called domain charting. So a Modern browser will create six TCP connections to download files for each domain So that means it can download six files at the same time at any point times We grab the index HTML your CSS files your other CSS files your other CSS files your other CSS files Yes, I know how Drupal does this aggregation However, you can kind of beat this by using domain charting. So having Domain WWW one dot your domain comm WWW two dot your domain comm and although they all leads the same server It will mean that the Your browser one set of having six connections can have 12 or 18 So if you have a lot of resources that needs to load you can have multiple different domains that will Secretly load all of those files We also do concatenation this is built into Drupal where we put all our files together we Instead of going getting six files which will require six TCP connections will require more and more back-and-forth Try to send only one which will less latency less back-and-forth faster website We also have spriting which is the same idea as concatenation except with images Where we put all of our images in a single file with CSS put the correct one in place So instead of grabbing 20 small files we grab one big one which again cuts on TCP connections cuts down latency faster website We also have inlining of assets instead of loading all of our CSS files with You know every single file is a single as an LTV request more back-and-forth in line the necessary resources And the most important thing you remember is that the faster request that you'll ever make is the one that you don't If there's something you don't need on your site, you shouldn't be loading it So if you have a good example, I saw a while back as there was a site that Loaded like six different sprites for their six different subdomains on every single one of those domains It was you don't need to do that You only need to load the one relative to that domain because they put everything together that they're making all these extra requests That were never actually shown on the page Don't do that These are all tricks with HP 1.1, but luckily Google has been selling a lot of work in what's called the speedy protocol spd y or htp 2.0 as it will be called once it's finalized Speedy Ish it's like speed racer It's a lot faster. So Google did a lot of research into How to all these issues that we're having widely and sees causing such an issue and they created a new protocol called speedy and What is it? It uses multiplex streams There's a fancy way of saying with HP 1.1 We have to create a new TCP connection for every file that we want to use Instead it reuses the same TCP connection and Downloads everything in a single stream. So instead of having to create six connections and go back and forth six times It's great all those connections. It will use a single connection. That's reducing the amount of latency that's required And the multiplex streams will allow multiple files to go along the same connection Because everything's going along the same connection. It also allows her request prioritization So you can say main dot CSS is more important than trivial dot CSS And it will make sure that main dot CSS always loads first over anything else my favorite part it allows for Currently when we are loading a web page with HP 1.1 The server will go. Okay. Give me index at HTML. It will grab it. It'll start parsing it and go Okay, I need main dot CSS and it will say okay. I need main dot CSS now with speedy instead of The client's always having to go and request assets the server can push it So it can say here's index at HTML and you're also going to need main dot CSS and scripts dot JS And it will start sending that along without another need for a full request being made It'll also remove redundant headers So if you ever looked in Chrome and looked at the headers that are sent back and forth between the server That's extra data that's being sent back and forth speedy will change that by only sending headers that have changed So if you all have the same headers of this is my you know cookie or what have you it doesn't need to be sent back And forth every time it will only be sent once It also compresses the headers So there's basic G's of compression to make sure that headers are compressed therefore less data a little bit faster Certainly with a speed 2.0 slash speedy. We're gonna have you doing different tricks than we would with a to be 1.1 Do not use domain charting You're gonna find a trend on this one Because we're using a single t-spee connection It will actually hurt your speed if you are sharding domains because instead of using a single t-speed request We're gonna be creating more and more with speedy. You can utilize only one Concatenation can hurt performance So this was kind of a mind-boggling for me when I first heard it, but if you're concatenating on your files together and Let's say one of your files gets changed really frequently because it's code That's being altered on the site by developers every day and you're concatenating your files Then every single time one of those minor changes made the whole file will be sent over and over and over again With speedy it's better to leave all your files separate Because then you know jQuery which will never change will always be cache always be stored while You know your scripts for this one slider that you're using on your homepage Which changes every single day because the client can't make up their minds can change all that once and only send a small bit of data You can also start using server pushed for important assets So things that are required CSS files JavaScript files things of that nature can be immediately pushed to the client That last bit. I've been trying to Figure out if a speedy module would be a good idea or not And it's in research. I'm thinking it will probably hold off till Drupal 8 to do Because speedy isn't going to be a protocol that we're all using Probably for another five years You think Drupal 8 taking a long time to get out So a case study to kind of look into all of these things working in unity is HTTPS. I'm careco.com. That's my blog So it uses speedy deliver everything It has a custom CDN It's a long story and I wrote a blog post on why it has a custom CDN But none of the rest of the CDNs that I want but it has servers in Singapore, Amsterdam and New York and Once don't digital ocean opens a server in Latin America. I will do it But I can't afford anything but that All the DNS has been moved to Route 53 so that Route 53 will send Each user depending upon their location to the correct server It inlines all of the critical CSS actually all of the CSS on the first page load And then it will load the rest of CSS asynchronously The results last time I checked the page speed score was 98 the why slow score is 98 Ping them gives me a score of 93 with sub and 500 milliseconds load time and web page test Lows between 400 and 800 milliseconds load time Very fast of no matter where I put it across the globe So what's next for that? Never stop Improving there's always gonna be changes new ideas new techniques There are a lot of great people doing some great work to speed up sites a little better Finally one question I've been asked a decent bit is who is actually responsible for performance in a team Who is it that needs to bear this burden and make sure that everything is performance on a site? and The answer really is everyone must think about it. It can't be something that's an afterthought it can't be something that is Oh this in the last three days of the project. We're going to fix all the performance issues That's going to be a nightmare So really the entire team must have the data to be making the right choices performance wise What this Well, then like the performance expert whoever that is needs to give the right information to the team But they need to give them. Okay designer. You need to know that if we load this Image that is 500 megabytes on the home page that changes every page load. It's going to be a terrible idea We need to you know load smaller images sizes things of that nature But also go back to our automated testing slides of Automated testing as we set up where everyone can see the impact of decisions that they've made on the code immediately Where on a merge to master something? Automated tests can run from web page chess or ping them or what have you that can say oh, no in this last commit our performance went from You know loading in 800 milliseconds and now it's two seconds like we need to reevaluate what happened here and look back at it But everyone needs to have that data and be able to do it so they can know When the decisions that they're making are affecting the performance of the site And really it comes down to it needs to be easy needs be something that every developer can run a grunt command a gulp command Go to their Jenkins server or whatever you have set up for CI who are going to set up for the eye after this presentation And can click a button and see this is what's going on right now It can't be something that's difficult or no one's going to be using it and then also we're going to have a 100 megabyte JavaScript file That's possible and With that are there any questions And as I'm going to hand off the mic so that we can record this. Thank you. Well Talking about this pity protocol. What do you think is going to happen to the Ajax calls? You know because when when I'm talking about performance using HTTP one one one dot one Most of Ajax calls are not on during the page load. They they're they're made after that and What do you think it is it's going to be the future at the next steps? when loading Ajax calls not see me step see me turn and see mutinously, I don't know and Still get the full performance from speedy I Don't think there's going to be a difference and and here's why because Ajax calls will happen after the base bit As long as you're using the right the same domain. It was the exact same TCP connection So speedy will keep your connection alive for a good amount of time for my your server set up correctly So really it it won't it will only make those requests a little bit faster because you won't need to create a new TCP protocol, but again going back make sure using the same domain if you're using a bunch of Ajax request of five different domains after your page load those are going to be slowed down dramatically every time Thanks for the presentation really good. I was wondering about your website. I am Kariko dot-com because You know I loaded and of course is super fast But then you have no images Your fonts are very few your CSS is very basic you had like almost no header and You know I I wonder you know how How would be if you have a very different example, you know something like loaded with images a lot of styles big header You name it I Love this question because every single time I give the presentation someone points it out immediately You're right. I am not a designer. I actually did a lot of work to make sure my web fonts are loading very fast They're part of the reason why I use my custom CDN however There are a lot of things you can do so if you look at the first response. It's still sub Eight kilobytes, I think which actually gives you a lot of wiggle room I've been working on the four kitchens website to do a similar thing Ironically enough web fonts are what's holding me up right now because they're weird However, as long as what you're doing is called with Ajax And loaded asynchronously you can do the exact same thing. So the same principle still apply It's the reason I show my blogs is a relatively simple example of all these principles in play But you know load your JavaScript asynchronously load your images asynchronously load your ads This is a big one. It adds should always be loaded asynchronously images are already loaded Asynchronously your page load will not be altered if you're loading a bunch of images So while it is a simple example the the principles still directly apply and there's still a bunch of tools out there That can help you do the same thing But yes, it is hard to do it especially on a big Drupal site. I understand Just curious you said your site is already using the speedy Does it require a special library JavaScript to our plug-in on the browser? How does it work today? Not at all. So Chrome and Mozilla both support speedy out of the box The server has to be set up specifically so I'm using engine X with speedy built into it And a lot of things aren't finished in the engine X version So I don't have server question once yet because when I built this it wasn't part of the engine X extension It's shockingly not that hard to set up and it will default to regular HP 1.1 HTTPS if it the browser doesn't have it. So there's a really smart protocol to make sure that it's loading as as fast as possible It's If you are have your own infrastructure It is really simple both Apache and engine X have extensions to use speedy right now And they're both were very well featured actually Any other questions? Don't be shy Okay so we we recently implemented CDN and And I really like what you say at the end You know who is responsible for this because we get a lot of pushback from the editors in our sites They want the biggest hugest feature that they can find and you know Super 10 megabytes videos and etc. Right. So there's a lot of times it's always pushback And we implemented the CDN we put a lot of work it we pay for it, right? jet the The you know the speed it and or they increase the increment in the loading performance Was not that we expected right and we I mean we fine tune and fine tune and finally we perhaps wait You know gain 20% in speed something like that so at some point I was wondering you know is is To what extent you you invest so much on that and if you are like all the way with Akamai, right? Yeah, and $10,000 a month for the CDN perhaps You know is it is it worth it? How you balance that out? so I mean obviously that's a business question of what is it worth I? Always look at it is what is the distance between you and your users? So if all of your users are in a single country There isn't going to be much of a gain by using a CDN The biggest game that you're going to get is generally CDNs are set up to be a lot faster response time But if you're using something like save pantheon or aqueous hosting They're actually set up to do that already as well So you're not going to get a huge performance boost where you get huge boost is when your your audience is in geographically diverse locations, so if you have an international audience then it's a huge boom There are I'm trying to remember there's a site. I used a while ago of looking at the ping times between servers and It is shocking how long it takes to a Ping to go from New York to Australia Because you're crossing three oceans to get there usually or a Country an ocean and a sea to get to Australia. It's a long distance like no matter what That is going to take some time even going literally at the speed of light You're totally right because if we look at the numbers overall You don't see the impact You know, I'm looking at for example the our numbers in South Africa in the in in the Latency we went from 300 milliseconds to three milliseconds Because there is a server right there in Cape Town and Yeah, of course in the overall picture of our analytics it doesn't look that much because we had a lot of traffic from the States Awesome any more questions Bealer Bealer Okay Then as final thoughts. Oh No, what did I just do? Either you're Gork who is a performance engineer for Google has a fantastic book on web performance Go read it It goes into all of the protocols and like why what we do matters It's fantastic and isn't a very hard read. He's a great job My slides again are at I am seco dot slash 1000 milliseconds They're also also on github so you can go to my github. I am Kerkow. They're all there And thank you. Thank you very much