⟵ Back to Archive

Improving Asset Delivery Times with gzip_static

| Shey Sewani | Toronto

So, HTTPScout’s JavaScript bundle is 1.9MB.

Something’s clearly broken in my setup. It’s something I’ll fix one day. Right now I don’t have the brain juice. That said, I still want performance. A 1.9MB bundle is oppressive (and embarrassing), even with HTTP caching.

Anyhoo, I was reading ruby.social, and pushcx published a bug list for lobste.rs.

And! as luck would have it, one of the issues referenced using gzip_static in nginx.

I immediately understood what I saw. I know I didn’t have that set, and it would make serving the giant js file faster.

It’s a simple change to the nginx config:

location ~ ^/(assets)/ {
  gzip_static on;
  root /home/rails/lrt/current/public;
  expires max;
  add_header Cache-Control private;
}

Before And After

Before enabling gzip_static, the JavaScript bundle was 1.9MB, the CSS was 548KB, and total transferred size came out to 2.6MB. Finish Time was 990 miliseconds.

Before

After the change, the JS dropped to 672KB, CSS to 72.4KB, and total transfer came down to 816KB. Finish time fell to 440. That’s 550 miliseconds faster!

After

Conclusion

Enabling gzip_static took 550 ms off Finish Time and reduced the total payload by 1.7MB. That’s a single-line nginx config change with a huge payoff. The asset pipeline still needs work, but this gave the site the performance boost it needed.

P.S.

I’m grateful that sites like ruby.social and lobste.rs exist.