Page 1 of 1

YSlow for Firebug/Firefox

Posted: Mon Sep 24, 2007 7:07 am
by CoderGoblin
Just came across this but don't have time to look at it in detail... Anyone tried YSlow for Firebug ? It's supposed to help identify slow points in a web page.

Posted: Mon Sep 24, 2007 8:38 am
by onion2k
It's part of my toolkit ( http://www.ooer.com/31/A-Web-Developers-Toolkit ). It's useful, but you need to ignore some of the things it suggests because they're targeted at massive websites. Most of it is good advice though.

Re: YSlow for Firebug/Firefox

Posted: Mon Sep 24, 2007 10:11 am
by The Phoenix
CoderGoblin wrote:Just came across this but don't have time to look at it in detail... Anyone tried YSlow for Firebug ? It's supposed to help identify slow points in a web page.
I've been using it both for work and play since it was released.

Its biggest strength is that it helps highlight issues that people are generally not aware of - caching, reducing http requests, and compression.

There are issues that it brings up (like using a content delivery network) that are overkill for the average site, but that is changing. Even medium sized sites are now gaining benefits from CDN's. With incredibly afforable offerings like Cache Fly, you can get a worldwide CDN for less than the cost of a hosting plan each month. That can mean your site goes from reasonably slow to screaming fast for most visitors in the world, at only $15 a month.

Granted, its not worth it for Bob's homepage, or Tina's blog, but for a small business with a couple hundred orders a month even, its very worthwhile.

Personally, I love that its bringing one-click knowledge to users that wouldn't normally dig in and ask questions like "why don't we compress our javascript". Thats worth its weight in gold.

Posted: Mon Sep 24, 2007 3:55 pm
by AKA Panama Jack
You could use this instead...

http://www.sitereportcard.com

It identifies quite a few things and you don't need a browser plugin so it works with any browser.

Posted: Wed Sep 26, 2007 12:27 am
by The Phoenix
AKA Panama Jack wrote:You could use this instead...

http://www.sitereportcard.com

It identifies quite a few things and you don't need a browser plugin so it works with any browser.
"Instead" implies it duplicates the functionality, and it doesn't do over half the things Yslow does.

Besides, Yahoo publishes the rules, so you can simply *read* them, instead of running the test interactively if you don't want to use Firefox.

But if you really want an interactive site for testing, you can cover almost every base with UI Test.

Posted: Wed Sep 26, 2007 12:33 am
by Josh1billion
I haven't heard of Firebug before.. I saw this thread title and thought it was a diss against Firefox, accusing it of being buggy.

This YSlow thing sounds very useful. I'm going to install it right now...

edit- Pretty interesting stuff. Ten suggestions total, and your page is rated A through F on how well your page incorporates those suggestions. Some of the suggestions seem that they would not matter in most cases, however, such as one suggestion which basically suggests uploading your images across multiple webservers instead of all on just one. I believe the speed difference there would, in most cases, be very minor and unimportant-- probably not something you'd want to invest the time to go back and change.

To put this all in perspective, this "posting.php" page of phpBB gets five A's, two F's, a B, a C, and an N/A on the ten categories, with an overall grade of D. At the same time, the page loaded very quickly for me. So you can see how a lot of this stuff is theoretical, in-the-long-run stuff which would maybe be useful to big sites like Amazon and not immediately practical to most people. What I'm saying is that you could apply all of YSlow's suggestions and your naked eye probably wouldn't notice any difference in page loading speeds whatsoever.

There's my summary. :)

Posted: Wed Sep 26, 2007 7:48 am
by superdezign
Josh1billion wrote:I haven't heard of Firebug before.. I saw this thread title and thought it was a diss against Firefox, accusing it of being buggy.
Development without Firebug? Blasphemous. :P

Posted: Wed Sep 26, 2007 2:01 pm
by AKA Panama Jack
Josh1billion wrote:To put this all in perspective, this "posting.php" page of phpBB gets five A's, two F's, a B, a C, and an N/A on the ten categories, with an overall grade of D. At the same time, the page loaded very quickly for me.
Most of these type of speed tests are based upon access using a 28k dialup modem. Trying to get the most speed out of the site for those connections. For the most part the location of where certain scripts load on a page will have virtually zero impact on a broad band connection. The biggest site slow down is media content where the site uses way too many images or images that have not been compressed well.

I find it really laughable that they claim that placing style sheets at the top of a document make it load faster. That is 100% total BS. In some browsers if you place all style sheets in the head the style sheets will be loaded before other content like images. This will make it APPEAR the page loads faster in some browsers like Opera but it DOES NOT load faster. If you time the pages over a series of page loads without the use of caching you will find the time it takes to RENDER FULLY the entire page is not affected by the location of style sheets or javascript files.

Some of their rules are quite frankly laughable.

There are just a few simple rules that should be used.

Use gzip to compress all output. If possible use it site wide so all content including externally loaded, from the same site, CSS and Javascript is compressed.

Make sure all media files use the highest possible compression while retaining the best quality. Paint programs like JASC Paint Shop Pro can compress image files with far higher quality than Photoshop.

Whenever possible use CSS instead of images for site design.

That's the basics that most designers/programmers should use if they want to keep a small download footprint.

I have found that the biggest problem for site speed is the lack of use of gzip. Even Yahoo fails in that respect. Their own YSlow users guide site FAILS on the gzip end. Even though they mention using gzip they don't even use it. You can check it out here...

link

That HTML download is almost 29k in size. If they had gzip enabled it could be as low as 5-7k in download size.

Check out our AATraders site.

link

It is only a 15k download with gzip enabled. If we weren't using gzip the html download would have been 86k!

So the number one rule for fast site download is using gzip wherever possible.

Many major, high traffic sites like CNN use gzip site wide.

link

For the most part YSlow is more of a straw man than anything really useful.

Posted: Thu Sep 27, 2007 9:53 am
by The Phoenix
AKA Panama Jack wrote:Most of these type of speed tests are based upon access using a 28k dialup modem.
Its really a range of non-broadband speeds, up to 56k, but you've got the right idea. Keep in mind that most mobile devices (iPhones, Nokia communicators, etc) are in this range of speed, and most areas in the US (rural) are also stuck at these speeds.

Depending on which statistics (damned lies?) you choose to accept, broadband use in America is as low as 50%.
AKA Panama Jack wrote: For the most part the location of where certain scripts load on a page will have virtually zero impact on a broad band connection.
That depends on the size of the scripts. Some sites have more size in the scripts than in the actual page, and by putting the scripts in the proper place, the page will render first, and then load the script. It is less noticable on broadband, but it still does have an impact.
AKA Panama Jack wrote:The biggest site slow down is media content where the site uses way too many images or images that have not been compressed well.
Thats not always true. As an example, check out the comparison shopping engine, mytriggers.com. It has ~30x more size in javascript (90k) than it does in images (3.5k) for the main page. The images aren't slowing the site down, the javascript is.
AKA Panama Jack wrote:I find it really laughable that they claim that placing style sheets at the top of a document make it load faster. That is 100% total BS. In some browsers if you place all style sheets in the head the style sheets will be loaded before other content like images. This will make it APPEAR the page loads faster in some browsers like Opera but it DOES NOT load faster. If you time the pages over a series of page loads without the use of caching you will find the time it takes to RENDER FULLY the entire page is not affected by the location of style sheets or javascript files.
Two different issues.

Having the style sheet at the top of the page means that the rendering engine can start rendering. Without the style sheet, it has to wait until the entire page is loaded, AND the stylesheet is loaded before it can begin rendering. It also means that it has to wait to load background images until those are loaded. Which means you get one request going for a long time, and then a whole bunch of requests at the end. Since http is allowed to send up to three concurrent requests at once, that can in fact cause a real delay.

But the other issue is that you are laughing away the issue of user perception. Page rendering makes a tremendous difference, especially on non-broadband connections. If the page renders in 2 seconds, but takes 10 seconds to load all the bells and whistles, most users are going to be much more pleased. In fact, its so important that the browser speed test that you include in your own signature file even tests for it.
AKA Panama Jack wrote:Some of their rules are quite frankly laughable.
I'm interested in exampels of which rules have no impact on users. You've listed one rule, and claimed that its not a large impact on some users (impact), and that other issues could have more impact - but thats a long way from showing the rule to be incorrect and thus "laughable".
AKA Panama Jack wrote:Use gzip to compress all output.
Which Yslow tests for.
AKA Panama Jack wrote:Check out our AATraders site.
I did - on my iPhone. Ignoring the flash items that wouldn't display, the site is *very* slow - even over wireless access. It renders a blue screen, then adds in the header and the center content, then takes a while to get the side content. Finally, it sits for several seconds trying to get the remaining items which blocks the ability to move the screen around until it is done. Surprisingly, despite the tag soup table layout, it renders most of it correctly. It just takes a while to render, and until it does, you can't move the screen to get to the content you want.

Annoying.

Posted: Thu Sep 27, 2007 1:49 pm
by AKA Panama Jack
The Phoenix wrote:
AKA Panama Jack wrote: For the most part the location of where certain scripts load on a page will have virtually zero impact on a broad band connection.
That depends on the size of the scripts. Some sites have more size in the scripts than in the actual page, and by putting the scripts in the proper place, the page will render first, and then load the script. It is less noticable on broadband, but it still does have an impact.
You don't seem to understand. I am talking about the total time it takes to completely render the page. The location of where the scripts load in the HTML page makes absolutely ZERO difference in how fast a page will complete loading and rendering.
The Phoenix wrote:
AKA Panama Jack wrote:The biggest site slow down is media content where the site uses way too many images or images that have not been compressed well.
Thats not always true. As an example, check out the comparison shopping engine, mytriggers.com. It has ~30x more size in javascript (90k) than it does in images (3.5k) for the main page. The images aren't slowing the site down, the javascript is.
I checked your site and hate to say it but you are compeltely wrong with your example. With Opera I can edit out the javascript from the page source and reload the page, without image caching. After removing all of the javascript the page was JUST AS SLOW loading. It didn't have to load or execute any javascript but the time to load the page was almost the same. It was still bogged down in loading the image files. Also, the site uses GZIP encoding so the entire content including the javascript and excluding images was around 25k.
The Phoenix wrote:
AKA Panama Jack wrote:I find it really laughable that they claim that placing style sheets at the top of a document make it load faster. That is 100% total BS. In some browsers if you place all style sheets in the head the style sheets will be loaded before other content like images. This will make it APPEAR the page loads faster in some browsers like Opera but it DOES NOT load faster. If you time the pages over a series of page loads without the use of caching you will find the time it takes to RENDER FULLY the entire page is not affected by the location of style sheets or javascript files.
Two different issues.

Having the style sheet at the top of the page means that the rendering engine can start rendering. Without the style sheet, it has to wait until the entire page is loaded, AND the stylesheet is loaded before it can begin rendering. It also means that it has to wait to load background images until those are loaded. Which means you get one request going for a long time, and then a whole bunch of requests at the end. Since http is allowed to send up to three concurrent requests at once, that can in fact cause a real delay.
Actually the number of concurrent requests for HTTP isn't set at 3. It depends upon the server settings and the client browser settings. Most servers allow far more than 3 requests per IP address. And most modern browsers allow the user to set the number of requests per server as high as 128. And you are wrong about having to wait to render the page. If what you claimed was true then pages without loadable style sheets couldn't be rendered as the page was loading. You will find that most modern browsers will start rendering a page irrespective of the location of any CSS and they DO NOT WAIT to for the CSS to load before rendering the page.
The Phoenix wrote:But the other issue is that you are laughing away the issue of user perception. Page rendering makes a tremendous difference, especially on non-broadband connections. If the page renders in 2 seconds, but takes 10 seconds to load all the bells and whistles, most users are going to be much more pleased. In fact, its so important that the browser speed test that you include in your own signature file even tests for it.
Cute, you take the speed test page out of context to try and prove your point but fail. :) The speed test page rates individual execution speeds of different areas of a browser which greatly impacts the time it takes to display a page irrespective of the download time. Nice try though.

A nice examaple is that Opera can start rendering a page as the HTML is loaded and before any javascript or CSS files have been downloaded. So page content can be viewed and interacted with before the CSS files have loaded. But there are still some browsers that will not display a page until all content has downloaded.

But the bottom line is that it still takes just as long for a page to fully render no matter where you place the downloadable CSS tags in the HTML page. Placing them at the top will not make the page render any faster than placing them at the bottom. But I do agree that placing them at the top is better for debugging reasons. Not having to search the entire document, when working on someone elses code, for the CSS load tags is less time consuming.
The Phoenix wrote:
AKA Panama Jack wrote:Use gzip to compress all output.
Which Yslow tests for.
And you don't need a plugin for that. :)

Using http://web-sniffer.net/ is far better as it will allow you to test any site for any type of connection. You can also test using different browser tags. It will display the header content, source code of the page as well as compressed and uncompressed file size. Just add a bookmark and no need to install a plugin and it works with ANY web browser. :D
The Phoenix wrote:
AKA Panama Jack wrote:Check out our AATraders site.
I did - on my iPhone. Ignoring the flash items that wouldn't display, the site is *very* slow - even over wireless access. It renders a blue screen, then adds in the header and the center content, then takes a while to get the side content. Finally, it sits for several seconds trying to get the remaining items which blocks the ability to move the screen around until it is done. Surprisingly, despite the tag soup table layout, it renders most of it correctly. It just takes a while to render, and until it does, you can't move the screen to get to the content you want.
LOL! The iPhone is notoriously SLOW as it uses an outdated and slow connection protocal. :D That's been one of the complaints about the iPhone. There are other browser able phones that use a faster connection protocal and will display web pages much faster. :D Just because it's from Apple doesn't mean it is all great. ;) I just tried the site on Safari, Firefox, Opera and IE and it loaded in about 5 seconds. I know the site coding isn't great but your example just doesn't wash, as usual. Make sure you have enabled gzip support in Safari on your iPhone. I would expect it to be slow if you disable gzip in Safari coupled with the slow protocal used by the iPhone. Downloading uncompressed 87k HTML plus 80k of images will take awhile on the iPhone. But if you you enabled gzip that is only a 15k download. The page will render instantly and then you have to just wait for the 80k of image data to download. You might want to wait until they come out with the new iPhones using the faster wireless protocal. :)

Posted: Thu Sep 27, 2007 3:54 pm
by The Phoenix
AKA Panama Jack wrote:You don't seem to understand. I am talking about the total time it takes to completely render the page. The location of where the scripts load in the HTML page makes absolutely ZERO difference in how fast a page will complete loading and rendering.
I do understand, you are focusing on page size (transfer rate) and ignoring network performance.

if you can load the css & js & images *while* loading the main page, thats 3 requests running at the same time. You are looking at the content as if the raw size is the only factor. The size isn't even the biggest factor - network responses are. By allowing the requests to run concurrently, it does move faster, because you don't have 1 hop slowing down all future parts of the request. A single page we looked at has 11 elements, and each can have 9 hops between the user and the site (on average - some sites are higher, some lower). Thats literally 99 points before the page finishes loading. If one hop gets slow, every request after that delays.

Thats why placement does matter, because concurrent requests means parallel execution, and that does speed things up - even in a finite pipe. The finite connection isn't reaching its maximum because network delays keep it far from 0 ms response speeds. :)
AKA Panama Jack wrote:
The Phoenix wrote:
AKA Panama Jack wrote:The biggest site slow down is media content where the site uses way too many images or images that have not been compressed well.
Thats not always true. As an example, check out the comparison shopping engine, mytriggers.com. It has ~30x more size in javascript (90k) than it does in images (3.5k) for the main page. The images aren't slowing the site down, the javascript is.
I checked your site and hate to say it but you are compeltely wrong with your example. With Opera I can edit out the javascript from the page source and reload the page, without image caching. After removing all of the javascript the page was JUST AS SLOW loading. It didn't have to load or execute any javascript but the time to load the page was almost the same. It was still bogged down in loading the image files. Also, the site uses GZIP encoding so the entire content including the javascript and excluding images was around 25k.
The time to load the page was almost the same? So now 90k of javascript is instantly downloaded? That makes no sense.

The javascript is larger than everything else on the page request *combined*. If thats not affecting your load times, you just aren't able to detect the difference (yay for your browser & connection), but that doesn't change the reality for slower connections. 90k is several *seconds* of delay on a slower connection.

Further, the site doesn't use gzip for images or javascript. Check using the web sniffer page you offered up.

The page is, the elements in it are not.
AKA Panama Jack wrote:Actually the number of concurrent requests for HTTP isn't set at 3. It depends upon the server settings and the client browser settings.
Read up on http pipelining at Mozilla's developer FAQ. The spec itself says:

The spec itself says: "A single-user client SHOULD NOT maintain more than 2 connections with any server or proxy".

Internet Explorer obeys it. Firefox does as well.
Opera uses heuristics to determine the best setting, but I haven't found a solid link documenting its range (ie, does it exceed it?).

A good writeup is available on Wikipedia, as usual.

So yes, you can modify it, and yes, the server AND client can modify it, the default and most common scenario, is that it doesn't go beyond 3.
AKA Panama Jack wrote:Most servers allow far more than 3 requests per IP address. And most modern browsers allow the user to set the number of requests per server as high as 128.
Opera doesn't allow you to set it, does that make it not a modern browser? Couldn't resist. Does IE? That just leaves Firefox, ahead of the game as usual? :)
AKA Panama Jack wrote:And you are wrong about having to wait to render the page.
Sorry, but I'm not. Here's a good blog post about it, including tests you can run.

Modern browsers have a parse tree that they have to work through, and until they have javascript & css, it could change. So that they don't have to do a redraw, they delay.

Thats why javascript has a 'defer' element, and why you can move the css to different parts of the page.
AKA Panama Jack wrote:Cute, you take the speed test page out of context to try and prove your point but fail. :) The speed test page rates individual execution speeds of different areas of a browser which greatly impacts the time it takes to display a page irrespective of the download time.
Thats exactly what I said - the execution speed of rendering is independent of the download time, and you are ignoring the execution speed of rendering. The rendering makes a huge difference to users.
AKA Panama Jack wrote:A nice examaple is that Opera can start rendering a page as the HTML is loaded and before any javascript or CSS files have been downloaded. So page content can be viewed and interacted with before the CSS files have loaded. But there are still some browsers that will not display a page until all content has downloaded.
Technically, Opera loads the html page first. Then it parses it, and displays it. Then it loads the other files, and changes to include those elements. Its called a redraw, and its why IE & FF don't do it. You'll notice that Opera often jumps around when displaying a page (its very noticable on slow connections on your main page for example). IE & FF chose to avoid changing the entire look of a page several times during loading.
AKA Panama Jack wrote:But the bottom line is that it still takes just as long for a page to fully render no matter where you place the downloadable CSS tags in the HTML page.
Repetition isn't proof, but considering that Microsoft, Yahoo, Mozilla, and virtually every site optimization page on the internet all lists it as a suggestion, you probably don't want it to be proof.

CSS location does matter to rendering speed.
AKA Panama Jack wrote:Using http://web-sniffer.net/ is far better as it will allow you to test any site for any type of connection.
Not for local sites that web sniffer can't reach. Plenty of development is done prior to deployment, and oh how helpful it is to have the ability to check without going to an external site. Plus, there are lots of things web sniffer doesn't test.

But hey, if you like external sites, I listed one that does everything that Yslow does - and more. Far more than web-sniffer.
AKA Panama Jack wrote:LOL! The iPhone is notoriously SLOW as it uses an outdated and slow connection protocal. :D
Your site is slow rendering on the iPhone even over 802.11, but my point WAS the slow connection rendering.

It doesn't render instantly in either situation. It renders sections of it, and then delays on several page elements, and then completes.

Go to an apple store and try it out. I guarantee they have 802.11 in the store setup for the iPhones, and I guarantee you'll see what I mean.

Then try it on the slow side, and you'll see its absolutely convincing that page design impacts rendering speed.