Better WebPerformance with Rails

Talks

Stefan Wintermeyer

Better WebPerformance with Rails

by Stefan Wintermeyer

In the talk "Better WebPerformance with Rails," Stefan Wintermeyer discusses the importance of web page loading speed and its impact on user experience. He emphasizes that slow-loading pages result in higher bounce rates, particularly stressing the significance of the first three seconds of page loading. Key points include:

User Expectations: Users expect quick feedback from interfaces, with anything over one second affecting their engagement significantly.
Page Load Time: Studies show that after two seconds, user engagement drops steeply. Hence, aiming for a page load time of under one second is crucial, especially for mobile users.
Technical Challenges: The speaker explains various technical aspects, including DNS lookups, TCP connections, and TLS handshakes that contribute to loading times, leaving limited time for actual data delivery.
Performance Analysis Tools: The use of waterfall charts to visualize resource downloading is highlighted, showcasing how slow elements can hinder overall performance.
Caching Strategies: Wintermeyer discusses implementing caching techniques, such as fragment cache and Russian doll caching, to optimize load time. He also stresses optimizing database queries and the importance of HTTP caching with methods like ETags and last modified dates.
Static File Management: The talk includes strategies for handling static files with nginx, advocating for caching and pre-compression to enhance loading times.
Server Infrastructure Optimization: Approaches to managing bandwidth and utilizing Content Delivery Networks are suggested for heavy traffic applications, emphasizing continuous strategic revisiting and fine-tuning.

Wintermeyer concludes by reiterating the necessity of assessing performance components and making necessary adjustments to enhance long-term efficiency and user satisfaction. Key takeaways focus on the critical need for fast web performance in modern applications and the continuous evaluation of strategies and technologies employed to achieve these performance goals. The speaker encourages ongoing discussions on web performance across social media platforms.

00:00:24.800 Good morning! First of all, this is going to be a bumpy ride.

00:00:30.680 So if you have any questions or if I miss something, just raise your hand and ask.

00:00:40.190 Let's talk about why our first web page is important. The problem is that the slower the web page, the more people will bounce from it.

00:00:53.949 This graph illustrates how that works. You see the first three seconds—that's the page loading time. The first three seconds are the most important. After two seconds, you have a steep drop-off, and if your page takes longer than about ten seconds, most of your users are gone.

00:01:17.720 You have to remember that this is not just for good internet connections. This applies to 3G mobile internet as well. You will lose users if your page takes too long to load.

00:01:32.600 Why is that? The issue is that humans need some sort of feedback from any kind of graphical user interface.

00:01:45.579 Research shows that if something takes 0 to 100 milliseconds, we feel it almost instantly. As the time increases, we tend to feel lost; anything over a second causes us to think differently about the task at hand.

00:02:04.490 Thus, we want to keep our web page loading time below one second. That's an ambitious goal, but it's achievable. To give you an idea of why that's so important, consider Google's experiment.

00:02:24.860 They slowed down their response time for a specific user group, and you can see the impact on user behavior over a few weeks.

00:02:36.650 Despite the slow start, even small drops in speed can lead to behavioral changes in how users engage with search results.

00:02:48.350 Regarding mobile users, these statistics are a bit older but have become even more extreme today. Many users are now using their mobile phones as their primary device for internet access.

00:03:01.540 You need to cater to these users because they typically have the slowest possible connections. Your goal should be to deliver a page to them within that one-second frame, which is a challenging task.

00:03:13.250 It's tough because we have to consider the whole stack we are dealing with, including DNS lookups, TCP connections, and TLS handshakes.

00:03:31.970 At the end of the day, if everything goes perfectly, we are left with about 400 milliseconds to deliver the page from the server.

00:03:44.810 However, the browser takes about 100 milliseconds to render the page itself. Thus, if we subtract that 100 milliseconds from the 1,000 milliseconds, we are only left with 300 milliseconds for actual page loading.

00:04:02.600 To understand the issues, you must know how HTTP downloads work. HTTP operates on top of TCP, which has a three-way handshake.

00:04:15.650 The latency caused by this handshake cannot be changed, and it always takes one round-trip from the device to the server.

00:04:44.390 TCP starts with a very small amount of data, slowly increasing as it tries to figure out the bandwidth. As a result, it takes a while to ramp up the transfer speed, impacting overall performance.

00:05:02.600 Talking about web performance analysis, one of the major tools available is the waterfall chart. This is a graphical representation of how resources are downloaded.

00:05:20.990 For instance, this is a screenshot from the homepage of this conference. The red line you can see indicates a missing favicon, signaling a problem that should be addressed.

00:05:41.810 Let's dive into a specific connection example using a 3G connection. The browser begins rendering at approximately 3.6 seconds, which is already far away from our one-second goal. The HTML file is the first to download, taking over two seconds on its own.

00:06:07.699 Once the browser starts rendering, there’s a noticeable feeling of frustration for the user, especially if the initial load is slow.

00:06:52.550 The first render is immensely important because if you're already visiting that page, your browser will have cached many of the elements the next time you load it.

00:07:11.340 Getting pages to render within milliseconds is crucial. Here’s an example from my business homepage, which begins rendering at only 500 milliseconds.

00:07:30.920 We need to discuss Rails 5.2, as most attendees here are likely familiar with it.

00:07:44.130 We will create a minimal webshop. We will set up scaffolding for the category, product, user review, and establish relationships between them.

00:08:01.360 For instance, a product belongs to a category and can have many reviews, while a user can create many reviews. The product model will have a method to calculate the number of stars.

00:08:20.000 The index page will contain simple HTML and some CSS to enhance readability. The question now is, how long does it take to render this page on my laptop?

00:08:40.580 In development mode, the page renders in 497 milliseconds, which is above our limit.

00:09:05.360 Even with such a simple page, we find ourselves well over our desired speed budget.

00:09:12.950 Therefore, the first step is to activate caching, which is typically disabled in development mode.

00:09:25.830 We will implement a fragment cache for individual rows.

00:09:32.270 To ensure up-to-date content, we need to add 'touch true' to the reviews.

00:09:43.340 This way, when a new review is added, the product will be updated accordingly, preventing old cached data from being shown.

00:09:58.970 In the end, we find ourselves significantly above our goal, but still within a reasonable range, approximately 79 milliseconds.

00:10:16.490 With a robust caching strategy, we could implement a Russian doll caching strategy, caching entire tables as well.

00:10:25.860 While the improvement gained might not be as substantial as the initial change, it's still an upgrade. We should continuously invest time in improving our caching strategy.

00:10:43.430 That said, we should also focus on optimizing database queries, as calculating values dynamically can be wasteful.

00:10:55.920 In most cases, you can store certain values in the database itself to save processing time later on, which is a better use of resources.

00:11:12.750 So, it’s critical to consider what calculations need to happen at request time and which ones we can cache.

00:11:27.500 When you implement caching, understand that it will always be slower the first time it’s accessed.

00:11:38.450 The system must check if a fragment is cached; if it's not, it will render the view and utilize resources.

00:11:53.040 The cache keys should be simple to compute so as not to add unnecessary delays to your application.

00:12:09.760 An overly complicated cache key can take longer to compute than rendering the view itself.

00:12:28.150 Next, let's discuss HTTP caching, which can drastically improve performance since browsers aim to minimize downloading.

00:12:39.850 Optimizing with last modified and ETags can reduce unnecessary resource retrieval.

00:12:56.020 The server acknowledgment of cached resources, when still good, saves time,

00:13:06.820 As a consequence, browsers save time fetching while servers save time rendering.

00:13:20.020 Preemptively generating caches during off-peak hours can provide great benefits and enhance performance.

00:13:35.189 Next up is the handling of files through nginx, where we cache frequently accessed static files to decrease request time.

00:13:46.079 Utilizing pre-compression on files enhances the speed further, resulting in dynamic and efficient page loading.

00:13:58.370 Web performance targets and practices, such as cookie processing and cache invalidation, must ensure files are current and cleaned regularly.

00:14:09.330 These cache mechanisms also apply to logged-in users, provided appropriate planning is taken.

00:14:21.620 In a scenario where user 10 million unique web pages are delivered, turn fine-tuning into a more significant efficiency strategy.

00:14:35.270 If the storage size is substantial, the implementation becomes far less daunting with cost-effective storage options.

00:14:45.390 Moving ahead, it’s equally worthy to devise the necessary settings to delete outdated files, ensuring a smooth operation.

00:15:05.135 Managing page expiration techniques ensures users are served the newest content while maintaining optimal performance.

00:15:19.270 Server infrastructures must consider edge cases, inviting intentional analysis instead of potential pitfalls, to optimize performance.

00:15:31.400 Utilizing Content Delivery Networks can further assist in managing bandwidth consumption, especially for applications experiencing heavy traffic.

00:15:56.850 Having done well with test performance implementations, it’s important to continually revisit methods and incorporate improvements.

00:16:02.380 Adopting alternative compression standards also saves time, boosting performance and optimizing user experience.

00:16:13.120 For any website or application needing growth, analyzing all performance components while yielding clarity and foresight will be vital.

00:16:25.080 Ultimately, performance optimization discussions shouldn't overlook programming languages as well as frameworks when building applications.

00:16:45.570 The importance of managing your development environments enhances launch performance while ensuring bug-free deployments.

00:17:01.440 In closing, always keep your focus on adjusting and finetuning your strategies for long-term efficiency and superior user experience.

00:17:19.440 Any questions?

00:17:28.300 Thank you! It's always a pleasure to discuss performance with you all.

00:17:38.180 And remember to keep the conversation ongoing on social media!

00:17:44.830 Feel free to follow my Twitter to stay updated on web performance topics.

00:17:52.520 Thank you all once again, and I hope you continue exploring these principles in your projects.

00:17:59.540 Thank you and have a great day!

wroc_love.rb 2018