 I was going to start by telling you that smaller is quite clearly always better by proof of dogs. We've seen some people's pets and pictures up on stage, but you haven't seen mine yet. This is my dog. She is a miniature dachshund in large at this point, but really she's about so big and she's adorable and she's named Ruby. Not after the language, it was actually my girlfriend's choice, but a funny story came out of that and asked me about it later. Ruby is the best dog in the world, demonstrably. Here she is tucked up in bed and she's tiny, therefore smaller is always better. So now we've got that sorted. My name is Sonash and I am a developer evangelist from Twilio. Who here has heard of Twilio at all before? Quite a few, that's cool to see. For those of you who haven't, Twilio is a communications platform. That means we have a whole bunch of APIs that you can use in your applications to do things like send and receive text messages, make or receive phone calls, start video chats, regular chats, and emails, and even facts if you need to. Some people still need to, don't worry. If you have built something cool with Twilio, come find me afterwards, I'll be in red. Or if you have any questions, if you want to know more, just come and chat. I'm happy to chat to anyone. Let's talk about making things smaller. And I'm going to start, I was really pleased, actually, to see in Piotr's talk yesterday, this quote, you know, speed in software is probably the most valuable, least valued asset. It's a great quote. It means such a lot. Now, obviously, Piotr was talking about, like, very much at the code level and very deep into the programs that we write. But I joined the development industry from the front end. I started out as a front-end developer and worked my way into Rails and Ruby and the rest of the stack. And so I've always been very interested in and focused on web performance. Because that is the first indication of speed that your users will ever come to. If they just see a loading symbol or a white page, not your website, then they are going to be sad. And that's what makes me sad, seeing anything that looks a little bit like this. And waiting. Just under two years ago, I moved to Australia. I thought it's a wonderful country, but it has some of the worst internet in the world, and I see this quite a lot. Ask any of the other Australians in here about our internet. It's shocking. So I see this a lot. And so it matters to me making things fast, making things get to people's browsers, get to their eyeballs quicker. And so there are a bunch of tools out there in order to measure your web performance. And one I like using is Lighthouse. It's built into Chrome. It's built into web page test. It's there for you to use. And this is what it looks like run against, say, the Ruby website. And it's quite cool. It gives you a few scores just up the top there in performance and accessibility and best practices and SEO and whether you have a progressive web app. And it's really useful. And I like to run this against my own site once in a while. And as a developer evangelist I don't actually have any kind of production applications running right now aside from my own blog. And so I'm going to make this blog the fastest thing you can ever see on the internet. That seems reasonable, right? So I ran Lighthouse against it one time. And this is kind of where the story came across. I ran Lighthouse and these were the scores I got. Yes, 100 for SEO. 100 for best practices. 100 for accessibility. 100 for progressive web app. And 99 for performance. I was devastated. I'd actually been okay if it had been like 40 for performance. I'd be like, oh, I've got some work to do here. But 99, it was playing with me. And I already did a lot of work to make this fast. It's HTML. There's very little JavaScript involved. The CSS is actually bundled up inside the head. So you don't even have to download another file for it. So I don't have this old simple thing for me that has been reserved over HTTP quantify all the assets that can get jumped to the browser as soon as possible alongside each other. What could I be doing that didn't get me a hundred? Because everybody wants 100. I wanted it across the board. And so this got me thinking, what am I missing out on? Perhaps the site is just too big. So let's talk about Gzip. Gzip has been around for ages. It's our compression format of choice voice for text content on the web. And it works. But does it work well enough? It's a question I have for you. So all browsers these days pretty much send this header to your website, saying, except encoding gzip, and it says, hey, if you send me a compressed file back, I will decompress it for you. Thank you very much. And we can do that. And so we set up our files, our sites to send compressed text content. This is what my engine x config looks like. I have over-engineered my blog, by the way. It is a statically generated Jekyll site served on a digital ocean droplet with custom engine x front end on it and then a CDN to serve it out to the world. But the important thing is, gzip is on. But is that good enough? It got me thinking. In fact, I had heard a bunch of things about gzip and how it can be made such that, well, so this engine x config gzip on actually makes engine x itself, zip up the content and send it. So it's doing this compression on the fly. And that's what got me thinking. Engine x is doing work for me here. It's taking time. Perhaps that's my one. That time. And so as a over-engineering, personal blog owning Ruby developer, it was time to write a new gem. Of course. So I wrote the jekyll gzip gem, which taught me a bunch about how to zip up files in Ruby, in fact. And not only that, indeed how to write a jekyll plugin as well. There's five different ways to write a jekyll plugin. My favorite are the hooks, because you can just reach into the site as it's being built and do something about it. So in this case, after the site has been completely written to disk, I then take the whole site and put it into the jekyll gzip compressor. And then for each file in the site, we compress it. And to compress it, this is it. This is all we have to do. Because the zlib library is built into Ruby's standard library and allows us to just open a gzip writer and write that file out to disk much smaller. You can see here, actually, we also set the modified time and the original name of the file. This is to make engine x happy. Apparently, it doesn't like it if they are different to each file. But the important thing on this is not only that we're doing it at build time for the site, but this little line here, oh, yeah, we're going to use the best compression. You see, zlib has nine levels of compression to turn a text file into a gzip file. Nine levels. Actually, it has ten, but zero is don't. One is the quickest, nine is the slowest, but one is the least compression, and nine is the most compression. Zlib best compression there is just a shortcut for nine. And so I wanted to compare this. I wanted to see how we are going to do if we stop this on the fly default level compression that engine x was doing. Default level is six. And we used the best compression and we did it ahead of time. So I picked a file that I thought would be interesting to compress and see what happened with, and I picked jQuery. Why not? Uncompressed and unminified jQuery is 271,751 bytes. But if we compress that with gzip by default, we bring it down to 80,669, a reduction of 70.32%. Now, that is pretty good. But is it the smallest? No, obviously. Gzip turned up to nine, sorry, zlib turned up to nine, compressing it. We bring it all the way down to 80,268. A solid win of 400 bytes there. All right, so I was a little disappointed with this. And you know, that obviously changes by the file and the size of the file you are compressing and all things like that. But in this particular test, we made it smaller. And you know smaller is always better. We are sending less bytes over the wire. We are going to get there quicker. In the thousands and millions of page views I send, I will save myself so much bandwidth. Smaller is clearly better. But could we do better than that? You see, zlib has been around for a long time. And whilst it is very efficient at zipping files up, making them smaller, it's not the best at making them the smallest. And getting involved in this a number of years back, we are a couple of Google engineers who were trying to make compression better for Google. Which seems reasonable. They have quite a bit more traffic than I do. And so they invented, it was a new algorithm to take text files and turn them into gzip format, but smaller. They invented Zopphly. I hope you might have heard of it before. It came out in February of 2013. And Zopphly is brilliant. It conforms to the same format that zlib does. It writes to the same kind of file. And that means in your browser nothing has to change. It's still able to re-expand, to reflate those files. The problem with Zopphly is it's 80 times slower than zlib. But it can make the files three to 8% smaller. So as an over-engineering owner of a statically generated site that had a little bit of time on my hands, it is a gem time. Thankfully, this one was quite a lot of copying and pasting. Because everything was the same except for this bit. Because there is, of course, already a gem out there for Zopphly itself. It wraps the C extension. Or wraps the C library. And does almost exactly the same. It actually can provide gzip or deflate formats. So I put it into gzip. And it looks exactly the same. And I bet you're wondering what are the results? The important thing, of course, is that Zopphly is 80 times slower than zlib. But it doesn't matter. Because this is done at build time for the site. You can't put Zopphly into nginx and say do this on the fly because you'll waste much more time on the compression than you will saving it over the wire. But you're probably wondering what does this look like when you compress jQuery? Well, remember we saved ourselves a good 0.08% when we turned up zlib. Well, turning it to Zopphly, we got ourselves down to 76,352 bytes. Not bad. Another 1.5% saving. Not as much as I thought it would be. Which is pretty much the theme of this talk. But it's good. Zopphly is getting better. And because we can do it ahead of time, it doesn't cost us anything at the time of actually requesting a page or requesting an asset. We've made the file smaller. And smaller is always better. You've seen the pictures of the dog, you know. But was that also having implemented this? It was then important to actually tell nginx about it for myself. Of course, if you're using Apache or any other kind of server, you can do this as well. This is just my experience. Turning gzip off meant this would now stop nginx doing any work to try and zip things up. And then there's an extension to serve gzip static. And so if you saw in the code what we did was create a file that just has a .gz extension on it. And gzip static for nginx will look for that. And if it's there, serve that instead. Smaller, it's better. But was that enough? Still probably not. And it wasn't just for me. Those same engineers that worked on Zopfly to improve the compression for Google, they did everything they could to wring everything out of the performance of gzip and its format. But in doing so, I think they discovered ways to do it better. And so later in 2013, they actually released an entirely new compression format and library to do that compression, which is Brotly. I really like the names of this, actually. Brotly just means small bread. I don't know why bread. Maybe they were hungry when they were rating these, but they released Brotly. Brotly is an entirely new format, a new file. And so now, if a browser sends you the accepting coding header with br, you can serve Brotly back to it. Of course, in 2013, there weren't any browsers sending this, but we're in 2019 now. And so making things smaller and sending them to those browsers is possible. That's why it's important to think about it and keep talking about it. Because this is today's support for Brotly and browsers. Pretty much across the board. Your redlarks there are i.e. Opera Mini and BlackBerry. I don't know why they still show BlackBerry browser on there. I don't know anybody using it anymore. But Brotly is basically available across the board. So we have this better compression format and a smaller file size that we can send. There is one caveat. You can't use Brotly in a browser unless you're serving your website over HTTPS. Whole bunches of new web features require you to have HTTPS these days. And with the existence of fantastic tools like Let's Encrypt, we should all be endeavoring to move our sites to secure to HTTPS. So that we can take advantage of these things. Also, HTTB2 doesn't work without HTTPS. So it's kind of no-brainer to secure your website with that. So, of course, we have this Brotly and I've got these other GZIP things. It was obviously new gem time. I've been over-engineering this so much. Why not have another gem? So in comes Jekyll Brotly. This is great because it does the same thing as all the other things except we have the Brotly library in there instead. And one more. Of course, what does JQuery do with it? Well, when we compress unminified JQuery with Brotly at level six, we get it down to a almost disappointingly 75,302 bytes. Another point, there's a third of a percent. But that's quality six. That's the default. The best thing about Brotly, I really hope the developers of this were thinking about Spinal Tap at the time, is that they put in 11 different levels. And so, obviously, because we're doing this ahead of time, it doesn't matter how long it takes. I wanted to turn it up to 11. And we can do that with the quality parameter just over there. It's cool. Turning up to 11 brings it in at 66,920. We've added another 3% on top of classic Brotly and another 5% on top of regular GZIP. Oh, I've saved so many bytes. 14,000 almost in total. That's a window. That's a frame size in HTTP, isn't it? Pretty exciting, right? So as part of the description for this talk, I also said how I got into a fight with a CDN. You see what happened was, I did all this work. It's not a lot of code. There was more work in writing a testing framework for it. I did all this work, and I wanted to test whether it was going to improve things. And so, before I actually implemented Jekyll Brotly into my site and deployed it and changed Nginx to serve it, I wanted to go and see what my site was already... what was already returning and see how much better I was going to be. And I opened up the browser and I checked in the network panel and I was already sending Brotly encoded files, which was a surprise to me and probably something I should have checked hours, days, weeks before I started on this. You see, it turned out, as I said earlier, I was using a CDN to serve this site and CDNs, of course, are brilliantly put your files all around the Internet so they can be closer to your users as they want to request them so that your site is no longer limited by the speed of light. I use Cloudflare for mine. It's free for your personal science and things like that, and I think it's great. And it turned out they were already doing the Brotly encoding for me, which, you know, it's kind of cool to them, right? I didn't have to think about this. I mean, they are doing it on the fly and they're not using quality 11. So I thought, now they're getting in my way. They're breaking my utterly minified tiny little site and doing it themselves. And so when I say we got into a fight, it was really kind of a fight. I raised a ticket to say, hey, can I serve my own Brotly things? It turns out what they do, actually, is strip the accepting coding header out of the original request and get it to Gzip. So admittedly, in turning on my Zopli integration, I was sending smaller Gzip files over to Cloudflare, but I could never serve them Brotly. My minified quality 11 Brotly. And I could have got mad about this. I could have gone on the internet, but I decided not to. I decided to submit a talk about it instead. They're not doing wrong. They're actually doing very well in fact, providing Brotly for everybody that serves via the CDN is a great idea. And there are other CDNs out there that will not strip the accepting coding header and will allow you to serve up your own files. And so maybe I should just, if I really care about it, move to that. But in my mind, it was a fight and I lost. So there's some takeaways from this. I still believe that smaller things are always better. And making things smaller shouldn't be something you have to think about. And so if you have a Jekyll site that you're hosting and you want to use any of these gems, they exist up there. They are also useful if you happen to, if you have a Jekyll site which you host on, say Amazon S3, which can serve Gzip files for you. So if you just zip them all up with Jekyll's OpFly, then they'll be the smallest possible files that AWS will serve for you, which is pretty cool. Do you think maybe I have a Rails application? What can we do about that? So if you have a Jekyll site or anything that is sprockets-based, it actually already supports generating files with the ZopFly if you want to. So if you, in your Rails 5 application, include the ZopFly gem, and then in your application config set assets.jizip to ZopFly, it will just use ZopFly instead and it will all be amazing. There's not actually a lot for Brotli out there to do it, but these sprockets-exporters pack will pre-render Brotli files for you as well, giving you that ability to serve up the smallest site you can, the smallest assets, at least, in as you can. Rails 6, of course, is now Webpacker by default and the JavaScript community, as we spoke earlier. I spend time in JavaScript as well and the ZopFly and Brotli Webpack plugins are just right there and ready to help you out in this case with almost minimal configuration. JavaScript land is not quite the convention over configuration world that the Ruby one is, but with a small amount of config we can achieve the same thing. There's one more thing. I've spoken all of this time about text files, but of course they're not the biggest thing that we serve as part of our Web applications. Constantly, images are the greatest one. I just wanted to throw this in at the end because it's not released yet or anything, but much the same as Google spent all that time working on compressing text files smaller, they've also produced better image formats since. And the one that has taken hold across the web has been WebP. It's brilliant because it supports both lossless and lossy compression animation, so it's JPEG, PNG, and GIF all in one and smaller than any of them. So it's not quite new gem time yet, I haven't got this quite figured out. It's working on my site, but we can actually go and take all the images from a Jekyll site or if you were to do Rails you could do this the same and encode them to WebP. And like I said there's a difference between lossy and lossless, in this case if the extension's PNG we can encode it with the lossless settings and at the top quality because it's lossless we can make it as small as possible. And if it's a JPEG or a GIF then we can pick a quality very similar to JPEG qualities. This does work on my site, the only problem is that every time I run the site it does all of the images so it takes about 20 minutes for me to build my site right now which is why I haven't released this yet. But we'll get there. There's some new caching stuff in Jekyll 4 which just came out so I'll be looking into how to make that actually workable for anybody. But being able to do this and then of course serving the images now we have a JPEG and PNG and a WebP version of all the images and so my engine settings need a bit of an update more complicated than just GZip on and GZip static on. In this particular case we actually create a variable based on whether the accept HTTP accept header includes WebP if it does add to this WebP suffix to the HTTP accept no sorry add WebP to the WebP suffix variable and then for all my assets there we just try to see if that exists otherwise fall back to the existing image otherwise fall back to 404 it actually works quite nicely until somebody tries to download one of your images because it's only browsers that actually show WebP images they download it to their operating system and the OS is like I don't know what this is but it works really well for the Web and it makes things smaller and as I said smaller is always better I wanted to actually finally finish the results of my work on my entire site itself did it make it quicker did it pass the did it pass lighthouses tests well firstly I wanted to do the table of compression this time against all text files on my website uncompressed it's apparently 1.8 meg which almost surprised me it's apparently I've been writing blog posts using Jekyll's OpFly we brought that down to just over 500,000 bytes which I thought was pretty good 72% reduction for the whole thing it's amazing and then using Brotly very much less I think I've done something wrong here I'm a little bit concerned there is one thing where particularly small files can actually increase in size if you use Brotly so it's a good idea not to compress everything and maybe throw some sort of threshold in front of that and that's something to add to the gem similarly if it's not compressed it by enough then it's probably worth not compressing as well because the work to decompress it will also make it slower even though it's very fast and optimized and then I checked Lighthouse I was like I must have done this now did I get that extra one no not at the time anyway and I wanted to I wanted to close by switching over to Chrome and this is my website right here and this is Lighthouse here in the Audits tab on Chrome in Chrome DevTools and it's going to audit my site right now and let's see what we get it's got to 100 now and I didn't change anything so performance tools can be interesting, can be flaky, can give you weird results but there's nothing there's nothing you can do wrong if you're making your file smaller and serving them to your people quicker there are easy ways to do it in Ruby and I just want you to remember that yes, smaller is indeed always better and just to finish with one final proof about how tiny dogs are always better here's my dog pretending to be a large prawn so that's it my name's Phil Nash, I am here for the rest of the day loving being in Bangkok as I said I work for Twilio come and ask me about that and otherwise enjoy the rest of the conference and thank you very much