Should I be using GZIP?

Hello again! Had a phase of momentarily doubt in myself building an own Wordpress theme using Roots (which at first got my head spinning), but after some fruitless search for the perfect (premium or free) Wordpress theme according to my maybe a bit strict criterias, I’m back for a second attempt.

I’m looking to accomplish an theme that is really lean on the browser load, but still modern. I realize the way Roots default workflow is makes it minimalistic, but since my target users are in many cases on slow and old browsers/computers/connections I really want a theme to be as lean as possible.

I’ve done some research and one thing that most Wordpress sites and themes seems to fail is in load time. page size and number of HTTP requests. I’m using and for example the Roots webpage is reported as:

Page load time: 1.64s
Total page size: 727KB
Total number of requests: 23

Which is impressive for a Wordpress site as far as the couple of tests I’ve run, where most sites does 3 or 4 more times in all (if not more). Of course the page load time is dependent on many things other than the Wordpress implementation that is hard to control as web designer/developer, but relies in many variables on things we can control like page size and number of request.

In my quest I’ve found that to compress with gzip is one not commonly used but most often recommended for optimizing web pages. Probably because today it’s not an obvious issue for desktop (and laptop) users, which is what most web designers are.

Anyways, even though I know web servers and Wordpress caching plugins do this, I’m pondering how to do it in the development workflow, and especially with using Grunt which I have come to somewhat befriend. I can’t see any gzipping going on in the current Gruntfile.js file as of by default. I’ve found grunt-contrib-compress does this.

Would using a compressor to gzip be right for me? Is grunt-contrib-compress a good way to accomplish this? Or is adding this to the default Roots workflow maybe even not necessary?

Gzipping is usually a server technology that your web server will do on the fly. You may have options with your web host to enable this, or look into adding the HTML5 Boilerplate .htaccess file which enables compression by default.

You can use a tool like this one to test easily if a site is gzipped, or something like the PageSpeed Chrome extension.

Thanks for your reply! Seems this is a good enough solotion, even though I’m still curious if dev time gzipping could save load and hence load time…

@henrik_vaglin you’re correct that there’s obviously some overhead if the web server needs to gzip files on the fly. Nginx for example has a gzip_static on; setting that will automatically look for static files with a .gz extension and serve them up directly.

If you’re precompiling your assets then you should definitely also do a .gz version. I guess the only tradeoff against this is it’s not good to store gzipped files in your repo so it would be good to use a deploy strategy to keep it out of there.

I just added grunt-contrib-compress to with this config:

          mode: 'gzip'
        files: [
          { expand: true, src: ['assets/{js,css,img}/**/*'], dest: '' }

Thanks for the reminder @henrik_vaglin

1 Like

You’re welecome @swalkinshaw ! Glad I can contribute something to this awesome project, even if it’s just an idea :smiley:

@swalkinshaw If I would use your Wordpress Stack “Bedrock”, would there be logical to put that code snippet in there somewhere for when deploying to staging and production server? (I’m about to give it a try to set up my development environment from Bedrock)

I would probably run your Grunt task on the server during the deploy by using and hooking into Capistrano’s deploy flow. The details are in the README of how to integrate it.

Just make the compress task part of your Grunt’s production/build/deploy task and it will be run on the server so the .gz files aren’t part of your repository.