I usually use Chrome to do all my web browsing. As such, for small site updates I don’t always test the changes using all the big 4 browsers (Internet Explorer, Chrome, Firefox, and Safari) — just Chrome. Yes, that wasn’t how I was taught and I know I’m being lazy. Nevertheless, this method has worked OK for me over time, for the most part. Up until the point where I noticed, quite by accident, Safari displaying garbage characters for specific webpages on one of my sites.
What’s worse is that although I just noticed the problem, I was sure it probably had existed for quite some time, since I hadn’t made any major changes to this particular website in awhile. Oh, bother.
So I troubleshooted by testing in the big 4 browsers, as I should have from the start. I also checked the NGINX server headers and didn’t notice anything too peculiar, although this one line started me wondering:
Shouldn’t there be just one gzip? Indeed there should have been only one (Neo, Neo), so I believed I was on the right track to solving the problem. But what would cause NGINX to output two gzips in the Content-Encoding header?
I knew that NGINX itself was configured to gzip html docs, so to confirm if NGINX alone was the culprit, I checked the headers from a non-WordPress site from the same server. Sure enough, the content encoding looked fine:
That’s when a lightbulb went on. Really, someone turned on the light in the room I was in. Bad jokes aside, I did figure the problem out, and it had to do with the WP Total Cache plugin I was using. WP Total Cache is a WordPress plugin designed to optimize WordPress for speed. One of the options is to compress pages before sending to the browser.
In my case, the option was checked. I unchecked this option and viola! No more garbage characters.