New Relic blog: JQuery Foundation’s Dave Methvin Shares his Rules of the Road for Speeding Up Your Website

Haven’t you noticed that just about everyone’s website is always too slow when you are browsing it? It seems like a universal truth. Nevertheless, if you spend some time with Dave Methvin, you can learn a lot about how to speed things up. Methvin is an old friend: we worked together back in the 1980s at PC Week (which is now called eWeek), since then he has built a few technical businesses and now is the president of the jQuery Foundation, the central repository and authoritative source for code for that particular language that is used in many websites. His recent speech about “The Web Doesn’t Have to Be Slow” at PraireCon can be found here on Slideshare.

Part of understanding how to speed up your site is in understanding how the browser and various Web servers work together to present a page to you. “A lot of times when people are doing performance testing, they start at the wrong end of the problem,” he told me in an interview. “They are measuring how fast it takes to do lots of loops, but they aren’t looking for bottlenecks in their code.” This is a common theme in performance testing. “We were doing this 25 years ago at PC Week when we were measuring network latencies, and people still fall into the same traps today,” he said. Think of this as asking the question of whether you want to run or walk to get to your car before you go on a long road trip. “It really doesn’t matter in the long run, because ultimately you are going to be in your car and driving for a lot longer than the amount of time you might save getting to it in front of your house.”

This means it is important to scrutinize everything on your pages and understand how each line can impact your performance. “You have to look carefully at when you are time-bound or causing something that is going to have a big effect like this,” he said. However, “with all the other things going on on your page, it is unlikely that the running time of your Javascript is the worst of your problems. But there are things you can do to make your Javascript code perform better,” he said. He calls these his “rules of the road” (see screen shot) to help you make browsing requests across the network more efficient for your pages and to eliminate tany obvious bottlenecks. These include:

Avoid 3xx requests. These penalize your pages because you introduce another round-trip to the time it takes you to load the referral page. While sometimes this can’t be avoided, you should do what you can to keep these referrals to a minimum. “The round trip times across the Internet can kill you and can degrade your performance,” he says.

Start requests early on your pages. Put requests for external resources such as images at the top of your page whenever possible, so this will be the first bits delivered to your browsers. This will also help with prefetching images for subsequent loads too, which should also be part of your HTML coding.

Minimize the number of overall requests and the resulting bytes.  Combine similar resources such as images or Javascript and download them together. Here you have to weigh the tradeoffs of combining these elements to take advantage of any browser caching versus using something like a content distribution network. You should also use tools such as CSSMin and Uglify.js to squeeze out any unneeded bits in your files to keep them small. Also most of you probably know to compress images or reduce their resolution and enable gzip compression on your servers too.

Maximize browser caching. Make sure your caching defaults are set up properly so that stable content (like your corporate logos or other frequently-used and infrequently-changed items) are specified accurately in your pages. This helps to take maximum advantage of browser caching. The less you have to reload, the faster your pages will appear.

Use domain sharding. If you find yourself loading a bunch of resources from a single domain you can take advantage of this technique. The idea is to spread requests across several domains at once to maximize bandwidth, since you are downloading elements in parallel rather than in series. This is a technique that many of the top trafficked websites use to boost their performance. Another way to do this is to use a content distribution network to help. One example is to use external jQuery libraries that are already pre-cached by your browser. Here is a great discussion of why you should do this, along with code snippets of how to use Google’s content delivery network for free. Because of different versions of jQuery, you can spend a lot of unnecessary browser time in loading these versions from your own site. This is just one or two lines of code and it can have a big impact on your page load times.  Along those lines, here is a sample plug-in to help speed up your WordPress site too.

Load non-critical stuff later. You should code your pages to wait near the end to load things that aren’t critical to viewing the page, such as content not initially visible, social media scripting tools, ads, and page analytics.

Another common coding mistake is to code into your pages browser version or client detection so you can push out particular features that depend on more modern browsers. This is decidedly old school and there are better ways, such as using tools like Modernizr that is a JavaScript library that can be used for this purpose. “Don’t try to detect which browser your visitors are using, that can really backfire when the browser changes in the future,” he said. Here is a great place to start to learn about this tool.

“This is a big topic, just like fixing cars – the more you do it, the more you understand the depth and dimensions of your problems,” he said.  “But at least following some of my suggestions you can be sure that the resources you put into your browsers are in the best order and optimized for the best possible viewing.”

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.