YSlow for Firebug/Firefox
Posted: Mon Sep 24, 2007 7:07 am
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.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
I've been using it both for work and play since it was released.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.
"Instead" implies it duplicates the functionality, and it doesn't do over half the things Yslow does.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.
Development without Firebug? Blasphemous.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.
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.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.
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.AKA Panama Jack wrote:Most of these type of speed tests are based upon access using a 28k dialup modem.
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: For the most part the location of where certain scripts load on a page will have virtually zero impact on a broad band connection.
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:The biggest site slow down is media content where the site uses way too many images or images that have not been compressed well.
Two different issues.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.
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:Some of their rules are quite frankly laughable.
Which Yslow tests for.AKA Panama Jack wrote:Use gzip to compress all output.
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.AKA Panama Jack wrote:Check out our AATraders site.
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: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: For the most part the location of where certain scripts load on a page will have virtually zero impact on a broad band connection.
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: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:The biggest site slow down is media content where the site uses way too many images or images that have not been compressed well.
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:Two different issues.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.
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.
Cute, you take the speed test page out of context to try and prove your point but fail.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.
And you don't need a plugin for that.The Phoenix wrote:Which Yslow tests for.AKA Panama Jack wrote:Use gzip to compress all output.
LOL! The iPhone is notoriously SLOW as it uses an outdated and slow connection protocal.The Phoenix wrote: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.AKA Panama Jack wrote:Check out our AATraders site.
I do understand, you are focusing on page size (transfer rate) and ignoring network performance.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.
The time to load the page was almost the same? So now 90k of javascript is instantly downloaded? That makes no sense.AKA Panama Jack wrote: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: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:The biggest site slow down is media content where the site uses way too many images or images that have not been compressed well.
Read up on http pipelining at Mozilla's developer FAQ. The spec itself says: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.
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: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.
Sorry, but I'm not. Here's a good blog post about it, including tests you can run.AKA Panama Jack wrote:And you are wrong about having to wait to render the page.
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: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.
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: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.
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.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.
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.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.
Your site is slow rendering on the iPhone even over 802.11, but my point WAS the slow connection rendering.AKA Panama Jack wrote:LOL! The iPhone is notoriously SLOW as it uses an outdated and slow connection protocal.![]()