WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: performance Toggle Comment Threads | Keyboard Shortcuts

  • Matt Mullenweg 3:28 am on July 13, 2010 Permalink
    Tags: performance   

    Forcing GZIP: http://www.stevesouders.com/blog/2010/07/12/velocity-forcing-gzip-compression/

    This would make an excellent WordPress plugin.

     
    • Justin Shreve 9:38 am on July 13, 2010 Permalink | Log in to Reply

      I gave it a shot. I follow the method totally to spec. It worked on my personal tests but could probably use some additional testing.

      http://justin.wordpress.com/2010/07/13/force-gzip/
      http://justinshreve.com/force-gzip.zip

      Also nice easter egg hidden in the headers!

    • demetris 10:18 am on July 13, 2010 Permalink | Log in to Reply

      For the majority of WP users this is less relevant than we may first think, for a simple reason:

      Most WP users are on shared-hosting, and gzip support in shared-hosting setups is rare. (Really rare!)

      For the rest of the cases, where the server can send gzipped content, I am curious to know what would happen if one sent gzipped content unconditionally, that is, without regard for the Accept-Encoding header and without running any tests first.

      • Milan 11:37 am on July 13, 2010 Permalink | Log in to Reply

        gzip support in shared-hosting setups is rare. (Really rare!)

        What is your source for this? I can’t agree that it is rare. And do we talk about compression via Apache or via PHP?

        I am curious to know what would happen if one sent gzipped content unconditionally, that is, without regard for the Accept-Encoding header and without running any tests first.

        In article it is said that they check for cookies first.

      • Matt 12:39 pm on July 13, 2010 Permalink | Log in to Reply

        You can gzip in PHP with ob_start( 'ob_gzhandler' ).

        • demetris 1:19 pm on July 13, 2010 Permalink | Log in to Reply

          But that’s not a good option, which is why it is not in core anymore.

          Also, that option does nothing for static resources like JS and CSS files, for which great benefits can be expected from gzipping. Two examples: 1. The main CSS of Twenty Ten is 22kB uncompressed and 5kB compressed. 2. The latest, minified jQuery (1.4.2) is 71kB uncompressed and 25kb compressed.

          @Milan

          My source is checks that I do myself from time to time. Last time I checked a large number of hosting companies was in Spring 2009. For an indication, at that time none of the hosts recommended at the wp.org page supported gzip compression in their shared-hosting offerings.

          I would be interested to know if the situation has changed significantly since then, but I am not holding my breath, since that happens for a reason: gzip compression is expensive.

        • Peter Westwood 8:24 pm on July 13, 2010 Permalink | Log in to Reply

          But that’s not a good option, which is why it is not in core anymore.

          Actually it got removed solely becuase it was impossible to tell reliably if compression was already enabled at another level in the web server stack – either in the Web Server or for all php requests.

          That lead to alot of people suffering from double compression when it was enabled.

    • Milan 11:42 am on July 13, 2010 Permalink | Log in to Reply

      It would be excellent if it is made by good programmer, with very lightweight JavaScript and small cookie. And in any case only HTML will be compressed and not for new visits.

      This data shows that minification of CSS and JavaScript files should be more encouraged since it will make some savings when delivered uncompressed.

    • Otto 5:29 pm on July 13, 2010 Permalink | Log in to Reply

      The problem with compressing output to browsers is that you’re really making a tradeoff. Compression uses less bandwidth, but if you’re compressing on the fly then you’re using more CPU time. On shared hosting solutions, CPU time is generally more limited than bandwidth, so compression like this ain’t always a good thing.

      • Peter Westwood 8:26 pm on July 13, 2010 Permalink | Log in to Reply

        Indeed.

        Compression on the fly is only a benefit if your servers are Network I/O bound not CPU bound.

        You often do better to focus on one time compression of the things that you can and good caching of output (which could be compressed once)

        • Matt 9:08 pm on July 13, 2010 Permalink | Log in to Reply

          You’re thinking only from the server side — it’s a benefit from the client side by making things much faster.

        • Otto 9:29 pm on July 13, 2010 Permalink | Log in to Reply

          It’s a diminishing returns problem. Compressing 20k of HTML down to 4k will indeed be faster, but not if it takes you longer to compress than to send 16k down the pipe.

          On the other hand, if you also use a static caching solution to save the compressed stream for serving it up again later, then you can achieve enhancements all around, since you don’t incur a CPU time penalty for compressing every single time.

        • Matt 9:34 pm on July 13, 2010 Permalink | Log in to Reply

          I think you’re vastly overestimating the time it takes to compress something on the fly.

          Time for some ab, but I don’t have an unloaded box handy.

      • Milan 12:15 pm on July 14, 2010 Permalink | Log in to Reply

        @Matt: If anyone does some tests, they should test both Apache and PHP since some people in their articles recommend only PHP without mentioning Apache’s mod_deflate.

    • Matt 12:39 am on July 14, 2010 Permalink | Log in to Reply

      This is a pretty nice tool for testing if Gzip is on, and how much it would save if it was:

      http://www.whatsmyip.org/http_compression/

    • Steve Souders 3:54 pm on July 14, 2010 Permalink | Log in to Reply

      @Matt: It warms my heart to have you evangelizing performance this way. You made my day.

      Compression is nearly always a win if the payload is > 1 kB. My blog post yesterday has a chart ( http://stevesouders.com/images/roundtrips-per-kb.png ) that shows the number of roundtrips required for various payload sizes. Reducing roundtrips, esp. for JS and CSS, makes the page load much faster. Netflix found that turning on gzip compression made pages 13-25% faster ( http://assets.en.oreilly.com/1/event/7/Improving%20Netflix%20Performance%20Presentation.pdf ).

      For static JS and CSS files, it is a challenge if the WP user does not have access to their web server config. One alternative would be to have gzipped versions of these files (main.js.gz) and WP could dynamically determine which static file to include.

    • Robert Jakobson 10:53 am on July 23, 2010 Permalink | Log in to Reply

      Could anyone or the author himself explain and clarify whether CSS, Javascript is getting compressed as well with this plugin or is it only PHP/HTML markup?

      Need an answer quickly.

  • Ryan Boren 6:53 pm on June 18, 2008 Permalink
    Tags: , performance   

    Performance tweaking the hierarchy walkers and eliminating taxonomy queries with DD32. Category listings are getting faster.

     
  • Ryan Boren 10:36 pm on April 18, 2008 Permalink
    Tags: performance   

    Eliminated a bunch of usermeta queries from the Write Post page.

     
  • Ryan Boren 1:56 am on April 18, 2008 Permalink
    Tags: performance   

    Sped up the main query for the Manage Comments page. Shaved some time from wp_list_categories() and wp_dropdown_categories(). Working on the category dropdowns and checkboxes on the Write Post page next.

     
  • Ryan Boren 12:19 am on April 17, 2008 Permalink
    Tags: performance   

    Consolidated three comment count queries on the Manage Comments page down to one.

     
  • Ryan Boren 6:03 am on April 16, 2008 Permalink
    Tags: performance   

    Eliminated a slow query in the Dashboard. Trying to consolidate some other Dashboard queries.

     
  • Ryan Boren 6:01 am on April 16, 2008 Permalink
    Tags: performance   

    Speeding up the Write Post page by loading the full category list only once the “All Categories” tab is clicked. The much shorter “Most Used” categories list is displayed by default. If you have hundreds or thousands of categories this speeds up page load time nicely.

     
    • Viper007Bond 12:01 pm on April 16, 2008 Permalink | Log in to Reply

      Any way to reverse this via a plugin or something? I don’t have hundreds or thousands of categories and I much prefer the 2.5.0 arrangement.

    • Ryan 7:34 pm on April 17, 2008 Permalink | Log in to Reply

      We ended up reverting this to try another approach.

    • Daniel 7:36 pm on May 25, 2008 Permalink | Log in to Reply

      Sorry to hear about the reversion, this change would have been great from my perspective, what about an option in the settings so the user could choose which of ‘All Categories’ or ‘Most Used’ is displayed by default?

    • Lloyd Budd 10:18 pm on May 26, 2008 Permalink | Log in to Reply

      Daniel, options are bad.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel