Yahoo Developer Network's "Best Practices for Speeding Up Your Web Site"
We've been batting around discussions between our two development groups for a while about ways to improve processes. It is no secret I am very interested in becoming more Agile, and some of my other co-workers are also looking into Agile methods. There has even been some inquiry into how we might achieve better documentation. In all, we are a pretty motivated group.
The co-worker across the hall that turned me on to PHPdoc mentioned "Yahoo best practices" today in passing, mentioning that he and someone else in his group had been looking at, so I asked him to send me the link. It looked good at first, but then when I clicked on the first link that caught my eye I was terribly disappointed.
From a User Experince stand point is always interesting to me to catch "initial impressions", so this blog post is my initial impression of Yahoo!'s Exceptional Performance Team's Best Practices:
1. Make Fewer Requests
Yes, but aside from the idea of "CSS Sprites" which is easy for me (though it might be tricky for others), this is perhaps a very unhelpful recommendation. Image Maps ARE NOT a good idea, I don't even know why they would mention such a thing when they admit it is not an accessible (and therefore a bad) solution. Inline image data is a bit too pie-in-the-sky to be helpful...
So as a design philosophy, designing with this principle in mind IS a good idea, but definitely a challenge. Certainly not a good candidate for the #1 spot.
2. Use a Content Delivery Network
Sure, if you're Google or Yahoo... how about an idea that most of us can use? Why is this #2? It really seems like something that might do a lot of good for about 2% of the people actually reading the recommendation.
3. Add an Expires or a Cache-Control Header
Yes, THIS is a good recommendation. I'm glad someone is willing to explain to me how to properly use HTTP headers so I don't have to dig through the overly complicated RFCs to try and understand what they are talking about. Thumbs Up.
4. Gzip Components
Yes. A little technical for some people to implement, especially to implement correctly, but great suggestion none-the-less.
5. Put Style Sheets at the Top
Yes, Thank You! Can we PLEASE try to follow the specification? I realize that some situations make this less than ideal, such as sites where users edit content in WYSIWYG inline editors and the only way to affect style is with inline code... but these are clearly an outliers. There are way too many offenders in this category. It's like the people that didn't want to give up table layouts are passive-aggressively trying to sabotage CSS any way they can...
6. Put Scripts at the Bottom
This is at least interesting to learn about. Perhaps problematic to actually follow, but definitely good to keep in mind during the design process.
7. Avoid CSS Expressions
I'm insulted. This isn't even part of the standard. Only a fool would use it (sorry if I offend any fools). It is flat out unnecessary to use them, and I really don't see why this would even needs to be considered a "best practice". If you even make a meager attempt at standards compliance then it is a given.
8. Make JavaScript and CSS External
Fair, Balanced, Accurate (unlike the news station that uses that as their "slogan"). I think this recommendation does a good job of pointing out why you might occasionally want to make an exception to what is other wise a good rule of thumb.
9. Reduce DNS Lookups
Good information to know... but also another one of the recommendations that really doesn't seem like it is applicable in the grand majority of cases.
10. Minify Javascript and CSS
Yes, PLZTHX, Next. This tip isn't really all that surprising, less is better.
11. Avoid Redirects
I sense a trend of being not too profound...
12. Remove Duplicate Scripts
... SRSLY?
13. Configure ETags
Good to know, useless to most people. This is another highly technical recommendation that requires control at the header level.
14. Make Ajax Cacheable
Fair enough, I suppose some people don't think about things like that...
15. Flush the Buffer Early
Something I don't do enough, but then I never really know what the sever admin is going to set the buffer settings to tomorrow or the next day. A good courtesy flush() never hurts! (sorry, had to)
16. Use GET for AJAX Requests
Now HERE, is some useful information for me. Something (at least) I didn't know about the difference between GET and POST.
17. Post-load components
This seems like it would have been better combined with #6. Certainly makes the design considerations easier. Is 34 a magic number? If not, this would have been much better off as part of #6.
18. Preload Components
Did this a LONG time ago with roll-over images (pre-loaded commonly used roll-overs for second level pages on the homepage).... man were we stupid back in the Web 1.0 days!
This approach sounds reasonable, but I fear it has the potential to be heavily abused.
19. Reduce the Number of DOM Elements
I guess there are some people that somehow fooled themselves into thinking this was inobvious. *cough* denial */cough*.
20. Split Components Across Domains
I've seen sites doing this...was confused but now at least I understand why... still something that most of us would never really get much leverage out of. This sounds like more of a reverse bandwidth sucking cheat to me. If you feel the need to do this... maybe there is something ELSE you can do to improve performance instead of hacking the HTTP recommendation?
21. Minimize the Number of Iframes
Uh, how about 0 (zero)?! Honestly though, I do use Iframes...when I REALLY have to (Like getting dynamic content on www4 sans-JavaScript).
22. No 404s
This is what initially threw me aback. Huh? I can't control someone typing in the wrong URL. Sorry, but trying to act like pilot error doesn't happen isn't a "best practice". I do like the way this recommendation touches on the pros and cons of "smart 404" pages that try to help the visitor find something, but aside from reminding developers to make sure their links (including style sheets and scripts) all go to valid URLs.... This recommendation is about as pointless as it gets.
23. Reduce Cookie Size
Is called "session". I use.
24. Use Cookie Free Domains
Yet another neat trick that most people _won't use_.
25. Minimize DOM Access
Three good tips in one! Is it my birthday, or are we having a sale?
26. Develop Smart Event Handlers
Another good tip (or is that two cleverly disguised as one?).
27. Choose <link> over @import
On a roll finally, If I cared about IE users. They should be punished. Regardless, this is REALLY good information to know, only problem is deciding whether to use it for good, or evil...
28. Avoid Filters
Back to Duh. Good information if I go to hell and have to develop sites for IE 5 or IE 6 users.
29. Optimize Images
Thanks Mr. Wizard :D
Sarcasm aside, it is good to have someone actually recommend to proper tools for doing this. There are some people that DON'T know how to optimize images.
30. Optimize CSS Sprites
Before I read this, I was prepared for the worst. This is actually GOOD information to have though. Orientation of components of sprites vertically is more efficient and some other useful tips.
31. Don't Scale Images in HTML
OK Daddy. I'll stop using the <blink> tag too. Pinky swear. There are legitimate cases when you _do_ want to do this. If you link to a picture only a little bigger than the space you have for a thumbnail, and don't wan't to waste space/resources to make a thuumbnail, this isn't a bad practice in cases where there are few pictures and the visitor is almost certain to click on them all. Pretty rare use case, but important to consider.
32. Make favicon.ico Small and Cachable
Good recommendations and considerations for something I'd really rather not have to deal with, but now I know I probably should anyway. Apparently it is better to have a really small icon than to not have one at all, and forcing a long cache can help performance.
33. Keep Components Under 25K
Wow, I hadn't really thought about that. But probably something really important to consider. Seems like a pretty extreme case, but good to know. Brings up a good point on the difference between compression and minification.
34. Pack Components Into a Multipart Document
Not very well explained...since this is a feature "some user agents don't support", it sounds pretty iffy.
twenty 3's, nine 2's, five 1's
Then again. This IS Yahoo we are talking about. I am seriously beginning to have second thought about integrating the YUI Calendar component into a recent project... It wasn't a terribly pleasant experience to start with.
The co-worker across the hall that turned me on to PHPdoc mentioned "Yahoo best practices" today in passing, mentioning that he and someone else in his group had been looking at, so I asked him to send me the link. It looked good at first, but then when I clicked on the first link that caught my eye I was terribly disappointed.
From a User Experince stand point is always interesting to me to catch "initial impressions", so this blog post is my initial impression of Yahoo!'s Exceptional Performance Team's Best Practices:
1. Make Fewer Requests
Yes, but aside from the idea of "CSS Sprites" which is easy for me (though it might be tricky for others), this is perhaps a very unhelpful recommendation. Image Maps ARE NOT a good idea, I don't even know why they would mention such a thing when they admit it is not an accessible (and therefore a bad) solution. Inline image data is a bit too pie-in-the-sky to be helpful...
So as a design philosophy, designing with this principle in mind IS a good idea, but definitely a challenge. Certainly not a good candidate for the #1 spot.
2. Use a Content Delivery Network
Sure, if you're Google or Yahoo... how about an idea that most of us can use? Why is this #2? It really seems like something that might do a lot of good for about 2% of the people actually reading the recommendation.
3. Add an Expires or a Cache-Control Header
Yes, THIS is a good recommendation. I'm glad someone is willing to explain to me how to properly use HTTP headers so I don't have to dig through the overly complicated RFCs to try and understand what they are talking about. Thumbs Up.
4. Gzip Components
Yes. A little technical for some people to implement, especially to implement correctly, but great suggestion none-the-less.
5. Put Style Sheets at the Top
Yes, Thank You! Can we PLEASE try to follow the specification? I realize that some situations make this less than ideal, such as sites where users edit content in WYSIWYG inline editors and the only way to affect style is with inline code... but these are clearly an outliers. There are way too many offenders in this category. It's like the people that didn't want to give up table layouts are passive-aggressively trying to sabotage CSS any way they can...
6. Put Scripts at the Bottom
This is at least interesting to learn about. Perhaps problematic to actually follow, but definitely good to keep in mind during the design process.
7. Avoid CSS Expressions
I'm insulted. This isn't even part of the standard. Only a fool would use it (sorry if I offend any fools). It is flat out unnecessary to use them, and I really don't see why this would even needs to be considered a "best practice". If you even make a meager attempt at standards compliance then it is a given.
8. Make JavaScript and CSS External
Fair, Balanced, Accurate (unlike the news station that uses that as their "slogan"). I think this recommendation does a good job of pointing out why you might occasionally want to make an exception to what is other wise a good rule of thumb.
9. Reduce DNS Lookups
Good information to know... but also another one of the recommendations that really doesn't seem like it is applicable in the grand majority of cases.
10. Minify Javascript and CSS
Yes, PLZTHX, Next. This tip isn't really all that surprising, less is better.
11. Avoid Redirects
I sense a trend of being not too profound...
12. Remove Duplicate Scripts
... SRSLY?
13. Configure ETags
Good to know, useless to most people. This is another highly technical recommendation that requires control at the header level.
14. Make Ajax Cacheable
Fair enough, I suppose some people don't think about things like that...
15. Flush the Buffer Early
Something I don't do enough, but then I never really know what the sever admin is going to set the buffer settings to tomorrow or the next day. A good courtesy flush() never hurts! (sorry, had to)
16. Use GET for AJAX Requests
Now HERE, is some useful information for me. Something (at least) I didn't know about the difference between GET and POST.
17. Post-load components
This seems like it would have been better combined with #6. Certainly makes the design considerations easier. Is 34 a magic number? If not, this would have been much better off as part of #6.
18. Preload Components
Did this a LONG time ago with roll-over images (pre-loaded commonly used roll-overs for second level pages on the homepage).... man were we stupid back in the Web 1.0 days!
This approach sounds reasonable, but I fear it has the potential to be heavily abused.
19. Reduce the Number of DOM Elements
I guess there are some people that somehow fooled themselves into thinking this was inobvious. *cough* denial */cough*.
20. Split Components Across Domains
I've seen sites doing this...was confused but now at least I understand why... still something that most of us would never really get much leverage out of. This sounds like more of a reverse bandwidth sucking cheat to me. If you feel the need to do this... maybe there is something ELSE you can do to improve performance instead of hacking the HTTP recommendation?
21. Minimize the Number of Iframes
Uh, how about 0 (zero)?! Honestly though, I do use Iframes...when I REALLY have to (Like getting dynamic content on www4 sans-JavaScript).
22. No 404s
This is what initially threw me aback. Huh? I can't control someone typing in the wrong URL. Sorry, but trying to act like pilot error doesn't happen isn't a "best practice". I do like the way this recommendation touches on the pros and cons of "smart 404" pages that try to help the visitor find something, but aside from reminding developers to make sure their links (including style sheets and scripts) all go to valid URLs.... This recommendation is about as pointless as it gets.
23. Reduce Cookie Size
Is called "session". I use.
24. Use Cookie Free Domains
Yet another neat trick that most people _won't use_.
25. Minimize DOM Access
Three good tips in one! Is it my birthday, or are we having a sale?
26. Develop Smart Event Handlers
Another good tip (or is that two cleverly disguised as one?).
27. Choose <link> over @import
On a roll finally, If I cared about IE users. They should be punished. Regardless, this is REALLY good information to know, only problem is deciding whether to use it for good, or evil...
28. Avoid Filters
Back to Duh. Good information if I go to hell and have to develop sites for IE 5 or IE 6 users.
29. Optimize Images
Thanks Mr. Wizard :D
Sarcasm aside, it is good to have someone actually recommend to proper tools for doing this. There are some people that DON'T know how to optimize images.
30. Optimize CSS Sprites
Before I read this, I was prepared for the worst. This is actually GOOD information to have though. Orientation of components of sprites vertically is more efficient and some other useful tips.
31. Don't Scale Images in HTML
OK Daddy. I'll stop using the <blink> tag too. Pinky swear. There are legitimate cases when you _do_ want to do this. If you link to a picture only a little bigger than the space you have for a thumbnail, and don't wan't to waste space/resources to make a thuumbnail, this isn't a bad practice in cases where there are few pictures and the visitor is almost certain to click on them all. Pretty rare use case, but important to consider.
32. Make favicon.ico Small and Cachable
Good recommendations and considerations for something I'd really rather not have to deal with, but now I know I probably should anyway. Apparently it is better to have a really small icon than to not have one at all, and forcing a long cache can help performance.
33. Keep Components Under 25K
Wow, I hadn't really thought about that. But probably something really important to consider. Seems like a pretty extreme case, but good to know. Brings up a good point on the difference between compression and minification.
34. Pack Components Into a Multipart Document
Not very well explained...since this is a feature "some user agents don't support", it sounds pretty iffy.
So In Summary
I have rather mixed feelings about this particular document. I was frankly expecting more, the guy that recommended this is pretty spot on with ideas, but I'm rather unimpressed with this tidbit.
I went back and rated every recommendation with a score between 0 and 3 depending on how useful I thought it would be to "most" developers. I ended up not giving a 0 to anything, I gave 3's to several recommendations that I made rather sarcastic comments to because let's face it, table based layouts are STILL BEING MADE TODAY AS WE SPEAK!
Out of a total possible 102 points, I awarded 83 points.... that's like a B on the 10 point scale and a C on the 7 point scale we used when I was in grade school...twenty 3's, nine 2's, five 1's
Then again. This IS Yahoo we are talking about. I am seriously beginning to have second thought about integrating the YUI Calendar component into a recent project... It wasn't a terribly pleasant experience to start with.