-1

I've searched everything about something like "compress html javascript" in the Web, but found nothing to answer my question, but I cannot understand what's wrong. The problem: if you have something like <span>blah<span>blah</span>blah<span>blah</span></span> in your html page, why don't you try to compress this? For example,

<!DOCTYPE html>
<html>
<head>
<title></title>
<meta charset="utf-8">
<style>
.click {color: blue; cursor: pointer;}
.encoded {display:none;}
</style>
<script src="jquery.js"></script>
<script>
$(document).ready(function () {
$.fn.encode = function () {
//encoding code
};
$.fn.decode = function () {
//decoding code
};
$('.click').click(function () {
var decoded = $(this).next('.encoded').text().decode();
$(this).next('.encoded').removeClass('encoded').addClass('decoded').html(decoded);
});
});
</script>
</head>
<body>
<div class="click">click</div>
<div class="encoded">AbCxYz*_()+=…
<!-- decoded html: <span>blah<span>blah</span>blah<span>blah</span></span>-->
</div>
</body>
</html>

Is there any functions that may be used for those encode/decode parts? Of course, base64 is not a solution, because that html must be compressed at first, and then something like base64 must be applied to the result...

lyrically wicked
  • 1,185
  • 12
  • 26
  • 1
    There are many HTML Compressors one of them is http://htmlcompressor.com/compressor.html – AurA Nov 14 '12 at 06:59
  • 3
    Because it is far simpler, far more efficient and doesn't hide the content to non-JS clients (including search engines) if you just use the compression options built into HTTP. – Quentin Nov 14 '12 at 07:00
  • @AurA — That minifies, it doesn't compress. – Quentin Nov 14 '12 at 07:02
  • it takes time to decode, so it could be ok only for short divs. It would look more like obfuscation than compression then. I think the best place to compress is on the server side, the content is served compressed and browser decompress it. This can be done already as for http protocol. – ShinTakezou Nov 14 '12 at 07:04
  • To add to Quentin's comment: for example in IIS (the web server) you turn on static and/or dynamic compression, and it just compresses everything you serve through it. Totally transparent. – Nick.Mc Nov 14 '12 at 07:10
  • From the sound of it, this isn't what you're looking for, but I thought you might be interested anyways: http://stackoverflow.com/questions/6604707/is-there-an-alternative-to-html – Joonas Nov 14 '12 at 07:15
  • @Joonas No, of course. I imagine something like rar/zip preprocessing, then base64-encoding... that would be cool! – lyrically wicked Nov 14 '12 at 07:21
  • No, actually it would not be cool. base64 encoding makes the compressed data larger, there is native gzip support in browsers (=> fast and transparent) and besides that, a few bytes usually do not matter. – ThiefMaster Nov 14 '12 at 07:24
  • @ThiefMaster No!!! base64 encoding makes the **non-preprocessed** data larger! Imagine you zip your large .htm file, then base64-encode the resulting .zip file, what do you think you'll get? The resulting .b64 file will be **smaller** than the original .htm file! – lyrically wicked Nov 14 '12 at 07:30
  • Of course, but it will be larger than e.g. native gzip compression of the whole http response body - because that does not need to be encoded in an ascii-compatible format. Just face it: Your idea is flawed and should remain as exactly what it is: an idea that hopefully nobody is going to implement. – ThiefMaster Nov 14 '12 at 07:31
  • @ThiefMaster Flawed for what? You talk about http, but what about offline usage of an html document? I just want my **offline** page to be as small as possible, what's wrong? – lyrically wicked Nov 14 '12 at 07:38
  • There is absolutely **no** reason to clutter a HTML document and make it inaccessible for anything but a JavaScript-enabled web browser just to save a few bytes. Actually, most browsers could even deal with a local .html.gz file... – ThiefMaster Nov 14 '12 at 07:39

1 Answers1

1

The support for gzip compression available in just about any browser and web server is much more efficient than the javascript transfer. In fact, with many web servers you can upload your web pages as .html.gz (for most browsers) and .html (for clients that do not support compression; mostly bots, no real users) and the web browser will automatically serve the compressed version when supported.

Note that in particular more clients support the HTTP (not limited to HTML - works for CSS as well) compression than javascript.

Has QUIT--Anony-Mousse
  • 76,138
  • 12
  • 138
  • 194
  • 1
    I have to double my previous comment: I'm not talking about online (http) and gzipping the whole page, I was just concerned about the very idea to compress my custom parts, for example, in an offline html document. But now I realize you all think it's useless, okay... :( – lyrically wicked Nov 14 '12 at 07:47
  • You can use `.html.gz` offline, too. Try opening the file with Firefox, Chrome, IE - they all should work fine. The biggest hurdle is that Windows doesn't realize that it still is a HTML file, and often will try to open it with WinZip. – Has QUIT--Anony-Mousse Nov 14 '12 at 08:48
  • @Anone-Mousse It's the same on Linux so I don't know what you mean. It seems that opening '.html.gz' files is not your browser's default behavior. (Gnome-Shell) – 3Qn Sep 30 '19 at 06:05