 API Vangelis for MYOB, who helps customers make awesome things. He also runs a number of meetups in Sydney, and is overall a really sweet guy. So he's absolutely the expert we need to talk to us today about how to make the web fast with jelly snakes and raspberry twizzlers. Let's make him feel welcome. Thank you very much. Hello, welcome. My name's Jack. If you know me online, you may potentially know me as Jack Skinner, quote, semi-colon-dash-dash. I do get some interesting lanyards printed for conferences when I o-auth with Twitter. That is a bit of fun. And if you are on Twitter, please tweet me at developer Jack. I warmly invite corrections, questions, heckles, and embarrassing photos of me in speaking poses like this. So I'll see you after the talk, and hopefully I'll beat the tweets per minute counter for the conference. Today, I'm going to be talking to you about making the web fast with jelly snakes and raspberry twizzlers. Why? I want to bring this back down to why we need to focus on performance and what impact that has for you and your customers. So I went and did some figures. And the Financial Times did a bit of an experiment where they took one second extra simulated page speed. And they found that it was a 4.9% reduction in content consumed. And almost 5% reduction in content consumed is a really, really big change in the way your customers use your site, especially if you have advertising revenue. And these are some US figures. We know that 30% of online sales are mobile. And yet the average site loads in almost seven seconds. 40% of your customers will leave after three seconds. That's quite a large volume of your customer base that you are losing after that third second. These are some AWS figures from Amazon. And they found that 100 millisecond improvement added 1% revenue. Now these figures are also sort of in flipped to a degree where they found that adding 100 milliseconds lost them 100% revenue. So you sort of flipped that equation around somewhat. GQ relaunched their website in the US last July, I think it was. And they found that an 80% reduction in load time they've optimized the site had an 80% increase in traffic. And GQ has a very large business in advertising and content consumed. Now they also found that the time on site went from 5.9 minutes to almost six minutes up to 7.8 or almost eight minutes. If that's a phenomenal improvement to the volume of content consumed on a website. Is anyone here more on the operations or networking side of tech? Few hands, wonderful. They also found that in optimizing their website here they had the number of calls to server reduced by 400%. Yeah, I heard her in the audience. Now ultimately we go back to that sort of three seconds and you lose customers metric. They got their site down to two seconds. Which I think is absolutely fantastic. 79% of dissatisfied customers will not purchase from your site again. And then that's specifically dissatisfied with performance. So if your site is slow, you're going to piss people off. And further 44% of those will actively tell their friends. Now when we look at the US versus Aussie speeds and I love coming over here in New Zealand because they're much faster internet. We know that the world's internet varies quite a lot. So if you're looking at US figures you have to tune this for your local audience whether it be local to a particular country or a region or globally. These figures need to be adjusted for your customers. Ultimately, slow sites make me sad. And I haven't spent the last week on the road talking at conferences just to be sad about web performance. So I want to talk to you all about how we're going to improve this. So I want to do a quick survey so I understand the room here. How many people are sort of web native? You use the web quite a bit. That is hopefully everyone in the room. Okay, keep your hand up if you know how HTTP works. Okay. And what if, keep your hand up if you know HTTP well enough to write a client or a server. You're allowed to reference the RFC. Okay, so a few hands went back up again. So I saw a few hands go down which shows that not everyone here is going to go and write an implementation or contribute to an open source server package. I'm going to go back to very, very foundations of HTTP and bring us up through current best practice and then we're going to land into some performance things. I have a three M's approach to performance. Measure it. If you do not know where you're starting from you cannot reliably make improvements. And in fact, that measure is so important that it is also the second M in my three M's approach but it's got a slightly larger font because you need to measure the progress you make when you're making performance improvements. You don't know how much of an impact you've had without measuring it a second time. And of course measurement is so important that you'll never guess that the third M is also measured by an even larger font because the web keeps changing and you need to keep that performance monitoring in place to understand how your customers and how the ecosystem is changing as the web grows. Now for anyone that is not familiar with HTTP and there are a few hands that went down quite rapidly after visiting Facebook, the web has a very simple request and response model. It's very much question and answer. We have a request that goes out so I'm asking in here to get the resource devjack.css and I'm speaking HTTP 1.1. Now along with this request is some extra headers up here in the sort of green box and these tell me a little bit more information about what my request is. In APIs that can be API keys and authorizations and here I'm saying that I'm using a Chrome browser and I specifically want the developerjack.com website subtle website drop. The response comes back in from the server. It says yes, 200 okay, I know how to respond to that and it gives me back some more headers over here. Here it's gonna tell me that I'm getting a star sheet and that I get an ETag and this is often used for caching and other sort of versioning types of things. But realistically the entire web as we know it on HTTP operates on this question, answer, response. And there's a lot of waiting involved in that as you wait for an answer. So at the very, very foundations, the client asks for some content and it asks it to the cloud and the cloud is of course somebody else's computer and you never know where it is and the cloud eventually when it's ready responds with an answer. So the first performance thing we introduce is a content delivery network or a CDN where we conceptually move the cloud a little bit closer. Now this has the added benefit of having complexity in your application stack. For example, my side projects I like to launch up on Heroku but keep all the assets and the static content on S3. And so anything that goes to the S3 content can go up to one origin and anything from my application can go to a second one and having a CDN closer to the user is a performance improvement because I can cache things on the CDN, faster responses and I can have a single consistent interface between all of my infrastructure. Now minification is a bit of fun. It takes large files and makes them smaller while increasing the file name. Makes small file names bigger and big files smaller. It helps remove some of the superfluous characters and data in that. That means that the content we're transferring over the web is smaller and that's important anywhere you go. The smaller the conversation the faster you can have it. Compression takes this sort of size reduction a little bit further. It's not usually implemented in your application but rather in the transfer process and it's obviously sent back to the cloud. So my content for example is not GZipped from my origin. It's GZipped from my CDN. That's also really important. And then we also have concatenation where we combine multiple assets together into one ginormous file and here we're taking scripts.js and dependencies.js and then of course someone didn't publish it through NPM so I've got it hard coded, committed into my repository Libs.js and I bring them all down into one file so I don't have to have multiple conversations. As I mentioned earlier, conversations take time and there's a lot of waiting involved to get that answer. And so we now have everything.js and often we introduce here manifests so that we can debug and figure out extra things with our code and this is all front end performance on our websites. Now when you combine all these together we get some kind of pipeline where we get scripts.js and dependencies.js and Libs.js and we get a very large everything.js and then a slightly smaller but larger file name everything min.js. And most of us here that are involved in web development will have these automatically run using Gulp or Grant or some kind of build tool for your front end assets. And this whole pipeline is generally considered best practice and that's true. The practices and processes we have developed over the many years on the web just because of HTTP 1.1 and the way it models conversations and data transfer. Ultimately though, we want to help web browsers be lazy and do less work. And so with HTTP 2, we're gonna start to see a focus around reducing those conversations and reducing the amount of work that a client has to do. So what is HTTP 2? Well, it introduces a number of changes on top of HTTP 1.1 and I'm only going to cover a few very small points because there's no point in me reading out an RFC you'll all go to sleep. So we're gonna focus on a couple but overall so you get a bit of an understanding HTTP 1 and 1.1, we're all plain text protocols. You could literally tell net to port 80 and type get devjack.css HTTP 1.1 and you could manually type out that conversation. With HTTP 2, that conversation is now binary, not plain text. So unless you've got some kind of middleman or application or library to do that for you you can't really have that conversation anymore. So the tooling has to be in place to use H2. Now it's also multiplexed over TCP. So when I had HTTP 1.1, every single question answer response was another TCP connection that I would open. With HTTP 2, that is now a single TCP connection per origin. So it's based around host names. It also introduces HPAC header compression which is really good for especially mobile clients where data transfer and speeds are reduced. And there is a stream priority so that with all these multiplexed conversations you can prioritize certain conversations. There's no point in loading some resources before others. But for me, because HTTP 2 is new and it was only ratified as a formal standard early last year, we're still getting the tooling coming into various projects. For me it's shiny. And with everything new sometimes it's a bit of oh I have to go implement that now don't we? I want to flip that. I want to challenge you to say HTTP 2 is fun and here's why. Waiting is bad. We never like waiting for things. We like things to be quick and snappy. But the internet is not simple. You can't just go and turn on the tap to get data and have it immediately come through the pipes. And I struggle with this analogy sometimes because it can be taken too far. But for me the internet is much more like this tap because when you turn it on there's a gurgling noise and a rumbling over the hill and then eventually you hear some rattling and sort of a squeaky noise and you sort of hear the water coming through the pipes and redirect it up over the hill through the garden bed around the corner and through the tap where it makes a splashing noise and then finally you get a stream of water. The internet is much more complex than we think about it. So the time to first byte metric is a huge portion of our web performance. Here what we have is we have a client requesting what will be hundreds of assets no doubt with the modern web. And in fact, can anyone remember when DOOM was released? That very first binary that came out? The average web page, the whole payload is now bigger than that DOOM binary. The web's getting really big. So we've got one conversation to get index.html and we get index.html back, we pass the content and the web browser then goes, aha, I need style.css. And I'm gonna request style.css and I'm gonna wait for it to be returned. And then when I finally get it back, I'm gonna go, aha, I need fonts and I need JavaScript. And all of this blocking content really slows down the page speed. Now, when you introduce TLS or running your website with HTTPS, you introduce a conversational overhead. So for example, to have a secure conversation, I first have to go, hello, sir, are you developerjack.com? Can I trust you? Wonderful, I'll have index.html, thanks. Okay, and then I have to go, hello, sir, are you developerjack.com? Thank you, can I have style.css? There's a bit of an overhead to that handshake and then of course I have to go for it, no, I won't do it again. But you can see that there is this slow conversation overhead to every single request. However, because HTTP2 is over a single TCP connection, that handshake occurs once because you have one handshake and then multiple conversations after that. So while TLS might have been an argument to reduce performance in HTTP1, there's now no excuse not to have security in HTTP2. And in fact, most browsers specifically require TLS in order to run HTTP2. Now, it is not a requirement in the standard. It took a lot of debating. Not a requirement in the standard, but it's a requirement for your customers. So that's the difference. And in fact, it was this particular multiplexing model that was the inspiration for this talk. It was originally written after a Monday night at a pub where a friend of mine said, Jack, you should submit to this conference. And I thought, yeah. And then my friend sort of did a bit of an Aussie tour and then he came back to the pub and we sat down there the following Monday and he goes, no, no, you should really submit to this conference. And I went, and then I saw this tweet. Now, Clay is a developer advocate at New Relic and I absolutely loved this moment where I saw, ha-ha, HTTP2 was a really sweet topic. So when we look at H2 and the way it models these conversations, concatenation and bringing everything together in one very big file is now an anti-pattern because it is more effective to have multiple concurrent multiplexed conversations than it is to have one huge file that you pick up over the internet and drop into a client's browser. Because it means once you've finished processing one of those elements, one of those resources, you can move on and work on the next. So it also means that they're not blocking each other anymore. And if you've got different moving parts in your complex web application, each of these scripts and moving parts in your web page can be independently cached. So you don't have to do a complete rebuild and serve up an entirely new 10 megabyte JavaScript file. You can serve up smaller portions of that code. Now you'll notice that minification is still a good thing here. Okay, we still want to transfer small things. So we get rid of all the superfluous data. But we also know that repetition is bad. So we can cache each individual element and avoid requests. So keep caching things. Keep minifying them and G-zipping them. But stop lumping them all together in a huge file. Break things up and have multiple requests. Prediction, however, is good. If you know the client is going to do something, HTTP2 now allows you to preempt that. So with server push, if a client asks for index.html, the chances are, and I'll put money on this, they're probably gonna ask for style.css. Probably. And you could potentially build into your applications some user agent detection logic. So if they're using links or something like that, then maybe you don't have to spit out a whole big file. But you have one connection overhead, one request, and then your cloud or your application can go, well, I know you want style.css. So I'm gonna push it down the pipe. And when your client, your browser, has finished passing the HTML, it's going to go, I need style.css. Oh, no wait, it's okay, I've got it now. And you reduce that overhead and that time to first byte. Now of course you can then cascade this. So of course you're going to want comic sans. Are you not? No? What's everyone got against comic sans? Thank you, thank you. So we can see this to start to cascade from small amounts of overhead that we've reduced in the conversation and then removing all the superfluous questions. That's where our performance is coming from. Now this is great for web pages. We've spoken about a very, very simple web page model but I'm an API evangelist and I have a lot of thoughts and things to say about APIs. I won't go into them too deep. Here is Apple, Android's Play Store. And you can see up the top there we've got menus. We've got various categories and then we've got some albums and some kind of leaderboard graphic. And in the current web model with H1, and 1.1 I should say, from a web performance standpoint the chances are we're going to have a JSON endpoint that couples all of that data together. It's complicating things. For me though as an API evangelist and helping developers design and implement really clean, sleek APIs, these are completely different resources from completely different endpoints. So with H2B2, we have the ability to have one very small get request on the app's index endpoint and then potentially push down the subsequent resources. So H2 is now going to enable us to properly isolate and represent our resources independently without having to design an API specifically for types of clients. I hate seeing APIs that are built just for mobile because there are so many other data clients out there. Yesterday's practices, many of them are now today's anti-patterns with H2B2. But H2 is an upgrade, so you still need to support both H1 and H2 and we are still exploring what best practice really means for H2. But for me it really brings the stack together. Are there any sort of more design and front-end developers in the room? A couple of folks up towards the back, wonderful. You still have a really, really crucial role to play in web performance because we need small resources, compressed images. There's a whole conversation around that that is critical to your participation in this. How many people here are front-end engineers and work with JavaScript? It's two hands up the back, awesome. You still have a really, really crucial role to play, minification, splitting up your front-end assets. Who here's more in network and infrastructure? Few more hands going up, wonderful. So you've still got a role to play. H2 needs support and various suppliers and vendors are bringing out that support day by day. It also changes the TCP model. So there's a couple of blogs that have come out in the last three months about the impact that's had for companies enabling H2. And who here's more an application developer? Quite a few more hands. Okay, you have a crucial role to play because you're designing these APIs and these endpoints and these interactions. So it's bringing the stack back together as developers and engineers where you can no longer say, oh, that's Ops's problem, catch. You've got to work together with H2. So what are we going to do about it? I've got this brand new technology that's going to enable so many awesome APIs and interactions. Well, 76% of browsers currently support H2 natively. This came from, can I use? It's an amazing tool to track feature uptake. Now, I messed with this number a little bit. It's actually 70% with complete compatibility and a further 6% of partial compatibility. So it might have H2 support, but it may not necessarily have something like Push. And that's the case for Nginx, for example, and it's a separate module in there. So same with clients. Now, who actually supports it? So you've got Cloudflare, you've got Max CDN, but also, as of three days ago, Cloudfront. So approximately 60 minutes ago, I logged into my Cloudfront distribution for developerjack.com and I enabled H2. And the propagation went out and it was updated and now this is my website. So we still have slow parts of the web. DNS took quite a while to look up, but I only need that once. The time to first bite was still quite large because I'm not pushing the content down the wire. However, subsequent calls was literally just waiting in a tiny resource. It wasn't this huge, big file waiting to download. This here was my style.css actually, I think. Really, really lightweight request. And you can actually see, and I did manage to copy it in in time, but you can see usually what happens with H2P1 is you'll make one request and then you'll make another request and another request and another request and it kind of cascades and blocks a bit. But with H2, you'll have one initial request over here and then they'll all cascade right next to each other. So if you load up developerjack.com in your browser, it does now support H2. And if you load up Google Chrome's developer tools, network tab, enable the network inspection, you'll see that cascading really quick requests. Now the interesting thing here is I actually got a reduction in my page speed metrics because I'm not properly using H2. It was changing the way I'm having that conversation. So there's still work for me to do. I can't just flick a switch. But that was my personal site. Others have experienced very different metrics. That's the measurement portion. So Simplr is a startup in Sydney and they enabled HTTP2 and found it was 400% faster across 500 page elements. Can I get a picture of hands? Who's familiar with web components and polymer? That's JavaScript. Okay, a few folks. For those of you that aren't, it's a brand new approach to JavaScript where instead of having your page and then jQuery.min.js, you've got individual small components. So the heading might be an element, the nav bar might be an element, the ad block might be an element and their individual components. Simplr is a startup whose goal is to replace the CMS. Completely change the way you model and build websites. So think of it as HTML5 content editable where you can click into the element, edit it, it makes the JavaScript calls to the sort of content store in the web and brings it back. And so you actually edit and build your web page exactly as it looks to a customer. But of course that has a huge overhead because you're no longer downloading one piece of JavaScript and one piece of content. You're downloading hundreds of pieces of content for your web page. Completely changes the way that that occurs. So they really depend on HTTP2 to have a viable business model. So they did some metrics. I bought them a whiskey and many, many coffees and they found that for their particular test, H1 was loaded in 42 seconds. I think you've probably lost more than 30% of your customers after 42 seconds. Now we were running a big metric to see how far we could push the technology. So we enabled H2 and got it down to 15 seconds. And then we added the CDN. We moved the cloud a little bit closer to the customer. There's your cloud, sir. And we found that the performance was down to nine seconds. Now it's not an ideal performance. There's a lot of work to do there. But we were pushing a large number of connections. So really trying to see where this technology goes. And in fact, this was the graph. Now there's a couple of anomalies as you can see. We were running this on local environments so we had other processes coming into play and locking things up. It's a bit of a drop off at the end there that we want to explore and what that actually was for H2. But overall, the blue line, which is H2, was much faster per more connections. So the more connections you have, the more performance H2 becomes. HTTP2 is a brand new way to think. It's binary, it's a completely new paradigm. It's a completely new way to architect your APIs and think about your resources. But we are still only just scratching the surface of what H2 can do for our applications and our clients. So there's the concept of a weight in a resource. There is no point in me pushing Comic Sans as a font before you've received index.html. That's useless. So we can prioritize certain streams, certain resources to be pushed down an H2 connection. Hpack, so it's a header compression, but we know there are security implications with other compression. So there's a write-up recently about an Hpack bomb where you can essentially compress something and design it in such a way that when it is unzipped, it's a huge multi-megabyte file. If you do that enough on enough connections, you can exhaust volumes of memory on the server. So there's still security implications that we need to explore. What else do I have here? Slow reads. So if you intentionally still read something slowly and accumulate a large volume of open connections, same as H1, still in H2. So there's still things we need to explore and how we do on a TCP level. And because we have these sort of dependency graphs on what resource to go first, especially when you're getting to push manifests and what resources mapped to where, you sort of get to this dependency cycle risk. So we still need to think about the way we model our communication. It's not just open slather, go performance things. WebSockets, who is using WebSockets in their application? Awesome. WebSockets still have a role to play. H2 is all about that initial load, that initial first conversation to get content to your client. WebSockets that are kept open over a long period of time are fantastic for that ongoing communication. Those sort of annoying chat pop-ups that irritate me on sales websites. So I want to challenge you. With every change you make, measure the impact. Go back to that 3M's approach. I want you to measure it. If you can take two things away from this talk, I'd like you to be the performance improvement you want to experience. Make it personal because you will immediately see the impact you have for your customers. And because it's HTTP2, because it's new and fun, I want you to try something new because we are all still learning. H2 is great fun and I've been making and breaking code with H2. So I want you to go and explore and then share what you learned back with the rest of us. Because without it, we can't grow HTTP2 as a community. My friends, that has been making the web fast with Jelly Snakes and Raspberry Twizzlers. You've been a wonderful audience. Thank you very much. We have a couple of minutes for questions. And I will try and answer them to my best of my ability. Great talk, thank you. Thank you. So I'm a big fan of REST APIs. As am I? Yeah, great. And I'm just wondering what are some of the implications for the people who are designing the REST APIs, which never touch a browser, for example, right? It's all just code that's talking to other code. Absolutely. So there's two key changes, I think, that we need to model and acknowledge as H2 moves forward as a technology. The first is understanding our clients. So for me at MYOB, I'm working with a community of about 4,000, a bit over that now, developers, who've come from years of working with relational databases on-prem, reach into ODBC drivers. And so it's an education factor. With our APIs, I can't just go use the API, off you go. There's an onboarding experience. There's a set of knowledge in the community you have to model. So we aren't rolling out HTTP2 tomorrow. Amazon only just got it into their stack. So you have to understand your developers' needs and how they are going to consume your content. The second is then how you model that content. So for example, let's take an invoice, for example. An invoice has all sorts of line items on it. But for an index of invoice resources, you don't necessarily want to push that down the pipe. From an accounting standpoint, there's a lot of background data to generate all of that. And so if that data is in memory, because you've had to calculate the total of the invoice for the index, our applications can become much more performant because we can push the full invoice resource down and not have to make that request in 50 milliseconds time from the database. So it's not just modeling the communication we have with our customers. It's modeling how we use data within our applications. And if we know the customer's going to want it, push it. Thank you. Yes? Hey, I'm really curious about this from the Django-E Python side of things. And I see that we've got Marcus in the room. And what I'm kind of wondering is, does H2 break WSGI? Like to take advantage of some of these push things, to take advantage of some of these multiplexing things, do we have to rethink how the Django, the Python code layer talks to the reverse proxy, the web server, the Nginx, the whatever? Good question. Short answer is I don't know. The slightly longer answer is, I don't know, let's find out over a WSGI. And the third answer there is, I suspect not because, for example, I come from a PHP background. I'll get to that. And it changes the way those languages interact with the web server as well. So especially on the memory management, you still got to make those requests. But Apache and Nginx handle the H2 conversation. So there might be small amounts that we need to do. Do we have an answer on the, does it break it? No, I can repeat back the answer. Because Apache will terminate the H2 connection and you have that clear separation with your web app through that WSGI API. There's nothing in the WSGI API about push. So you lose that ability. So yeah. Also, the other thing there is that the RFC doesn't say push has to be implemented. It's a May push. So as long as you know how to handle and ignore, which is how most clients can support it, you can use it then by the sounds of it. Was there another answer? Question, wonderful. Can you do the server push stuff with static pages? So I don't know, yeah. Yep, you absolutely can. However, it becomes a little bit more complicated. So we add a header and we say that this is a rel of preload and then the sort of middle agent such as your CDN can read those and then preload content. So there's a whole bunch you can do in headers about DNS prefetching and content preloading and things like that. You can send a header with your content and say yes preload style.css and then other parts of the stack implement that for you. So out of the box, no, but the stack does support it once you align your various chess pieces to make it happen. I can find some resources and we can have a chat about it over a WSGI. Wonderful. Do we have time for more questions? Just one. Just one more question. Wonderful. We're up the back here. Hi there. I've been doing a bit of... I've been doing a bit of performance and load testing with Locust and Python and so forth. Are there any implications in HTTP too for changing the strategies that we use for load testing? That's a really good question. I don't know. I've not delved into that much myself. I boil it back down to TCP. We're really talking about conversations, what transfers over that. It's up to your application. So TCP, keep that load testing happening. For HTTP, it's gonna depend on your application stack and how you're doing various scale operations. Let's find out. And when you do discover it, write a blog post, let me know and we can let the community know. Wonderful. Is that the last question? I have one more question. Very quickly, yes. Are you willing to take questions in the hallway track? I absolutely am. I'm also happy to take them on Twitter. Okay, cause that's all the time we have. Thank you very much. Let's say thank you again. Thank you very much. Thank you.