YSlow rule #9 – Make JavaScript and CSS External

17. May 2011 · Write a comment · Categories: Performance · Tags: , , , , , ,

We’ve briefly touched this subject a number of times already. Making your JavaScript and CSS external simply means moving it from your HTML header to their own files, referenced as an external file in the header. So why does Yahoo think that this is a good idea? We’ve already discussed the possibility to cache resources in the browser client-side cache. Caching scripts and styles is definitely easier than caching HTML. JavaScript and CSS are typically only changed when changing something on the site like new styling, new features, etc. Changing HTML happens all the time when users write new content, new search results are found, etc. When inlined, the scripts and styles are typically not cached or at least not for a very long time. But wait, here’s the real bonus: scripts and styles are typically shared between multiple views. Moving all that static stuff to external files will make the browser cache them, serving the cached versions when loading page number 2, 3, and so on.

The YSlow documentation argues that you can sometimes benefit from inlining your script and styles directly in the HTML. This only goes for pages with a single page view per session like the Yahoo front page. I can see the point and noticed that pretty much all search engines do this. I still think that you should get a lot of visitors in order to do this kind of thing. So unless you’re Google or your front page uses an entirely different styling than the rest of your site, you should be covered by moving the static stuff to external files.

Another benefit is when debugging through Firebug. When I need to debug some inlined JavaScript, I typically spend some time wondering and then realizing that I can’t debug JavaScript from the HTML tab in Firebug. This usually causes a bit of confusion and sometimes even some pulling out of precious hair strands. The solution is to navigate to the scripts tab and selecting the HTML file. I can understand why the UI works that way, but I keep forgetting. Moving all JavaScript to an external file forces me to navigate to the scripts tab right away.

(Proofread by inWrite)

Finally! Google makes a Page Speed API

11. May 2011 · Write a comment · Categories: Performance · Tags: , ,

A lot of new stuff is released by Google these days. The Google I/O conference typically means a bunch of new products and API’s and this year are no different. In regards to performance optimization, I was very happy to discover a new Page API earlier today. That’s right, folks! A new and shiny API, making the Page Speed rules open for everyone to integrate into their products. Actually, I requested this feature last year (http://code.google.com/p/page-speed/issues/detail?id=279), why I’m even happier to see it implemented.

I’m really looking forward to see exciting new products, using the Page Speed API. In fact, I’m working on a product myself, which will definitely be using the Page Speed API. Stay tuned for more info soon.

You can check out the Page Speed API at Google Code.

YSlow rule #1 – Minimize HTTP Requests

23. February 2011 · Write a comment · Categories: Performance · Tags: , , ,

In the following twenty-two posts, I will look into all the rules in YSlow. This is a pretty comprehensive plan, but I will try to keep the posts short and precise. All rules are pretty good documented in the YSlow documentation here: http://developer.yahoo.com/performance/rules.html. I will try to give you my point of view and experiences with each rule rather than just repeat the Yahoo documentation.

Let’s look at the first YSlow rule: “Minimize HTTP Requests.” This rule covers the problem of the way a page is rendered in the browser. When you browse to a new URL, the HTML is fetched from the web server hosting the requested domain. HTML typically contains references to resources located at the same or different web servers like images, scripts, style sheets, etc. Some might think that when doing the initial request for the HTML from the web server, all referenced resources from that same domain are also returned to the browser. This is not the case. When the browser successfully obtains the HTML, it starts rendering the markup. Each time it reaches an element in the HTML containing an src attribute, a new request for the referenced resource is made to the web server. You probably can understand why this could be a potential problem: a lot of requests to the web server.

How do we minimize the number of requests from the browser? Well, there are multiple strategies, and they all depend on the specific resource causing the request.

Images

You probably need a lot of images in order to render your page. Pretty much all pages on the web consists of both text and images. Images often result in a lot of requests, because most pages use a lot of images for making your website look pretty. One of the only strategies to reduce the number of requests for images is to combine multiple images into one; this is also known as CSS sprites. All your images are placed side by side in a larger image. This sounds a bit like a hack. Well, it is a hack!

When combining multiple images into one, you need some way of extracting each image when fetched from the server. Here you will be able to extract regions of a larger image, using CSS. I usually don’t use CSS sprites that much. There are a couple of reasons why:

  1. If you are a programmer like me, it will get harder to deploy new images, because you need to modify an existing image rather than just add a new file.
  2. The client code gets messy compared to multiple clean image references. You need to specify the region inside the large image to show each time a new image should be rendered.

I prefer a good caching strategy over CSS sprites at all times. I sometimes in-line images in CSS as well. More on both strategies in later blog posts.

JavaScript/CSS

Unlike images, both JavaScript and CSS are all text. The easiest way to reduce the number of requests for these types of files is to combine all references of JavaScripts into one file and doing the same with all the style sheets. This strategy is similar to the CSS sprite approach for images, but we don’t need to split the combined files on the client. That is why this is the simplest and most effective way to reduce HTTP requests for scripts and style sheets.

You can combine your scripts and style sheets manually or you can use some kind of tool for the job. When doing ASP.NET (MVC) sites, I usually go for SquishIt, which bundles both JavaScript and CSS files into one. In my next blog post, I will show you how SquishIt works.

I never bundle my own style sheets and scripts with external stuff like jQuery. If you use a CDN from Google, Microsoft, or third, jQuery should already be in your local cache.

Google Webmaster Tools – What’s your site performance?

18. February 2011 · Write a comment · Categories: Performance · Tags: , , , ,

In the last three posts, I’ve looked at tools for optimizing performance on a website. This week I will show you a nice performance-related feature in Google Webmaster Tools. Google Webmaster Tools is a free tool from Google that provides different tools for webmasters, such as submitting a sitemap, generating a robots.txt, and other stuff. Webmaster Tools is typically not used for looking at performance issues, but if you expand the Labs tree note in the navigation menu, you will see a link named Site performance. If you click this link, a graph will show, which looks something like this:

The screenshot shows the site performance graph for one of my Danish websites, www.myrating.dk. Notice that unlike YSlow, Page Speed, and Speed Tracer, the result showed above covers the average load times for all your pages and not only one page at the time. The chart is divided into two areas: a fast green area and a red slow area. If the trend line is below the red dotted line in the green area, this means that your site is fast. If above the red line, your site is slow. The statistics is generated from all users who have installed the Google Toolbar and enabled the PageRank feature. This means that you need a lot of visitors on your site for this graph to show a realistic result.

Below the graph you will find up to ten URLs, which Google have suggestions for you to optimize:

You can expand each URL, giving you a detailed explanation on what to improve. The rules used on Google Webmaster Tools look like a subset of the rules used on Google Page Speed. I don’t see much idea in this feature, unless you don’t have Page Speed installed.

It would be great if Google would implement some sort of alert, where you could receive an email or similar, if response times suddenly decreased.

Google Speed Tracer – The alternative with potential

11. February 2011 · Write a comment · Categories: Performance · Tags: , , ,

In the two previous posts, I’ve covered different plugins for Firefox. Even though web developers still seem to prefer Firefox over Chrome, a lot of us (me inclusive) switched to Chrome. Luckily Google does a pretty decent performance optimization extension for Chrome as well. The extension is Google Speed Tracer. You will find it at Google Code here: http://code.google.com/webtoolkit/speedtracer/.

When installed, a green timer icon will show to the right of the omnibox. One might think that the tool is now ready to run; unfortunately you need to modify how Chrome starts by adding the –enable-extension-timeline-api parameter to your Chrome shortcut. This seems a bit stupid, but once it’s done, you don’t need to worry about it again.

Speed Tracer is a bit different from YSlow and Page Speed in the way it presents your page. When you click the green timer icon, the Speed Tracer tab opens and starts profiling all the activity on the active tab. Try browsing to the page you need to optimize or reload it if it was already loaded in the active Chrome tab. Speed Tracer shows you all the activities needed to render your page. This typically consists of loading scripts, images, rendering HTML and even garbage collection as illustrated on the following screenshot:

Unlike YSlow and Page Speed, which focuses a lot on script, styling, and images, Speed Tracer also shows the time spent by the browser in rendering the various HTML elements on the page. Next to the headlines at the left, a small icon is sometimes shown, indicating available help to fix this issue. Unfortunately these help icons don’t show up that often, and when not shown, it is hard to find out how to deal with specific issues. This is the main problem with Speed Tracer. For us to be able to fix slow rendering of HTML, Google needs to provide us with hints on where the problems are and how to fix them. For instance, it would be pretty simple to implement a warning when a table is used for layout rather than a div. The tool could even generate the optimized code.

Look at the following example:

Speed Tracer is trying to tell me that a paint operation is slow. Slow is measured as anything above 100 ms. But the tool doesn’t tell me what parts of the painting is slow and how to fix it.

My conclusion on Speed Tracer is that it’s semiuseful but has a lot of potential if Google decides to update it with more rules and tips.

(Proofread by inWrite)

Google Page Speed – the YSlow clone

03. February 2011 · Write a comment · Categories: Performance · Tags: , , ,

Page Speed is a plug-in developed for Firebug by Google. If you don’t use Firebug, get it (http://getfirebug.com/)! It’s the coolest web developer plug-in for Firefox out there. The Page Speed tool is downloaded from http://code.google.com/speed/page-speed/download.html. Google Page Speed is very similar to Yahoo!’s YSlow, which I talked about in my previous blog post. I don’t say that competition is a bad thing, but developing a tool based on pretty much the same set of rules just seems stupid.

Page Speed analyzes your web page just as YSlow. Your page will get a grade from 1 to 100 (100 is the best), based on how you managed to follow certain rules for doing fast rendering of web pages. The rules are very similar to the ones available in YSlow. Some of the descriptions have a bit more information, like showing you how many percentage a file can be compressed. If you find old screenshots of Page Speed, it had a nice Activity tab, showing you a lot more information about the resources needed for your page to load than the Net tab in Firebug. In 2010 Firebug got those missing information, and Google deprecated the Activity tab.

One nice feature in Page Speed is its ability to natively optimize images, which can be compressed, as illustrated on the following screenshot:

This feature is available in YSlow as well, but through an external service.

So which tool should you use, YSlow or Page Speed? The answer is probably both. Try testing your pages in both tools and check for differences. I usually start by analyzing my page in YSlow, optimize it, and finish off by analyzing it in Page Speed. If you prefer Page Speed over YSlow, try doing it the other way around.

YSlow – your new best friend

28. January 2011 · Write a comment · Categories: Performance · Tags: , ,

The first tool that you should definitely check out is YSlow from Yahoo. YSlow is a plug-in for Firebug, which is a must-have for all web developers. You can find the Firebug plug-in here: http://getfirebug.com/ and the YSlow plug-in here: http://developer.yahoo.com/yslow/. Firebug is activated by clicking the small bug icon in the bottom right part of the Firefox window. When visible you will get a new tab in Firebug as illustrated below:

You start the analyzer by browsing to the site you want to analyze and enable the “Autorun YSlow each time a web page is loaded” or by presseng the “Run test” button. In the following example, I’ve analyzed the URL “http://www.myrating.dk/indhold/3422-boller_i_karry” from one of my websites:

(By the way, “Boller i karry” is a great Danish dish. If you want to make it, a translated recipe is available here: http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=da&tl=en&u=http%3A%2F%2Fwww.myrating.dk%2Findhold%2F3422-boller_i_karry&act=url.)

As shown in the screenshot, YSlow analyzes the content of the current page and shows you an overall performance score as well as a detailed list of rules, each graded from A to F (A is best). This page is rated C, which is actually not that bad. Striving for the best grade on all your pages will most likely be a waste of time. I usually go for an A or B on simple pages and B or C on complex pages, which uses a lot of external JavaScripts, etc.

You can click each rule, which shows a detailed description in the area at the right. YSlow typically shows a detailed description, explaining what you’ve done wrong as well as some hints on how to fix it. Note the “Read More” link at the bottom of each description, which will direct you toward a more detailed description at the developer.yahoo.com website.

YSlow has tabs as well. As default the Grade tab is selected. Make sure to check out the other tabs as well. The Components tab gives you a grouped overview of all your resources like HTML, JavaScript, and CSS. The Statistics tab is sort of the same but shown in a pie chart.  The hidden treasure is found beneath the Tools tab. There you’ll find URLs for different tools to help you optimize CSS, JavaScript, and much more. My favorite tool is the link titled “All Smush.it,” which will redirect you to the Smush.it service from Yahoo. I will write a blog post about image compression sometime in the future, but shortly told, the Smush.it service analyzes all your images and compresses them further, letting you download all the optimized images in a single zip file.

I will go into each YSlow rule in detail in upcoming posts, but right now you know enough to start analyzing your own sites.

(Proofread by inWrite)

Free tools to check your performance

21. January 2011 · Write a comment · Categories: Performance · Tags: , , , ,

So how do you spot if your site has performance issues or not? You probably have an idea if your site is responsive or not, but how does it compare to other sites, and which potential problems do you have? This is a starter’s guide to some of the tools I’ve used for the job. Blog posts with detailed info on each tool will be published later.

By the way, this post only focuses on the tools and techniques used for updating one page at a time. If you’re running a serious site, I highly recommend you to stress test your site using either real users or simulated clients. More on this subject in a future post as well.

YSlow

YSlow is probably one of the best and mostly used tools for analyzing performance problems. YSlow is a plug-in for the incredible Firefox plug-in Firebug. Yes, that’s right, a plug-in in a plug-in. If you don’t have Firebug installed, do it now. You won’t regret it! YSlow does its job by analyzing the current page and showing you all the issues worth fixing. You will get a total score from 1 to 100 (100 is the best) based on not your response time, but the way you’ve written your code. Example: you are referencing fifteen JavaScript files, hosted at your own domain. This scores low, because you could combine these into one reference instead. Not all rules in YSlow are equally important, but start from the top and starting seing your response times improving.

Google Page Speed

Google Page Speed is very similar to YSlow. It’s a plug-in for Firebug and analyzes the current page and shows issues. I don’t really know why Google decided to make a clone of YSlow, rather than contributing to the YSlow project. But the Page Speed plug-in has a couple of great features, not natively implemented in YSlow. One cool feature is the ability to let Page Speed generate optimized images on the fly for your page, which saves you the time in Photoshop.

Google Speed Tracer

Google Speed Tracer is the new kid on the block. It’s a plug-in for Google Chrome, which is nice if you’re using Chrome instead of Firefox. Speed Tracer is similar to YSlow and Page Speed but also includes a great profiler. The tool is definitely usable but still needs some work in order to beat the Firefox plug-ins. I like the new view on things though, rather than just doing another YSlow clone.

Google Webmaster Tools

This is not really a performance tool, but Google Webmaster Tools have an interesting feature for investigating your site performance over time. Beneath the menu Labs | Site performance you will find a graph, showing the average response times for your site in the last six months. It’s a good idea to follow this graph at least once a month, to verify that you didn’t break something with one of your software updates. You will need a lot of visits for this graph to show a realistic image, though. The data are collected through visitors of your site, using the Google Toolbar.

The rest

This post only focused on optimizing the web part of your application. If you’re connecting to a back end, a database, or similar, you could have performance problems here as well. In the upcoming posts on the various performance tools, I will show you how to spot these kinds of problems.

(Proofread by inWrite)

Why optimize your website?

04. January 2011 · Write a comment · Categories: Performance · Tags: ,

So why do I need to think about the performance of my website, you might think. Well, maybe you don’t. If you’re making a niche website, which exports a large data set to XML, the user probably doesn’t mind if the transaction spans four or ten seconds. But chances are that you’re actually doing something where performance is an issue. Research shows that 75 percent of your visitors are less likely to return to your site if you present them with a slow experience.

Furthermore, Google announced in 2010 that site speed is now used in web search ranking (http://googlewebmastercentral.blogspot.com/2010/04/using-site-speed-in-web-search-ranking.html). This basically means the following: if the user googles some keyword and you and your competitor has exactly the same ranking, the fastest site is presented first. This can have a huge impact on your number of visitors. Of course, the example is very simplified. A lot of factors are in play when Google decides which result to show first, and website performance is only a small percentage of the complete picture. But you probably get the idea that performance is important for Google rankings as well.

Finally, the performance is important in order to avoid your site crashing when multiple users suddenly decide to visit your site at the same time. When looking at a single page load, you could think that three seconds’ load time is acceptable by all your users. But think about the scenario where multiple users request the same resource at the same time. Most of us are on cheap hosting servers, not scaled for thousands of simultaneous requests. The result is that your load times will increase. I will talk more on tools to performance test your site with hundreds or thousands of simulated users in a later post.

Well, this is pretty much the introduction to the subject. In the next post I will get more technical. See ya!

(Proofread by inWrite)

Welcome to my blog

02. January 2011 · Write a comment · Categories: Performance · Tags: , ,

Hi and welcome to my new blog. During my years as a professional software developer, I’ve learned a thing or two about performance-optimizing software applications (both desktop and web applications). I’ve studied a lot of blog posts in order to solve different performance-related problems. This blog is my small donation back to the community.

I will primarily be writing about performance-optimizing websites in ASP.NET (MVC), but a lot of the concepts are portable to other technologies like PHP and Java Servlets (and even Ruby on Rails).

(Proofread by inWrite)