This patch (which should be applied on top of the #100516 patch):
- Adds an option to the settings to gzip this cached file.
- If enabled then it gzips and saves a .css.gz file in addition to the regular .css file and...
- Adds a .htaccess rule to use this file if the browser accepts gzip and the gz file exists.
As you can see, it is a very simple addition, but should be very valuable for heavy sites. Apart from the time saved for users, there is a 16Kb bandwidth saving too - potentially several GB of bandwidth a year for a site with several 100K visitors.
I currently have this flagged as a feature request for 5.0, but it could very well be considered a usability enhancement.
Here are my original benchmarks:
HEAD Total Transfer Duration Page Duration Test 1 12798 8756 8454 Test 2 12984 8907 8162 Test 3 12730 8718 7966 Average 12837 8794 8194 Baseline 100% 100% 100% conditional_css_include_2.patch Total Transfer Duration Page Duration Test 1 10633 7111 6828 Test 2 11225 7332 7530 Test 3 11047 7639 7357 Average 10968.33 7361 7238 Faster By 15% 16% 12% cache_19.patch Total Transfer Duration Page Duration Test 1 9160 5453 5175 Test 2 9417 5712 4961 Test 3 9056 5306 5290 Average 9211 5490 5142 Faster By 28% 38% 37% conditional_css_include_2.patch AND cache_19.patch Total Transfer Duration Page Duration Test 1 9595 5615 5333 Test 2 9909 5709 5425 Test 3 9461 5824 5537 Average 9655 5716 5432 Faster By 25% 35% 34% cache_19.patch AND gzip Total Transfer Duration Page Duration Test 1 7429 3495 2741 Test 2 7027 3306 2758 Test 3 6915 3267 3001 Average 7124 3356 2834 Faster By 45% 62% 65% conditional_css_include_2.patch AND cache_19.patch AND gzip Total Transfer Duration Page Duration Test 1 7489 3157 2395 Test 2 6699 3107 2364 Test 3 7250 3013 2255 Average 7146 3092 2338 Faster By 44% 65% 71%
* Testing was done locally, to eliminate the variable latency you get on live networks. The Charles web debugging proxy was used to apply a consistent throttle and latency equivalent to a typical 64Kbps connection.
* Browser caching was disabled completely, to simulate an initial page load. I can repeat, with caching enabled (to test http cache freshness checks) if that would be useful.
* Drupal page caching (css caching for #100516) was enabled, and the test was done as an anonymous user. All Drupal modules were enabled (a few of these would more likely be contrib modules in reality). The page cache was cleared before each set of tests, and 2 dummy reloads were made before starting timing.
* The first column 'Total' is the total time spent transferring data, as reported by Charles. This does not include the time saved by browser pipelining of http requests.
* The second column 'Transfer Duration' is the Duration between the first byte transfer and the last byte transfer, as reported by Charles
* The third column 'Page Duration' is the time between the end user hitting refresh and Firefox finishing building the page. This is occasionally less that the transfer duration, which is a little odd, but perhaps certain page graphics (favicons maybe?) are not included in the page build time.
Note that these percentages are compared to the times in my original HEAD benchmark (with no patches) at http://drupal.org/node/100516#comment-162025
Please read the notes on that comment if you have not done so already. Also note that all the conditional css includes patch is doing here is somewhat reducing the cached css size, because none of the conditions are met on the front page.
Here is a summary:
Test Set Faster By: Seconds Saved: HEAD 100% 0 conditional 12% 1 caching 38% 3 conditional + caching 34% 3 caching + gzip 65% 5.3 conditional + caching + gzip 71% 5.8
Looking at this I am actually wondering if we should be looking at including gzipped css (and js) in core - if not for 5.0 - then certainly in 6.0. While the percentages are skewed by the fact that my test page is pretty lightweight (i.e. not much content, and no user added images) the seconds saved are real, actual seconds that would be saved by a user on a 64Kbps connection, and would be saved no matter what is added to the site and theme in the way of content and additional images. Also note that the conditional includes patch has now been committed to HEAD, but wasn't when I did my initial benchmarks - I am keeping it separate here for easier comparison.
Bearing in mind the statistic that most users will only wait 4 seconds before going to a different site, the application of aggregation/caching and gzip can take the initial page load time from a very poor 7 or 8 seconds, to a very respectful 2 seconds. The difference between these patches is extremely noticeable, the site goes from feeling pretty sluggish to appearing extremely fast.
|#134||drupal-101227-134-css-js-gzip.patch||5.91 KB||Owen Barton|
PASSED: [[SimpleTest]]: [MySQL] 25,306 pass(es). View
|#133||drupal-101227-132-css-js-gzip.patch||5.92 KB||Owen Barton|
PASSED: [[SimpleTest]]: [MySQL] 24,802 pass(es). View
|#131||drupal-101227-131-css-js-gzip.patch||6 KB||Owen Barton|
PASSED: [[SimpleTest]]: [MySQL] 24,818 pass(es). View
|#122||drupal-101227-122-css-js-gzip.patch||5.89 KB||Owen Barton|
PASSED: [[SimpleTest]]: [MySQL] 22,116 pass(es). View
|#118||drupal-101227-118-css-js-gzip.patch||5.83 KB||Owen Barton|
PASSED: [[SimpleTest]]: [MySQL] 22,020 pass(es). View