Hi Everyone,

I have a problem with Expire header. There are 9 static components without a
far-future expiration date. I dont know hoe to fix the expire header. I am using
this code for expire header.

<ifModule mod_expires.c>
   ExpiresActive On
   ExpiresDefault A0
   ExpiresDefault "access plus 10 years"
   ExpiresByType text/html A25920000
   ExpiresByType image/gif A25920000
   ExpiresByType image/jpeg A25920000
   ExpiresByType image/png A25920000
   ExpiresByType image/ico A25920000
   ExpiresByType text/css A25920000
   ExpiresByType text/javascript A559200000
   ExpiresByType application/x-javascript A559200000
</ifModule>

Url for site:
http://flavorwire.projectsjunction.com/

Hi,

Does anyone know what the expected behavior should be if both etags
and max-age is configured on an object? My understanding was that if
an object had an etag it always took precedence over a max-age and
caused an INM to be sent an a 304 response if the ETag did not change.
  I read recently that they can be used together and that the behavior
would be that once the object expired it would then use the Etag to
perform a INM request to the origin.  Can anyone clarify this?  I can
probably setup a test for this when I have a moment to verify but
wanted to see what you all thought.  Thanks

- Justin Lintz

The documentation doesn't explicitly define how YSLOW calculates the response
time for each component's in the beacon's 'comps' array, as opposed to the full
page load time ('lt') being measured from the previous page onunload event as
documented in the FAQ.

We've been running page load time measurements on a regular basis on our sites,
and we notice that the beacon returns in nearly 40% of cases a page load time
that is lower than the actual response time of the 1st element in the comps
array. See the example below. Sometimes that 1st comp's response time is around
60+ seconds, even though the lt is still around 1+ seconds.

This doesn't seem to make sense. The first element in the comps array is usually
the page's main document request. We would expect that response time to be at
least lesser than the time it takes for the initial document + all sub-object
beforeOnLoad to load, no? Please clarify this for us.

output of the YSLOW JSON beacon collected in a PHP script:
stdClass Object
(
     [w] => 196105
     [o] => 70
     [u] => http://testpage.com/onepage.php
     [r] => 67
     [s] =>
     [i] => ydefault
     [lt] => 803
[...]
     [comps] => Array
         (
             [0] => stdClass Object
                 (
                     [type] => doc
                     [url] => http%3A%2F%2Ftestpage.com/onepage.php
                     [size] => 121489
                     [resp] => 1060
                     [gzip] => 21527
                     [cs] => 546
                 )
[...]

clarifying the example:
shouldn't [resp] => 1060 be something smaller/quicker than [lt] => 803?

--- In exceptional-performance@yahoogroups.com, "ct_leblan" <ct_leblan@...>
wrote:
>
> The documentation doesn't explicitly define how YSLOW calculates the response
time for each component's in the beacon's 'comps' array, as opposed to the full
page load time ('lt') being measured from the previous page onunload event as
documented in the FAQ.
>
> We've been running page load time measurements on a regular basis on our
sites, and we notice that the beacon returns in nearly 40% of cases a page load
time that is lower than the actual response time of the 1st element in the comps
array. See the example below. Sometimes that 1st comp's response time is around
60+ seconds, even though the lt is still around 1+ seconds.
>
> This doesn't seem to make sense. The first element in the comps array is
usually the page's main document request. We would expect that response time to
be at least lesser than the time it takes for the initial document + all
sub-object beforeOnLoad to load, no? Please clarify this for us.
>
> output of the YSLOW JSON beacon collected in a PHP script:
> stdClass Object
> (
>     [w] => 196105
>     [o] => 70
>     [u] => http://testpage.com/onepage.php
>     [r] => 67
>     [s] =>
>     [i] => ydefault
>     [lt] => 803
> [...]
>     [comps] => Array
>         (
>             [0] => stdClass Object
>                 (
>                     [type] => doc
>                     [url] => http%3A%2F%2Ftestpage.com/onepage.php
>                     [size] => 121489
>                     [resp] => 1060
>                     [gzip] => 21527
>                     [cs] => 546
>                 )
> [...]
>

When I upload more than a few dozen small images in one go, some of them appear
to fail with the following error:

   Upload error: [IOErrorEvent type="ioError" bubbles=false cancelable=false
eventPhase=2 text="Error #2038"]

After retrying or uploading in smaller chunks, the same images often go through.
Is there an official limit, or what's going on here?

Another weird effect is that when I try to re-upload an image that failed,
smush.it appears to reprocess some (but not all) previously uploaded (and
successfully processed) images...

hello
do you remove optimized image by Smush.it service from your server?

Thank you guys for the insights. I do understand YSLOW will re-fetch the
object/document to get a response time when it hasn't been retrieved from
scratch with a 200 OK initially by NET and how the variance in result can come
from the usual misc client and network loads and latencies. I think you guys
should really document that on your beacon section as it can be misleading.

To answer your comment Sergey, indeed you need to be careful on how you
interpret numbers. On our side, we're automating the process and averaging our
results as well as running all tests in a dedicated environment. This is one way
(very far from perfect indeed) to mitigate the huge levels of variance that we
can get from load time measurements. Variance analysis and other calculation
methods could help even further, but because page load times can only be so
representative of what each user will experience, we don't feel the need to dig
any deeper in our numbers.

Another very important factor to our analysis is that we actually use several
measurement methods (for instance local YSLOW tests vs. Gomez). This allows us
to confirm trends much more accurately.

As far as using the score as a sole measurement tool, it's definitely a
possibility in a closed environment (meaning you can measure everything you want
to compare yourself, hence not other people's websites), but if you want to be
able to see what impact your page load time reduction efforts have in the 'real
world' (and by that I mean vs. competitors, vs. a web-wide audience and ....
very importantly, vs. our friends the search engines (G Y and B), you can't rely
on the score only, unless Google recently decided to use the YSLOW score for
what it uses or will use to score page ranks? ;)
Maybe one day so ... but I doubt they'd be going with YSLOW (G-speed anyone?).

--- In exceptional-performance@yahoogroups.com, Sergey Chernyshev
<sergey.chernyshev@...> wrote:
>
> I think that doing "precise" measurements requires different level of setup
> then for ranking.
>
> For precise measurements you need to clean caches, have same connection
> speeds and other characteristics and so on.
> While ranking works across the environments and current testing conditions
> and that's why it's so useful and I'm glad that YSlow took this approach.
>
> I think both approaches have a reason to exist, but we just need to be
> prepared to interpreting the data accordingly.
>
> I mentioned it in my talk about ShowSlow and general approach to collecting
> the data and warn users to be careful in their chase for "precise" data - I
> think that ranking can work better for general analysis of performance
> situation.
>
>         Sergey
>
>
> On Mon, Apr 5, 2010 at 1:56 PM, Antonia Kwok <antoniakwok@...> wrote:
>
> >
> >
> > YSlow finds out the response time of each component in the following order:
> > 1. If the component's load time can be found in Firebug's net panel, and
> > the response of the component is 200 OK, this load time will be used.
> > 2. Otherwise, the response time of the component are measured by requesting
> > the component using XMLHttpRequest.
> >
> > In case #2 is why you are seeing the load time was coming in faster than
> > the first request.
> >
> > The response time column in component view is to provide insight of the
> > component's response when it is requested with an empty cache.  For example,
> > if a page contains an image that is found in cache, YSlow will not show 0
> > response time for the image.  It will make an XMLHttpRequest for the image
> > and show the response time of the XHR.
> >
> > ------------------------------
> > *From:* Patrick Meenan <PatMeenan@...>
> >
> > *To:* exceptional-performance@yahoogroups.com
> > *Sent:* Mon, April 5, 2010 10:41:43 AM
> > *Subject:* RE: [exceptional-performance] Re: irregularity in yslow beacon
> > between page load time and first comp response time
> >
> >
> >
> >  From what I can tell, the problem was that the load time was coming in
> > faster than the FIRST request (not the sum of the requests) which if it is
> > really for the base page in  their case shouldn't be possible.  That said,
> > even when functioning I'd be REALLY surprised if the load time ever matched
> > the sum of the individual requests (because of parallel loading).
> >
> > -Pat
> >
> >
> >
> > *From:* exceptional- performance@ yahoogroups. com
[mailto:exceptional-performance@yahoogroups. com]
> > *On Behalf Of *Antonia Kwok
> > *Sent:* Monday, April 05, 2010 1:37 PM
> > *To:* exceptional- performance@ yahoogroups. com
> > *Subject:* Re: [exceptional- performance] Re: irregularity in yslow beacon
> > between page load time and first comp response time
> >
> >
> >
> >
> >
> > The page load time is measure from the beforeunload event of the previous
> > to the load event of the requested page.  It is often less than the sum of
> > the response time of all components because some of the components are found
> > in cache.  If you clear the cache before you run YSlow on a page, the page
> > load time should be the same as the sum of all response times.
> >
> >   ------------------------------
> >
> > *From:* ct_leblan <ct_leblan@yahoo. com>
> > *To:* exceptional- performance@ yahoogroups. com
> > *Sent:* Thu, April 1, 2010 6:17:30 PM
> > *Subject:* [exceptional- performance] Re: irregularity in yslow beacon
> > between page load time and first comp response time
> >
> >
> >
> > clarifying the example:
> > shouldn't [resp] => 1060 be something smaller/quicker than [lt] => 803?
> >
> > --- In exceptional- performance@ yahoogroups. com, "ct_leblan" <ct_leblan@
> > ..> wrote:
> > >
> > > The documentation doesn't explicitly define how YSLOW calculates the
> > response time for each component's in the beacon's 'comps' array, as opposed
> > to the full page load time ('lt') being measured from the previous page
> > onunload event as documented in the FAQ.
> > >
> > > We've been running page load time measurements on a regular basis on our
> > sites, and we notice that the beacon returns in nearly 40% of cases a page
> > load time that is lower than the actual response time of the 1st element in
> > the comps array. See the example below. Sometimes that 1st comp's response
> > time is around 60+ seconds, even though the lt is still around 1+ seconds.
> > >
> > > This doesn't seem to make sense. The first element in the comps array is
> > usually the page's main document request. We would expect that response time
> > to be at least lesser than the time it takes for the initial document + all
> > sub-object beforeOnLoad to load, no? Please clarify this for us.
> > >
> > > output of the YSLOW JSON beacon collected in a PHP script:
> > > stdClass Object
> > > (
> > > [w] => 196105
> > > [o] => 70
> > > [u] => http://testpage. com/onepage. php<http://testpage.com/onepage.php>
> > > [r] => 67
> > > [s] =>
> > > [i] => ydefault
> > > [lt] => 803
> > > [...]
> > > [comps] => Array
> > > (
> > > [0] => stdClass Object
> > > (
> > > [type] => doc
> > > [url] => http%3A%2F%2Ftestpa ge.com/onepage. php
> > > [size] => 121489
> > > [resp] => 1060
> > > [gzip] => 21527
> > > [cs] => 546
> > > )
> > > [...]
> > >
> >
> >
> >
> >
> >
> >
>

Some of you may have already read this, but just to keep it in the
archives, I'll post it here:

http://www.yuiblog.com/blog/2010/04/08/analyzing-bandwidth-and-latency/

I did some analysis on the network connection that readers of the
yuiblog use and the results are posted above.

Philip

Hello,

I've been having a pesky problem.  I have configured Firefox to automatically
run Yslow whenever I access a site.  I've configured this by tweaking Firefox's
yslow extensions.

The problem is that sometimes Yslow automatically runs, and sometimes it does
not.

I wrote a script that goes through the top 100 Alexa sites and launches a
Firefox instance for each site.  I need each Firefox instance to automatically
run Yslow - otherwise I'll have to click the YSlow icon on the bottom right-hand
corner of the browser 100 times.

The goal is to compute Yslow grades daily for the top 100 Alexa sites.  However,
I won't have much success if I can't automate the process of generating Yslow
grades.

Any suggestions on forcing Yslow to run automatically *every* time Firefox
accesses a new site?  Any special tips or tricks?

Thanks!

//Mark

Should they be broken out into their own component type?

Here is a good test page (2mb of fonts!)

http://hsivonen.iki.fi/doctype/

Also, fonts aren't flagged in the "Compress components with gzip" rule.

test:

http://opentype.info/demo/webfontdemo.html

Rob

> Should they be broken out into their own component type?
>
> Here is a good test page (2mb of fonts!)
>
> http://hsivonen.iki.fi/doctype/
>
>

When I click on the Smush.it link within YSlow (in the Tools area), a new page
opens, but it's completely blank.

Is there another way I can access Smush.it?

Thanks!

I'm looking at a page in YSlow and it has 3 iframes.  Two of them are empty and
so is the third, but it has a src attribute that says src="#".  In the
components view under iframes it shows as the same size as the document but even
slower to download.

My assumption is that because it's referencing the page itself it's actually
calling the page again.  When I add up the size of all the components it makes
sense that it calls this twice.

However I watch the page in the net tab and don't see the page called.

Can someone please give me a ruling on this, is the page actually calling
itself?

Thanks,

j