Search
RubyConf AU 2013
Keith and Mario’s Guide to Fast Websites
Edit
#web-performance
#benchmarking
#ruby-on-rails
#cdn
#caching
#http-2
Summarized using AI

Keith and Mario’s Guide to Fast Websites

Keith Pitt and Mario Visic • February 20, 2013 • Earth

In the video 'Keith and Mario’s Guide to Fast Websites' presented at RubyConf AU 2013, speakers Keith Pitt and Mario Visic delve into strategies for improving frontend performance in web applications. They emphasize the importance of user experience, stating that for every additional second a web application takes to load, conversion rates can decrease by 7%. Rather than focusing on backend concurrency, the discussion centers on optimizing loading times for end users. The following key points are highlighted:

  • Significance of Frontend Performance: Most load time issues originate from the frontend and network stack (80-90%), necessitating a focus on these areas for improvement.
  • Benchmarking Performance: Accurate performance measurement is critical. The speakers utilize the HTML5 Navigation Timing API and developed a tool called WBench for consistent testing. They focus on the 'DOMContentLoaded' event, which is key for user experience.
  • Optimization Techniques: Several approaches are discussed:
    • Minifying CSS and JavaScript files, which can reduce load time by approximately one second.
    • Implementing Gzip compression to decrease file sizes, saving another second.
    • Moving script tags to the bottom of HTML documents to prioritize content loading.
    • Asynchronously loading JavaScript to enhance rendering times.
    • Splitting JavaScript assets into application-specific and vendor assets to allow for better caching.
  • DNS Preloading: To resolve DNS lookup delays with new asset hosts, DNS addresses are preloaded, allowing quicker resource requests.
  • SPDY Protocol: Employing SPDY can further reduce latency and improve resource loading efficiency by making multiple file requests over a single connection.

After implementing these optimizations, the case study of their GIF Topper application shows a reduction in load time from 9 seconds to under 2 seconds. The speakers conclude by reiterating the importance of first impressions and user experience in web applications, encouraging developers to adopt these practices for optimal performance. Their findings provide valuable insights into how developers can enhance the speed and responsiveness of their web applications for better user engagement.

Keith and Mario’s Guide to Fast Websites
Keith Pitt and Mario Visic • February 20, 2013 • Earth

RubyConf AU 2013: http://www.rubyconf.org.au

When you talk to most people about Rails performance the conversation usually turns to concurrency. How can my Rails app handle 60 simultanious requests per second? How do I webscale?
Although the topic of concurrency is important, we won't be focusing on that during this talk. We want to focus on end user speed.
For every extra second your application takes to load your conversion rates will drop by an average of 7%. While most people start tweaking their backends to squeeze every extra ms in response time, more often than not (80-90%) of the actual time spent loading your application is on the front end and the network stack. This is where you should start.
We will cover a range of techniques and provide benchmarks along the way to show how much performance you can expect from each step along the way. We'll also cover some backend performance tuning as well.
Here's some of the topics we'll cover:
How to accurately benchmark performance
Asyncronously loading assets
Reducing requests per page
Rails http streaming (chunked responses)
Basic caching
What is SPDY - and how to use it
What CDN is right for your app?
Server location and why it matters

RubyConf AU 2013

00:00:04.640 Hi everyone. Thank you for joining us today for Keith and Mario's guide to fast websites. I apologize in advance for the title. When Mario and I were brainstorming, he asked what we should call the talk, and I was trying to think of the lamest possible name we could come up with. Hence, we settled on 'Keith and Mario's Guide to Fast Websites,' which we think is quite fitting.
00:00:24.400 A little bit about Mario: he is the lead maintainer for a site called howgoodischem.com, which is a fun and cheesy title. If you want to know how good cheese is, definitely check it out! As for me, I am originally from South Australia, where I had the honor of winning the South Australian Magician of the Year award in 2007, specializing in close-up magic.
00:01:04.159 Now, we are both from Australia, specifically from a suburb called Brunswick, which is located just north of here. It’s a vibrant and hip area with a culture that often promotes the saying 'go hipster or go home.' It's a peaceful place with great coffee and is a really nice place to live.
00:01:26.479 By day, we work at a company called Invado, and by night, we contribute to a site called DeskTopper. You may have heard of it. DeskTopper allows users to upload their favorite wallpapers, which can then be synced to their Dropbox accounts. This means that whenever users sync their Dropbox, their desktop wallpaper will update automatically.
00:01:51.479 How many of your chat rooms look like this during the day? Personally, I prefer using GIFs rather than text as they make conversations more lively and fun, even if it annoys some people. Speaking of GIFs, while preparing for this talk, I came across a tweet that apparently showed Can Stall loving to create GIFs of people getting punched in the face. It was unexpected but amusing.
00:02:21.239 Today, Mario and I are excited to introduce a new app we created called GIF Topper! This app features a list of GIFs you can browse through. When you hover over a GIF, a loading symbol appears, and then it starts playing. At the bottom left of each GIF, there’s a little cloud icon that lets you send that GIF to your Dropbox for easy access.
00:03:01.040 During a demonstration to David Goodlad, I showed him a GIF and remarked that it looked like Link Stall. He quickly corrected me, claiming it was Zach Galifianakis. After some friendly betting between us, I conducted a quick image search and found that I was wrong. Turns out it was indeed Zach. The moral of the story? Always double-check before claiming someone's identity.
00:03:48.400 Thus, I lost a friendly bet and ended up giving away a free lifetime membership to DeskTopper, which costs around $30. So today, we want to share with you our journey of optimizing GIF Topper. Initially, everything was great, but we realized that the website was slow to load, especially for first-time users. We conducted some benchmarks and discovered that it was taking 9 seconds to load.
00:04:45.679 Now, many people may assume that the slowness comes from the animated GIFs, but we had a preview image for each GIF so that should not have been the issue. We explored our hosting setup on Heroku and checked our page size, which was about 900 kilobytes — slightly larger than average but not severely so. This led us to a significant question: why was our site so slow?
00:06:08.160 To fix this, we set a goal for our web page to load in under 2 seconds for a better user experience. Given that we launched the site just yesterday with no users yet, we wanted to ensure it loaded quickly for those first interactions. The focus here is not on scale numbers like serving thousands of users simultaneously but rather ensuring that when users arrive, their experience is immediate.
00:07:24.639 To enhance our website's performance, we consulted with experts, including Steve from Google. He advised us to focus on front-end optimizations, as most response time is spent there rather than on the back end. The initial breakdown of a website loading is primarily made up of HTML markup, CSS, JavaScript, and images.
00:07:50.240 When visualizing this process, the latency and response time for serving up HTML from the server is small compared to the overall loading time of the web page. So, we decided to concentrate on optimizing the front-end components.
00:08:21.000 Measuring performance accurately is critical. Since we're in Australia and hosting in the US, latency can be quite high, making it necessary to have consistent run benchmarks. HTML5 provides the Navigation Timing API, which records timestamps when loading web pages, capturing various data points like DNS lookup timings, DOM loading times, and asynchronous script loading.
00:09:07.839 Using this API, we developed a performance tool called WBench, version 2.2, that helps us measure various loading points over multiple test runs. This allows us to determine a standard deviation of load times, providing us with a reliable indicator of performance consistency.
00:09:56.760 The goal was to focus on the 'DOMContentLoaded' event because it's fired after all images have loaded. As GIFs are the primary content of our website, this metric is crucial for us. Additionally, we made sure to perform our tests over a strong internet connection to simulate average usage in Australia.
00:11:07.360 Our primary focus was on first impressions, ensuring that when users visit our site, it loads quickly. This is vital as they might leave before the page even loads, negating any performance enhancements we make later through caching.
00:12:05.920 We also utilized webpage test.org, a powerful tool for analyzing front-end performance by entering any URL to get detailed insights. Using Google Chrome Developer Tools’ waterfall chart functionality and specifying our testing location allowed us to obtain consistent performance metrics.
00:12:48.000 After benchmarking GIF Topper, we aimed to optimize the time users waited before they saw anything on the page. The load time was unacceptable; we wanted to decrease the time users saw a blank screen, which lasted around 5-7 seconds.
00:13:54.080 We realized that minifying CSS and JavaScript files was one of the first things we could do. Using Rails makes this straightforward since it handles it automatically, but we manually turned it off to measure our original load time. Minification helped us shave off around a second.
00:15:16.600 Next, we implemented Gzip compression to reduce the size of our assets. Gzip works by compressing files before they are sent to the client, allowing for smaller payloads and improved loading times. This change helped us save another second in load time.
00:16:25.840 However, we still faced issues with blocking JavaScript that was delaying the render time of the page. To combat this, we moved our script tags to the bottom of the HTML file, allowing the page content to load first before running JavaScript.
00:17:46.840 After managing to reduce load time from 9 seconds to 5 seconds, we continued to explore the possibility of asynchronously loading JavaScript. This would let the browser continue rendering while scripts load, thus minimizing blocking time.
00:18:26.239 We also discovered that splitting our JavaScript assets into application-specific and vendor assets would significantly help. This way, we could cache vendor scripts and ensure that users wouldn't need to re-download them every time we made a small change.
00:19:35.600 Lastly, we also tackled how to optimize asset loading from multiple hosts. By having multiple asset hosts, we could bypass the browser's limitation on connections per domain, allowing simultaneous downloads of resources to further decrease load time.
00:20:00.560 But we encountered DNS lookup issues when hitting new asset hosts on fresh loads. To fix this, we preloaded DNS addresses at the top of our pages so the browser can be ready for requests, which helped improve performance significantly.
00:21:28.000 We also considered implementing SPDY, a networking protocol that reduces latency and improves resource loading. By using this protocol, we could request all files simultaneously over a single connection, drastically cutting down wait times for users.
00:22:51.680 After implementing these changes, we managed to reduce our load time from over 9 seconds to just under 2 seconds. It was incredibly satisfying to see the performance improvement. However, we still struggled with third-party scripts that could block our site performance. We always need to be mindful of how they affect the overall speed.
00:23:34.000 After numerous optimizations, our visitors can now enjoy a significantly improved experience with GIF Topper. It's crucial to ensure that your site remains speedy, especially for users who rely on fast load times.
00:24:51.600 In conclusion, we hope our findings will help you assist developers and optimize their web applications effectively. Remember, first impressions matter, so ensure users find your site fast, responsive, and enjoyable. Thank you for joining us today!
Keith Pitt
@keithpitt
Mario Visic
@mariovisic
Explore all talks recorded at RubyConf AU 2013
+25