By doing this, you actually are reducing both the readability and the extent to which the plugin can be minified.

Let’s take your example of your HTML string by getting a HTML file with some <div> tags. Running some sample code through a minifier, we get 380 bytes before gzip for the first one:174

var a="<div>a</div><br><div>bc</div><br><div>def</div><br><div>ghij</div><br><div>klmno</div><br><div>pqrsjt</div><br><div>uvwxyzA</div><br><div>BCDEFGHI</div><br><div>JKLMNOPQR</div><br><div>S</div>",b="<div>T</div><br><div>UV</div><br><div>WXY</div><br><div>Z`12</div><br><div>34567</div><br><div>890-=`</div><br><div>!@#$%^*</div><br><div>()_+[]{</div><br><div>}|;':,./</div>";

For the second one, we get 347 bytes before gzip, a slight improvement:

var c='replace',a="<!>a</!><br><!>bc</!><br><!>def</!><br><!>ghij</!><br><!>klmno</!><br><!>pqrsjt</!><br><!>uvwxyzA</!><br><!>BCDEFGHI</!><br><!>JKLMNOPQR</!><br><!>S</!>"[c](/!/g,"div"),b="<!>T</!><br><!>UV</!><br><!>WXY</!><br><!>Z`12</!><br><!>34567</!><br><!>890-=`</!><br><!>!@#$%^*</!><br><!>()_+[]{</!><br><!>}|;':,./?</!>"[c](/!/g,"div");

However, what you have to understand is that what’s important most of the time important is the size of the file after being gzipped, not before. This is because most servers and browsers support sending files which have been compressed in this manner, reducing bandwidth usage.

When compressed, the DEFLATE algorithm (what gzip uses to compress files) already does what you would do manually, however you would have to have the additional size and loss of performance associated with the replacement code. As well, it’s able to recognise string patterns which aren’t easy to see with regular code without making your code completely unreadable.

With this example, what we end up finding is that after running compression on it (I used Zopfli to test this), the first script actually compresses down to 172 bytes, while the second can only be compressed down to 199 bytes, which is worse. The declaration for var c="replace" and [c](/!/g,"div") takes up bytes in itself, and since gzip already places backreferences in the compressed file, it actually increases the size of the code.

Not only that, the performance is slightly worse because you’d have to replace each of that during runtime, which is worse than the time needed to unpack the gzipped file natively.

In fact, most minifiers actually do the opposite of what you’ve done, so that the gzipped size is reduced. See this discussion on the Closure Compiler Discuss group.

An FAQ for the Closure Compiler also covers this:

Closure Compiler inlined all my strings, which made my code size bigger. Why did it do that?

Most people compare code size by looking at two uncompressed
JavaScript
files. But that’s a misleading way to look at code size, because your
JavaScript
files should not be served uncompressed. It should be served with gzip
compression.

Closure Compiler assumes that you are using gzip compression. If you
do not, you should. Configuring your server to gzip your
code
is one of the most effective and easiest optimizations that you can
possibly do. The gzip algorithm
works by trying to alias sequences of bytes in an optimal way.
Aliasing strings manually almost always makes the compressed code size
bigger, because it subverts gzip’s own algorithm for aliasing. So
Closure Compiler will (almost) always inline your strings when it can,
because that will make your compressed code smaller.

If you know your client doesn’t support gzip, the Java API has an
aliasAllStrings option on the
CompilerOptions
class. Turning this on will make the compiler alias all your strings
in the global scope.

If code were perfect, there would be no need for documentation because it is simple and straightforward, hence there would be no need to optimize for anything other than performance.

However, code is not perfect, and if you’re like me, you’ll have passed several days pulling your hair out trying to resolve a silly issue with a javascript library. I think the best solution is simply to not decide on behalf of the programmer who is downloading it, but offer both versions equally. The readable version is for those who wish to change existing code and the minified version would be to optimize performance because the code depending on it already does what it is supposed to.

Rarely will you see a programmer want to have code readable to debug, yet fast enough to put into production. If you can get it faster still by reducing it beyond readable levels, you will see that version used in production instead.

The minified version can simply be your readable version that has been minified, so focus simply on writing readable code since the objective is to make your code, well,… readable. Lets do a thought experiment for a moment.

Suppose you can minify your code from 50kb to 10kb. This is a 80% reduction in size, and you could say that, from a bandwidth standpoint, this is 80% more performant. Now suppose you can further reduce this reduction from 10k to 9k if you replace all if statements with tertiary operators. Now rather than an 80% reduction in size, you’ve managed to achieve an 82% reduction in size.

This said, if you could gauge the readability of your code before and after this change, do you think you would have suffered only 2% change in readability? Possibly, but I would argue that you’ve lost more. Even if it were only 2% difference, readability is the scope here, not performance. Most of the difference in performance comes from that 40k reduction using minified, and very little is gained for that single change.

That said, maybe don’t create large blocks of code that will never be run.