 All right, so let's get started. I'm Ben. A little while ago, I started a side project, which was a Twitter account called the Practical Dev, where I told jokes and shared programming links that I thought were interesting and people could sort of come back and find resources every day. And in the process, I really started to realize that so many websites were bulky and slow and crappy, and I was sharing links every day and every single site was different and the content was in a different place and the title was in a different place and everyone had their own custom web fonts. And I really just wanted everyone to use a website that could at least just load quickly on my phone. And since I was in the sort of business of sharing a lot of links, I really got into the idea that I need to sort of make a platform just for my own purposes. It was a side project. And it was really just about sharing sort of programming resources as well as I could. So Dev2 is a place where software developers can read, write, share about programming, leave comments, take part in discussions. Just a place where you're going to not be bogged down by sort of the hectic nature of software development on the web or other platforms like Medium, where you kind of have to sift through to find the good stuff. We try to just be a place where people can find relevant content and sort of engage with community and sort of learn how to be a software developer along the way. Before we get started, I'll caution you that there might be small numbers here. If you work at Twitter or Google or something, you might think that the numbers that we talk about as going viral are numbers you could expect every single second on your platform. But when you're a small company trying to make it in the world, some of these things are a big deal. This was sort of a bigger story than any sort of Reddit or Hacker News hit, but it wasn't so big like we became the next great social media platform. And I'll also say that going viral really isn't a good business strategy. I've been involved in companies that really wanted to bank on this kind of thing. And what made this whole project so special is that it was really just a matter of actually trying to make a good product. And a group of people were so into it that they really got excited and shared it wildly across the web. Without that, I really wouldn't have all been worth it. So let's set the scene. It was November 15th, 2017. It was 10 p.m. in New York. We have this thing on our Twitter account called Dev Discuss. We do every night at nine Eastern. So this is kind of what I was up to. This was what sort of made it memorable, that date. I was minding my own business. It was 10 p.m. I was getting ready to go to bed, put on my PJs. As anyone who's built websites before, check Google Analytics just before I went to bed, or what I always do on my phone, whatever, I have a free moment. And it was 10 o'clock, so I expected numbers to be sort of going to sleep for the night in general, but they weren't. They were sort of climbing a lot. So I noticed the numbers started to creep up. Like, wow, this is a lot for 10 p.m. And then this is a lot for ever. And then this kept growing and growing and growing. And we just kind of had a massive influx of traffic, almost all from Japan. So the first instinct is that it's probably bots or some sort of spam network or something. You just never sort of trust success this way. So in a couple of days, it had a long tail where we had a lot of people stick around and stuff, but over the two days where it was most popular, we had about a million page views from Japan. Which is just a lot of individual developers. And it was developers. They were signing up. They were creating content. They were engaging in discussions. It really forced us to sort of improve some of our language features, because a lot of people were writing in Japanese now, more so than they had been. And it was really just exciting. Because it was 10 p.m. when all of this started, I didn't really get a lot of sleep, because I was really confused and just trying to track it over the night. So time to investigate. Why were all these people coming to our website? We still didn't have the answers. I went to bed really with no clue as to why we were getting all this traffic. It just didn't really make any sense. Usually we can kind of track these things. And a lot of it was actually just direct traffic. It wasn't even referrals. So it really was just a big mystery. It turned out it really was sort of a viral story. A few influencers in Japan started talking about, hey, this website dev2 is remarkably fast. And you should check it out. And then it cut and became a thing. It wasn't a few big stories or a link aggregator or something. It was a lot of people talking about web performance and relating back to us. And even now, we've come across some forums which seem to be using dev2 as the benchmark for what a fast website is. So it's even kind of stayed in the mainstream discussion in the broader Japanese dev landscape. And I think a lot of the direct traffic was because at the time Twitter didn't turn dev2 into a link automatically. So I think a lot of people were just taking it off the tweet and putting it into the URL. So it was harder to kind of tell where the traffic was coming from except the geographic nature of it. But so the real question is, what's so special about a fast website? Aren't all websites pretty fast? And why Japan? So the Japan part is important because the Pacific Ocean is really big. And that's kind of where sort of the nature of performance on the web has to come from. You have to sort of respect the distance between things before you can kind of even get started with some of this stuff. So the reason is you can't change the speed of light. So every time I send a bit or a byte or a pixel or any sort of information over the web, it has to travel back and forth a few times for different handshakes and everything. And every single time, you have to go all the distance. And the speed of light is a universal constraint in software development. All of this is called latency. So it's a time interval between a request and a response. So every time someone from Tokyo requests a website that's hosted at some data center in Utah or at US East One on AWS or anything like that, they're going to make this whole trip across the world. And then every JavaScript file, every CSS file, every custom font, et cetera. It's a lot of trips back and forth, and this just takes time. And especially in the worst case scenario. So best case scenario, you're doing all right. Worst case scenario is that one of these files that's going to have to be requested before anyone can even start reading or start interacting at all might hang or might take a while. And you're really as strong as your weakest link in this case. So there's a lot of issues with latency. And overcoming this is especially a big deal when you have such geographic distance in play. So let's look at the data. An average web page on 3G is about 19 seconds load. 4G is 14. So these are really terrible network conditions. And it's not sort of our typical thing. We still expect websites to load in under a second or maybe a second or two. But you'd be sort of amazed how many people still use inconsistent networks across the world. And even in most of America, the network conditions are pretty bad. And people will leave a site in about three seconds. And even if the data sort of changes over time, I think this was from about a year or two ago that I found this information. But fundamentally, this is not changing very quickly. And we're still very resource constrained on the web. The average web page is now larger than Doom, which was a story that came out a few years ago. So every time I go to a web page, even a lot of simple blogs, I'm downloading a first person shooter, a 3D first person shooter with levels and points and scores and stuff every single time. Because we load a lot of really bulky CSS, a lot of heavy JavaScript libraries, a lot of huge, bulky dependencies. And as we talked about, we have inconsistent networks that are already struggling to send the data across the world in time. And we're not doing it any favors by adding a ton of information that has to go on every single request. So web performance really is about inclusivity. If you want to make a website that's going to be accessible across the whole world, you want to make it fast. You want to make it not too resource intensive. You really want to make it work for everybody. And this is a part of progressive enhancement at its core. If we make our websites swift and quick, they're going to work for everybody. There's a lot of cultural things that go into broad international inclusivity, but there's a lot of fundamental technical considerations, too. And this project was really about examining a lot of that as well. It's also a big opportunity. A lot of sites do not take care of this problem really well. There was a really famous article talking about a YouTube enhancement that Google tried really hard to make. They were working on it for a few months. And when it went live, their performance actually dropped considerably. And they had to find out why this happened, why after all these enhancements, all this progress is performing so much worse. And it was because a lot of users in parts of Africa could actually use YouTube for the first time ever. So without even realizing it as a really popular startup that had already been acquired by Google, they still didn't realize just how poor their product was across the world. So with stores like this, we really just wanted to start at the basic fundamentals. So let's start with a product that just really works well across the whole world, even if it's just a simple website, because you cannot take for granted that these products do work well across the world. Even really popular blogging platforms like Medium send a lot of information over the wire on every page request. And it's just not always great for all users. And really the web is supposed to feel instant. This is something I've always felt was important. If it's not really magical, what's the point? We try really hard for these things. And if we can't say no to a few features in exchange for just the fundamental experience feeling like snappy, instant, and awesome, it really, I just feel like it's really just not really worth doing anymore if you're not doing that. So what did we do to do this the right way or a good way? So what did it take? So first of all, you really want to CDN all the things. So a CDN is a content distribution network which takes our pixels, our pages, and distributes them to nodes all across the world. So if I'm in Tokyo, I actually request the content directly from a node in Tokyo or somewhere else in Japan. As you can see on this map, some of the major internet centers are covered. And as we grow and the world gets covered more by internet, it's going to be a more covered map. So I believe this is a Cloudflare map. This is actually not the CDN we use. We use Fastly. It's been really good. There's Cloudfront. There's Cloudflare. There's a few other great services. And they're really fundamental to our architecture. And a lot of people know CDNs in terms of static assets, like JavaScript and CSS and web fonts, et cetera. But we actually architected so every single page request gets delivered from the edge, from the CDN. So that first initial request you make is actually being downloaded directly from the CDN. So I don't even leave the city most of the time if I'm in a popular place. And I probably will never leave the country no matter where I am to get the whole web experience. And we actually shipped the entire experience to start using and reading the page in ideally less than 14 kilobytes, which is about the size of a TCP packet. We don't really sort of, it's not really a hard constraint, but it's a nice ideal to have. So let's see what we do in Rails. So we use Fastly. It really plugs right into Rails. And a lot of this is really important that we just keep it within Rails best practices. We don't try to make it this whole new thing or take all these radical changes to make it happen. So set cache control headers. This is just a screenshot from our code. It means that we're just going to cache the page at the highest possible level. Basically the exact same API is an action cache, the action cache API, a page caching in Rails. It really fits into any sort of your conceptual mindset of Russian doll caching in Rails. And a lot of these concepts are useful in any framework, but in Rails it's really easy because we're really familiar with these kind of caching techniques already. So what's next after that? After we send the whole website over from the closest possible node, what are we going to do next? So the next thing is that we want to reduce render blocking resources. And in our case we have zero render blocking resources after the first data is sent over the wire. So here's a couple screenshots of, sorry, of our site compared to Mashable.com here. So in 143 milliseconds under bad network conditions which are simulated here, you're reading the whole page. So 143 milliseconds under bad 3G, you're done, you're all set to go, you're reading. Below here we have at 5.3 seconds you have like a little bit you can see. At six seconds you're starting to see like the frame of the site and actually this whole graph doesn't even really get to readable content even after nine seconds and it goes way off the page. So it almost sort of never comes home. And a lot of this is render blocking resources. So that page, even though it's basically the same website, it's just content you read on the internet and it's actually less interactive than our site, it's just a news site. Just does not respect your experience on a bad network or really sort of think about resources at all. And I picked Mashable because I just noticed they really suck but there's a lot of websites that really, really do this badly. And the thing is it's not the developers who really have the issue. A lot of developers in the room really want to fight for these things. It's about the organization really thinking of this as something that matters and having the coordination and the communication across your whole organization to make sure that you can say no to things and actually focus on the experience. So in terms of reducing render blocking latency, we use async and defer on all JavaScript tags. But this means that you can't sort of rely on setting the framework of the page with JavaScript. You sort of have to acknowledge that the JavaScript comes in after the fact so you have to know that you wanna send this sort of basic framework of the page without JavaScript. We inline all critical paths CSS. And this is kind of like an old school technique in a way. People have been talking about it for a while and maybe they say you should sort of move off of it. But in our opinion, in terms of just sort of making a stable, awesome, fast website, it's still a really great technique. We async load all the other CSS, so any CSS you might need sort of after that first second comes in after the fact. And this can be loaded over JavaScript and there's no sort of native way to do this, but it's pretty easy to do just with some JavaScript logic. And we async load actually all the user data. So if you're logged into the site, you actually still just get the I'm logged in version of the site where we differentiate logged in or not logged in at the edge at the CDN level. But all additional data about who you are and what you're sort of doing on the site is loaded asynchronously. And we keep some of that basic information like your profile picture or your name cached sort of in your browser, so at that layer. And then asynchronously we fetch sort of the updated version. So that has the possibility of taking up to the like, full second it might take to cross the Pacific Ocean and back, but everybody gets the initial reading experience no matter where they are in the world. And I'll also say that there's a few ways to sort of do custom user data and stuff like that at the CDN layer by other means, but in terms of absolutely making it the fastest possible and never sort of dipping into sort of bad situations, async is a really great way to go here. So let's see it in Rails. So here we have the Rails include tags so like our base sort of CSS or a base JavaScript here is has the defer tag. So in HTML that'll be like defer is true. And async and defer are two sort of similar options here. They have similar functionality, but slightly different. Differ ensures that all the HTML is loaded and async actually just means that we let the HTML start to load and then we start fetching. The difference here is that because we weren't really using like the jQuery like dom.load sort of situation, if we use async we sometimes got some like some race conditions where like a page with like a lot of comments on it. Some of the bottom comments sort of wouldn't be triggered in the events and stuff. So defer for us is a slightly better, like an easier logical way to do this. It also ensures that the JavaScript files are loaded one after another synchronously. But all the page doesn't, nothing blocks rendering. So no matter how long the JavaScript takes to load, the page is still readable. And then here we have the actual, some of the styles which are in line. It's just kind of a random snippet of a certain page. And it could be done cleaner or differently or whatever. But basically we get to still use any sort of general asset pipeline or any sort of Rails techniques we want here. As far as you sort of know, you're just basically doing CSS for Rails. But then we have to just realize that we're gonna in line some of these assets sort of as we go. So that's kind of almost a configuration layer consideration. And we cache all this, so we don't have to sort of recompute all this stuff. They'll tell you not to do this. Sort of if you go to a Rails thing, like don't call CSS this way. But the big thing is that it's computationally intensive but we just make sure that this as well gets cached on every request. Sort of Russian to all styles. So this is gonna be like a page cache thing. Not good with Rails words. So I'm gonna say maybe use a lot of these modern browsing browser features. This is all stuff we do use but we actually started not using this stuff. We started the basics of sort of the fundamental sort of reduced latency. Let's make sure this works on every device around the world. Let's not really trust the client to like have every API set up or really like send all of our code sort of over the web and have to debug on the client a lot. So like let's just send a website that works and once we've done that pretty well and this was just like my own personal project. So this was just me being like I don't wanna debug JavaScript. I don't wanna have to worry about all these new APIs at first. But now we do have all this stuff I just wanna say like in a lot of performance oriented talks a lot of people say like the only way to do performance or like the way to do performance is all these new things you can do but it's really the old stuff that makes it possible in the first place and these new things are great on top. So we use service workers to actually cache certain resources some pages offline and even sort of permanently cache some things that you might get every time and we're actually architecting our site so that the initial framework is actually cache right on your browser and little things from there but it really isn't something you wanna rely on because if your site say gets a lot of traffic from Google or Twitter or Reddit or anything where people are gonna find your site for the first time very few of these techniques do any good on sort of cold starts and those are a lot more common than I think sometimes we realize you're just gonna wanna actually provide a good experience in every case and not just the cases where every resource is already cached and everything's already great so we use very little JavaScript we send all the CSS over the wire everything's async we try to make it really good in every condition. HTTP2 has a lot of sort of new features as well and sort of we use that too like at our CDN layer we don't really think about it a lot but FACI sort of does everything through HTTP2 so does our image CDN and et cetera. WebP is an image format that works really well on Chrome it doesn't work on other browsers we do use it through our image CDN who automatically determines what the best what the best type of image to show is so we did a lot of optimization here but we didn't like worry about handling this all ourselves we just chose some good partners who provided some good work here but really modern browsing techniques are not what's gonna make this awesome it's really a lot of work and a lot of understanding about just all the different reasons someone might actually come to your website for the first time all the different network conditions they might be experiencing your site on and just what the point of your site is if it's really about the open web about being accessed from other sites you're really gonna wanna just go to the basics and you're really gonna wanna embrace constraints as I talked about we have a we asynchronous load user data we do some things where we just sort of can't do every feature easily because we try so hard to make that core feature of just reading an article so basic and so simple and so useful so you gotta just say no to things or just take your time to figure out sort of like what you wanna do I think it's a really nice constraint to have you know we don't wanna leave the city to get this website back so we're gonna sort of build with that in mind we're gonna say no to certain things certain sort of authentication tactics that might be easy but not sort of ideal and really there are no silver bullets this isn't gonna sort of work for everybody it's a lot of hard work it's a lot about just sort of getting your team on board getting people excited about this stuff I think if you go back to your team and try to start implementing everything right away or anything like that it's gonna be hard you're gonna wanna sort of make the business case for everybody so tell people how it can save them money how people are gonna leave their site if they don't do this but really understand that people are gonna have irrational reasons for doing this stuff or not doing this stuff and you're gonna have to communicate it all pretty well and of course write code for humans as we showed the Rails examples like we wanna do this the Rails way or the whatever framework you're using we wanna use its its styles, its conventions and we ultimately don't wanna make a site or an app so optimized that you can't possibly sort of actually extend it or code with it and just sort of be reasonable with all this understand that like maybe this isn't the right idea that approach should take maybe it's not important that people sort of get a brand new people with a brand new page get it sort of ideally perfect this way there's a lot of like popular marketing frameworks like A-B testing stuff which will just destroy all of your hard work in this area because they basically they'll show a blank screen while like a huge library gets loaded but it's worth like if you do care about performance it's worth knowing that that is just crushing your performance but you know your marketing team might have a really good reason for doing that and no evidence that it doesn't work and stuff like that so like you know you can't be can't be unreasonable about these things so that's my talk I like to do things fast so I've still got a few minutes for questions while you're here I'd recommend this book High Performance Browser Networking by Ilya Grigorik this is where I sort of like feel like I really got into a lot of this stuff he talks a lot about these concepts and that's really where I I got so excited about all these things if you want to create a Dev2 account it's highly recommended we're a great community lots of really great technical content and just sort of answers about everything you might want to do and we're growing pretty fast there's about 70,000 developers on the platform right now and it's really become a fun big project and it's our full-time job now and also this is a link this Bitly link is a link to a form to let me know that you are interested in being part of the open source project so we're going to open source our whole code base we're like sort of in the process of just working towards that and if you're interested in helping out along the way because we'd love to sort of make our our Rails app our all the work we've done sort of open because we are a network of developers so we're really excited about the idea that folks who are on the site or in the community can actually just contribute back and possibly stand up their own instance of this site in the future if they really want to but we're going to take our time but here's a link if you're interested so I'll open it up to questions if anybody wants to pick my brain about anything and if not I'll thank everyone for coming thanks so much for being here