search

google-code-export / wro4j

Automatically exported from code.google.com/p/wro4j
1 stars 1 forks source link

Browser loads optimized script/css and then waits for 20 seconds... #171

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Please see the attached screenshot
It looks like wro4j sends optimized resource and then keeps the stream open or 
something like this. So browser receives the whole script/css and then still 
waiting for something until timeout. This problem appears in IE9 and Firefox 
3.6 and doesn't appear in Opera 11.01. This happens in wro4j 1.3.4 release only 
(it was ok in a 1.3.4-snapshot 2 weeks ago)

Original issue reported on code.google.com by eum...@gmail.com on 17 Feb 2011 at 8:07

Attachments:

GoogleCodeExporter commented 9 years ago 
here's piece of web.xml:

<filter>
        <filter-name>WebResourceOptimizer</filter-name>
        <filter-class>ro.isdc.wro.http.WroFilter</filter-class>
        <!-- раскомментировать для деплоймента -->
        <!--init-param>
            <param-name>configuration</param-name>
            <param-value>DEPLOYMENT</param-value>
        </init-param-->
        <init-param>
            <param-name>disableCache</param-name>
            <param-value>true</param-value>
        </init-param>
        <init-param>
            <param-name>cacheUpdatePeriod</param-name>
            <param-value>0</param-value>
        </init-param>
        <init-param>
            <param-name>managerFactoryClassName</param-name>
            <param-value>ro.isdc.wro.extensions.manager.ExtensionsConfigurableWroManagerFactory</param-value>
        </init-param>
        <init-param>
            <param-name>uriLocators</param-name>
            <param-value>servletContext</param-value>
        </init-param>
        <init-param>
            <param-name>preProcessors</param-name>
            <param-value>cssImport,bomStripper,semicolonAppender,lessCss</param-value>
        </init-param>
        <init-param>
            <param-name>postProcessors</param-name>
            <param-value>cssVariables,cssMinJawr,jsMin</param-value>
        </init-param>
    </filter>

Original comment by eum...@gmail.com on 17 Feb 2011 at 9:29

GoogleCodeExporter commented 9 years ago 
That's strange, because there were no functional changes since the 2 weeks 
snapshot version. I'll investigate the problem. Thanks for reporting.

Original comment by alex.obj...@gmail.com on 17 Feb 2011 at 4:38

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 17 Feb 2011 at 4:38

GoogleCodeExporter commented 9 years ago 
Actually this has nothing to do with wro4j. The onload time is related to 
client-side processing. You can see that by accessing a static resource (ex: 
http://l.yimg.com/d/lib/bc/bc_2.0.5.js) this is a definitely a static resource 
hosted by yahoo CDN - its onload event is taking much more longer than the time 
taken by the  script to load.

Original comment by alex.obj...@gmail.com on 17 Feb 2011 at 4:50

GoogleCodeExporter commented 9 years ago 
Here's the difference in the headers (same css file). 1.3.4 release adds 
"no-cache" headers. Different content-length (although the css is the same!). 
Both requests don't use cached CSS. Could you explain please why the one from 
release version takes 10 times longer onload time? 20 seconds for client-side 
processing of a static file which shouldn't be processed at all...

Original comment by eum...@gmail.com on 18 Feb 2011 at 6:41

Attachments:

GoogleCodeExporter commented 9 years ago 
May it be possible that 1.3.4 release gives the wrong content-length header 
(e.g. unoptimized size) and browser receives optimized content and then waits 
for the rest of content-length until timeout?

Original comment by eum...@gmail.com on 18 Feb 2011 at 6:59

GoogleCodeExporter commented 9 years ago 
I'll investigate this... Until I'm not sure what could cause the problem, I'll 
leave the status of the issue as New

Original comment by alex.obj...@gmail.com on 18 Feb 2011 at 7:57

GoogleCodeExporter commented 9 years ago 
You are right, it seems that setting the content-length is the problem. 

wro4j filter sets the content-length based on the size of the resource content, 
which is wrong when the resource is gzipped. 

I'll fix this problem for the next release by not setting the content-length 
from the filter.

Thanks for reporting this one.

Original comment by alex.obj...@gmail.com on 18 Feb 2011 at 1:58

GoogleCodeExporter commented 9 years ago 
Fixed in github 1.3.x branch (future 1.3.5 release)

Original comment by alex.obj...@gmail.com on 18 Feb 2011 at 2:54

GoogleCodeExporter commented 9 years ago 
This is related to issue 173

http://code.google.com/p/wro4j/issues/detail?id=173

Original comment by eli.will...@gmail.com on 25 Feb 2011 at 9:49

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 25 Feb 2011 at 9:58