Search Results

Search found 3 results on 1 pages for 'utt73'.

Page 1/1 | 1 

  • What is recommended minimum object size for gzip performance benefits?

    - by utt73
    I'm working on improving page speed display times, and one of the methods is to gzip content from the webserver. Google recommends: Note that gzipping is only beneficial for larger resources. Due to the overhead and latency of compression and decompression, you should only gzip files above a certain size threshold; we recommend a minimum range between 150 and 1000 bytes. Gzipping files below 150 bytes can actually make them larger. We serve our content through Akamai, using their network for a proxy and CDN. What they've told me: Following up on your question regarding what is the minimum size Akamai will compress the requested object when sending it to the end user: The minimum size is 860 bytes. My reply: What is the reason(s) for why Akamai's minimum size is 860 bytes? And why, for example, is this not the case for files Akamai serves for facebook? (see below) Google recommends to gzip more agressively. And that seems appropriate on our site where the most frequent hits, by far, are AJAX calls that are <860 bytes. Akamai's response: The reasons 860 bytes is the minimum size for compression is twofold: (1) The overhead of compressing an object under 860 bytes outweighs performance gain. (2) Objects under 860 bytes can be transmitted via a single packet anyway, so there isn't a compelling reason to compress them. So I'm here for some fact checking. Is the 860 byte limit due to packet size the end of this reasoning? Why would high traffic sites push this down to the 150 byte limit... just to save on bandwidth costs (since CDNs base their charges on bandwith offloaded from origin), or is there a performance gain in doing so?

    Read the article

  • What is recommended minimum object size for gzip benefits?

    - by utt73
    I'm working on improving page speed display times, and one of the methods is to gzip content from the webserver. Google recommends: Note that gzipping is only beneficial for larger resources. Due to the overhead and latency of compression and decompression, you should only gzip files above a certain size threshold; we recommend a minimum range between 150 and 1000 bytes. Gzipping files below 150 bytes can actually make them larger. We serve our content through Akamai, using their network for a proxy and CDN. What they've told me: Following up on your question regarding what is the minimum size Akamai will compress the requested object when sending it to the end user: The minimum size is 860 bytes. My reply: What is the reason(s) for why Akamai's minimum size is 860 bytes? And why, for example, is this not the case for files Akamai serves for facebook? (see below) Google recommends to gzip more agressively. And that seems appropriate on our site where the most frequent hits, by far, are AJAX calls that are <860 bytes. Akamai's response: The reasons 860 bytes is the minimum size for compression is twofold: (1) The overhead of compressing an object under 860 bytes outweighs performance gain. (2) Objects under 860 bytes can be transmitted via a single packet anyway, so there isn't a compelling reason to compress them. So I'm here for some fact checking. Is the 860 byte limit due to packet size the end of this reasoning? Why would high traffic sites push this lower/closer to the 150 byte limit... just to save on bandwidth costs, or is there a performance gain in doing so?

    Read the article

  • How to detect for screenreaders/MSAA without focusing the flash movie?

    - by utt73
    I am trying to detect for the presence of assistive technology using flash. When a Flash movie holding the actionscript below on frame 1 is loaded (and screenreader chatting to IE or Firefox over MSAA is active -- JAWS or NVDA), Accessibility.isActive() does not return "true" until the movie is focused. Well, actually not until some "event" happens. The movie will just sit there until I right-click it & show flash player's context menu... it seems only then Accessibility.isActive() returns true. Right-clicking is the only way I could get the movie to "wake up". How do I get the movie to react on it's own and detect MSAA? I've tried sending focus to it with Javascript... can a fake a right-click in javascript or actionscript? Or do you know the events a right click is firing in a flash movie -- possibly I can programatically make that event happen? My Actionscript: var x = 0; //check if Microsoft Active Accessibility (MSAA) is active. //Setting takes 1-2 seconds to detect -- hence the setTimeout loop. function check508(){ if ( Accessibility.isActive() ) { //remove this later... just visual for testing logo.glogo.logotext.nextFrame(); //tell the page's javascript this is a 508 user getURL("javascript:setAccessible();") } else if (x<100) { trace ("There is currently no active accessibility aid. Attempt " + x); x++; setTimeout(check508,200); } } /* //FYI: only checks if browser can talk to MSAA, not that it is actually running. Sigh. if (System.capabilities.hasAccessibility) { logo.glogo.logotext.nextFrame(); getURL("javascript:setAccessible();") }; */ check508(); stop(); My HTML: <embed id="detector" width="220" height="100" quality="high" wmode="window" type="application/x-shockwave-flash" src="/images/detect.swf" pluginspage="http://www.adobe.com/go/getflashplayer" flashvars="">

    Read the article

1