00:00:10.670
All right, so let's get started. I'm Ben. A while ago, I started a side project that was a Twitter account called 'The Practical Dev,' where I told jokes and shared programming links that I thought were interesting. This allowed people to come back and find resources every day. In the process, I really started to realize that many websites were bulky, slow, and just not user-friendly. I was sharing links daily, but every single site was different—the content was in various places, and titles were in different spots. Everyone had their own custom web fonts. I just wanted everyone to use a website that could load quickly on my phone. Since I was in the business of sharing a lot of links, I became increasingly interested in creating a platform for my own purposes. It was a side project focused on sharing programming resources.
00:01:20.040
So, Dev.to is a place where software developers can read, write, and share about programming. They can leave comments, participate in discussions, and it's a place where you won't be bogged down by the hectic nature of software development on the web. Unlike platforms like Medium, where you have to sift through content to find the good stuff, we strive to be a space where people can find relevant content, engage with the community, and learn how to be software developers along the way.
00:01:44.850
Before we get started, I want to caution you that there might be different numbers mentioned here. If you work at Twitter or Google, you might think that the numbers we discuss as going viral are trivial compared to what you could expect every second on your platform. But when you're a small company trying to make it in the world, these numbers can be a big deal. What made this whole project special was that a group of people was so passionate about it that they shared it widely across the web. It's crucial to note that going viral is not a solid business strategy. I've been involved with companies that wanted to bank on this kind of exposure, but what made this project unique was our focus on striving to create a good product.
00:03:13.030
Let's set the scene: it was November 15th, 2017, at 10:00 p.m. in New York. We had this event on our Twitter account called #DevDiscuss, which we host every night at 9:00 Eastern. I was minding my own business, getting ready to go to bed, and like anyone who has built websites before, I checked Google Analytics before heading off to sleep. I expected the numbers to be quiet for the night, but instead, they were actually climbing significantly.
00:04:32.920
I noticed the numbers starting to creep up. Wow, this is a lot for 10 p.m., and then it just kept growing and growing. We experienced a massive influx of traffic, almost all from Japan. My first instinct was to think it was probably bots or some spam network; you never expect success to come this way. Over the two days of peak traffic, we had about a million page views from Japan, which was an impressive number of individual developers engaging with the platform. They were signing up, creating content, and joining discussions. This surge forced us to improve our language features to better accommodate Japanese readers, and it felt so exciting to see the interest grow.
00:06:01.590
Because it was 10:00 p.m. when all this started, I couldn’t sleep well that night; I was perplexed and kept trying to track the surge in traffic. I spent time investigating why so many people were visiting our website, and we still don’t have all the answers. Initially, we had a lot of direct traffic, which made it challenging to trace. It turned out that a few influencers in Japan were praising our website, saying that Dev.to was remarkably fast, sparking discussions across social media.
00:07:37.640
Even now, we come across forums using Dev.to as a benchmark for what a fast website looks like. I believe the direct traffic stemmed from the fact that, at that time, Twitter didn’t automatically convert Dev.to links into previews. Many users were directly typing the URL from tweets, making it harder to determine the traffic source purely based on referrals. It led me to ponder what's so special about a fast website. Aren't all websites fast? And why was Japan's reaction so pronounced? The geographical distance plays a part since the Pacific Ocean is vast, which affects web performance.
00:09:38.580
To improve performance, we need to consider latency, which is the time interval between a request and a response. When someone from Tokyo requests a website hosted in a data center in Utah, the data has to travel across the globe. Every JavaScript file, CSS file, custom font, etc., takes time to load, making latency a significant challenge. When you have geographic distance at play, overcoming latency becomes crucial. An average web page on 3G takes about 19 seconds to load, while 4G takes around 14 seconds. Even though we expect websites to load in under a second or two, many still have inconsistent network conditions.
00:10:36.030
One of the hurdles we face is that most people will leave a site if it doesn’t load within three seconds. We still deal with resource constraints on the web; the average web page is now larger than the original DOOM game. Consequently, when we load a webpage, we're often downloading a sizeable amount of content like heavy JavaScript libraries and bulky CSS, which add to the delay in performance. Web performance is about inclusivity — making websites accessible across the globe requires speed and efficiency.
00:11:55.560
Next, let's talk about a content delivery network, or CDN. A CDN distributes our pages and assets across various nodes around the world. When a user in Tokyo requests content, it should ideally come from a nearby node in Japan or Tokyo, minimizing latency. We've implemented Fastly as our CDN; it has been instrumental in our architecture. Unlike typical CDNs that focus on static assets like JavaScript and CSS, we’ve configured our system so that every page request is delivered from the CDN's edge. This way, users can fetch whatever they want without cross-continental travel for the data.
00:13:19.950
This means that ideally, we want to deliver a full user experience while keeping the initial request size small — around 14 kilobytes that can fit inside a TCP packet. This isn’t a strict requirement but serves as a good ideal. When using Rails with Fastly, we make sure to follow best practices, using cache control headers to cache pages effectively. We ensure our caching fits well into the concept of Russian doll caching, which is especially easy and effective in Rails.
00:15:01.050
Next, we focus on reducing render-blocking resources. After the essential data is sent over the wire, we have zero render-blocking resources. I’ve included comparisons of our site to other platforms like Mashable, illustrating how our site renders quickly under poor network conditions, while others take significantly longer. Many sites do not respect users' experiences in challenging conditions. The challenge is that many developers are aware of these issues, but effective organizational communication and prioritizing performance are crucial.
00:16:43.930
To combat render-blocking resources, we utilize async and defer attributes for JavaScript tags. This approach ensures that JavaScript is loaded after the initial page render is completed. With the defer method, all HTML loads, and the JS loads afterward, which preserves a better user experience. We also inline critical path CSS to make the loading times snappier. After the vital CSS is loaded, we fetch the remaining CSS asynchronously.
00:17:51.940
We also provide asynchronous loading for user data. Logged-in users will see their personalized content after the initial page load. The user’s profile picture or name can be cached in their browser, while additional data is loaded asynchronously. This method enables us to present the initial experience quickly while still minimizing delays from data fetching.
00:19:31.570
Rails supports this with various methods, such as adding the deferred tag to our source CSS or JS files. Using the defer feature, we ensure that nothing blocks rendering. By using a manageable amount of JavaScript, limiting CSS bundle sizes, and implementing HTTP/2 features, we can maintain a responsive experience even with a large amount of content being processed.
00:21:03.390
Overall, it’s essential to optimize for both speed and experience. The focus should be on creating a good website that functions efficiently for everyone — making these choices involves understanding that performance cannot always solely rely on traditional approaches or modern features alone. The work we put into creating a fast website stems from fundamental principles of performance.
00:22:59.500
Finally, I want to encourage everyone to think about the business case when it comes to performance improvement initiatives. It’s important to get your team on board, as a collective effort can lead to significant advancements. There can be tensions between marketers wanting to leverage new techniques and developers focusing on performance—thus effective communication is essential.
00:23:45.480
That's my talk. I like to do things fast, so I’ll open it up to questions. As for resources, I highly recommend 'High-Performance Browser Networking' by Ilya Grigorik. This book introduced many concepts I’ve shared here.
00:24:00.080
If you're interested in joining the community at Dev.to, we would love to have you. There’s a lot of technical content, an engaging community, and we're growing fast — currently, around 70,000 developers are part of our platform. We're planning to open-source our codebase soon, and if you're interested in being part of this open-source project, please let us know. Thank you all for being here!
