Yahoo's YSlow Plug-in Tells You Why Your Site is Slow
Stoyan writes "Steve Souders, performance architect at Yahoo, announced today the public release of YSlow — a Firefox extension that adds a new panel to Firebug and reports page's performance score in addition to other performance-related features. Here is a review plus helpful tips how to make the scoring system match your needs.
Interesting utility. Slashdot gets a D on the homepage, F on a comments page. Many media sites score Fs, mostly thanks to numerous ad and cookie sites.
I bet it doesn't actually tell you your site is being /.ed
[alk]
Web developer(a must-have) has a speed analyzing tool by default (well, more of a link to a website that does the job), I prefer to use that one. Here's an example of slashdot's report.
that's all well and good, but it's slow because of the server-side scripts, not anything client side. and no browser plugin will ever know that.
Saw this demoed at web2.0 This is a very useful plugin. Especially so for developers who may not be familiar with a lot of the reasons sites can load or feel slow.
The damned article makes a point to say it is an extension to Firebug not Firefox. Whats the difference?
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
Nice one Yahoo. Now people can optimize their website without bothering to read up on HTTP and thinking about what they're doing.
Since 9/10 web developers can't even be bothered using a validator, I predict great success for this tool.
Sites are only as fast as the slowest path through the site.
If your site has 10 different affiliate links/sponsors, all hosted on different providers, your site will be slow.
Similarly, if your site has 100 different java/javascript crapplets,widgets, your site will be even slower.
Here is a simple guide for site creators:
1. Don't overload on ads, I'm not going to view them anyway
2. Put some actual content I'm interested in on your site
3. Don't overload me with java/javascript crap, I don't care what my mouse pointer looks like, just let me click
4. Not everything needs a php/mysql front/back end.
Feel free to use this as a guide, and I might just visit those sites.
Why are people developing web apps commercially when they can't even be bothered reading the HTTP RFC's?
Don't you mean Slowverlords? :D
F: You are co-located at 365 Main.
sarchasm: The gulf between the author of sarcastic wit and the person who doesn't get it.
Interesting approach, with lots of flaws.
For example "use CDN" (aka Akamai, etc.) - yeah, right. For Yahoo.com that's an idea. For my private website, that's bullshit. If they really use this internally to rate sites, their rating sucks by definition.
So in summary there are a couple good points there, and a couple that are not really appropriate. Expires: Headers are a nice idea for static webpages. But YSlow still gives me an F for not using one on a PHP page that really does change every time you load it.
Assorted stuff I do sometimes: Lemuria.org
Finally, someone tells what web developers have known for years: optimizing the site is not a matter of splitting your content into as many images as possible over an enterprise app, but good clean design and code.
For years, as a web designer, every time I got ready to deploy I encountered some nitwit who would say, "You're going to break up that giant image, aren't you? We can put it on nine servers!" -- creating organizational havoc, a completely unmanageable asset mess of a project, and driving everyone nuts. The Souders-Yahoo approach is different. He suggests the obvious, which is have fewer page elements, stick them into the HTML code if possible, and trim that ragged mess of Java and CSS.
Also, as a technical writer, I'm impressed whenever someone gets paid to write down the obvious.
technical writing / development
You have to build up your resume some how in order to keep your job or to get a better one. What better way than to develop shit that the project really doesn't need but will sure look great on a resume!
And it's not just techies. Back in the mid nineties, it seemed that every CIO was moving his system from mainframe to distributed architecture. And then in the late 90s, it became moving the company onto the web. One project I was on had three different CIOs by the time it was done because they all went on to better things - thanks to the project building their resumes.
That's the way it is. IT is so "latest and greatest technology" centered that you have no choice. Otherwise, you're out of date and work dries up REAL fast. You always have to keep your skills up to date! Huh my fellow old timers?
I prefer Flambe as apposed flamebait.
it does run on Linux. :-)
The game.
Lets you figure out why your site is slow, eh? Cool! Now if only the web developers at Yahoo could use this wonderful tool to learn how to make their script-laden web pages (yes, Yahoo Mail Beta, I'm looking at you) load on my laptop in under 30 seconds. :)
[b.belong('us') for b in bases if b.owner() == 'you']
If ever there was a time for this tag, this is it!
I've said this for a long time, website developers need to test their sites with a dialup account. In the US this is still at least 30% of the web surfing public using dialup (mostly from no choice in the matter). If you'll optimize and test for different browsers, even those with tiny marketshare, why not for speed as well? Just because the devs might have a fast net connection and an over 20 inch monitor with the latest videocard(s) installed and a fast machine with gigs of RAM, doesn't mean your potential customers have all that. I know to me, being on dialup, it's maddening sometimes, if I want to view a site that requires a lot of images and scripting turned on, it *does* take minutes sometimes for a single page to load, and that damn Flash is about the worst there is now. At least provide a low-res version of your site, with an obvious easy to see link on the very first page so folks who need to can switch over. Example of where they "get it" on this idea, nasa.gov, a very nice site that has three versions, flash, no flash, or real low res, the latter being much better for slower connections, slower machines or to make the site more accessible for those with visual problems, etc. Depending on your needs, you can pick which version you want and still access content reasonably, and still navigate. To me, that is the sign of real professional web developers.
Interesting they rate down the comments pages on bannination.com because they have stylesheets outside the document head, yet why i look at the code the stylesheets are where they are supposed to be... weird.
I think I'd prefer it to use a bit more realistic reporting. How about: 1) Your web developer is a complete incompetent. 2) Buy more hardware, tightwad. 3) There is no need to add every script plugin you come across. 4) Animated gif's are annoying as well as slow to load. 5) Yes, it does take time to download and render an entire book in html.
A couple of 30-somethings embark on the ultimate roadtrip
I'm sending something showing that the file is already expired (since it's completely dynamic) and apparently that still gets an F.
Not too impressed
YSucks - reveals why your site sucks.
YMe - translates your site into emo-speak.
stuff |
The Anonymous Coward here is spot on. This thing gives awful, awful advice. Some of these in particular I really hated as a dialup user.
This is only a win if your images are tiny. Why are you optimizing for this? Tiny images do not take long to download, even on dialup, because they are tiny. Frankly I would prefer to have all the site's little icons progressively appear as they become available than have to wait while a single image thirty times the size of any one of them loads. Or, perhaps, fails to load, so that I have to download the whole thing again instead of just the parts I have.
This is hands down the stupidest idea I have ever heard. Ignoring for the moment that it won't even work for the 70% of your visitors using IE, sending the same image multiple times as base64-encoded text will completely swamp any overhead that would have been introduced by the HTTP headers.
Less egregious than suggesting CSS Sprites, but it still suffers from the same problems. These are not large files, and if they are large files, the headers are not larger.
What, seriously? Are you really optimizing for your visitors who load one and only one page before their cache is cleared? Even though you "measured... and found the number of page views with a primed cache is 75-85%"?
And if you ever change something but forget to change the file name, your visitors will have to reload everything on the damn page to get the current version of the one thing you changed. Assuming, of course, they even realize there should be a newer version than the one they're seeing. And assuming that they actually know how to do that.
Um. Duh? link elements are not valid in the body. style elements are
In my experience "slow" is a very subjective measure of a web site. It really depends on how quickly the content is displayed, not how quickly the entire page is loaded and rendered.
Lets say you visit, oh, dilbert.com (just to pick on a geeky site) to get your daily dose of dilbert. If the first thing that is rendered on your screen is the actual comic, you don't really care that it takes another 10-20 seconds to display the buttons, menus, sidebars, topbars, bottombars, animations, ads and ads for ads. It can do that while you chuckle over the comic.
On the other hand, if you have to sit there and drum your fingers while all the other crap loads first before you get to look at todays dilbert, then you are going to be muttering "why is this site so freaking slow?" And if wwww.weselladstoadserversbythebillions.com got it's DNS server taken out by a freak lightning strike, you could be sitting there a while.
Would it be possible to have a plug-in or extension, so that I could right click on the actual content of a site and say "next time I visit here, load this bit first?" Yes, I could just block everything else on the site, but then they'll change it a week later, and some of the non-content stuff might actually be useful on occasion. I don't want to have to be in an arms race with a million web-monkeys on a thousand different sites just to browse my RDA of surfing.
What, seriously? Are you really optimizing for your visitors who load one and only one page before their cache is cleared? Even though you "measured... and found the number of page views with a primed cache is 75-85%"? Daily Visitors != Page Views
Making up random numbers and fudging to a perfect caching system for convenience:
10 people hit your site on a given day.
3 have never been there before, have an empty cache, say, "Damn, this shit's slow," and leave.
2 have never been there before, have an empty cache but endure, surfing 5 pages each.
The other five are regular users and have files cached. They surf the same 5 pages.
Total: 3x1 + 2x(1+4) + 5x5 = 38 total pages.
(5 out of 10) 50% of daily visitors had an empty cache.
(5 out of 38) 13% of page requests hit with an empty cache.
(33 out of 38) 87% of page requests hit with a primed cache.
So, both quotes are correct: 50% of daily unique visitors came in with an empty cache, 87% of total page requests were made with a primed cache.
Obviously those numbers are pulled out of my anatomical
Both numbers are important. By looking at the gulf between them, you can start to build up an impression of what new users vs. what returning users do with your site.
Similarly, both types of users are essential:
Sure, you want to ensure new users love the site and become repeat users. So you want to optimize for them. But you don't want to do this at the cost of returning users or they'll come, love the experience, decide to return, discover it sucks, then leave again.
In the same way, you want to ensure your existing users have a site they love and don't defect. So you want to optimize for them. But you don't want to do this at the cost of the site sucking so much for new users none of them convert in to repeat users in the first place.
It's a classic case of all things in moderation: If you're going to one or other extreme, you're probably hamstringing yourself. If you're picking somewhere in the middle, informing yourself with the statistics, getting the best understanding of where that sweet spot lies, you're probably going to be far more successful.
The people who fail are the ones who say, "Statistics show that 85% of page views are hitting with a primed cache! We should always plan for that." and go off after what's actually only 50% of total users - they'll lose all new traffic and their site will slowly die. So will the people who say, "50% of daily visitors have an empty cache! We should always plan for that." and go after what're only 15% of the total site's experience. The wiser people say, "Hmm, 50% of unique users hit with an empty cache, 85% of page views have a primed cache. That implies we're getting a lot of new users coming in that we should accomodate but that most of our total traffic is to established users. We should find a healthy balance point for both."
...AT&T protection money for your packets.
-ted
Now, if Yahoo would only use it on their own sites to find out why they are always so darn slow.
Would you really trust anything that Yahoo puts out? Yahoo has previously ratted on journalists and bloggers to the Chinese Authorities. Worse: They were unapologetic about it, and kept doing it. One Yahoo 'satisfied customer' got ten years jail for criticizing the Government.
m lu siness/12search.html?ex=1185508800&en=a0a01819d3ec c0ca&ei=5070
So when Yahoo trundles along offering me neat tracking software, umm, no thanks. There's no telling where you might end up reading about it. Now sure, in the U.S. you don't get locked up for criticizing the government, but things do get leaked or given to the wrong people. Anyone who has ever written a comment that was less that P.R.-worthy should consider that. Yahoo has shown itself to be less than trustworthy.
http://www.csmonitor.com/2005/0909/p01s03-woap.ht
http://www.rsf.org/article.php3?id_article=14884
http://www.nytimes.com/2005/09/12/business/worldb
Dude, the guys at Exceptional Performance aren't some kind of secret cabal.
You can't read (much) from /dev/null, and your numbers don't look like they come from /dev/zero either — those would be rather repetative.
I think, you meant /dev/random...
In Soviet Washington the swamp drains you.
Hopefully this are not the same people at Yahoo that tell he world to send 404 instead of 410 return code for deleted pages. K<0>
Busy helping non technical users of OpenOffice.org - http://plan-b-for-openoffice.org/