I’m using classic ASP on IIS6 and am trying to following YSlow’s recommendation to flush the content early, just after the page header. If compression is disabled then this works a treat, the browser starts downloading the css and images from the header before the rest of the page is received. However, if compression is enabled in IIS (either gzip or deflate) then the browser waits until all the content has been received before downloading any of the other items from the page, I’m using Chrome and Firefox to test this.
Interesting the time to first byte is much lower if I flush early, but the browser doesn’t attempt to render any of the content.
I have read it’s possible do flush early with compression enabled in Apache, does anyone know if it’s possible to do this with IIS6?
Interesting that would cause your data to not flush early. Though, i wouldn’t worry about lowering the compression. With gzip, most of the size reduction is done with the basic compression itself. The higher compression levels just utilize more stringent binary compression, that while it will reduce the file size even more, the change is not as dramatic as the base file versus the basic gzip. I’d actually say its almost a waste to go too high on the gzip compression, as the return if not worth the amount of cpu usage after a certain point.
I wonder if the issue was related to a buffer size somewhere in the pipeline where the lower compression value just happened to cause the data to be big enough to fill the buffer.
Glad to hear you got it working. Sucks that it’s usually voodoo/trial and error to figure it out.
Yeah, that is probably why. Our version of apache has a similar issue. I forgot about needing to add fake data to the header section of our site when I was experiementing with early flushing. It is indeed trial and error for such things.