RealTime Template Compressor

[ShiningArcanine]

Hey could someone port this to vB3:

https://vborg.vbsupport.ru/showthread.php?t=56589

I'd really really like this. :D

[Logician]

When time comes, it will be ported to VB3 by its author.

[Koutaru]

;) thanks Logician

[Logician]

I didnt work on this yet so this is just a thought but this hack can be problematic in VB3 though. VB3's javascript/DHTML structure is more sophisticated than VB2 (eg. WYSIWYG post area etc.) and removing spaces/new lines can cause some bugs. We'll see when I start to work on it. :)

[Andreas]

I think it might be a good idea not to do this realtime, but when the templates are being parsed for conditionals (eg. in process_template_conditionals).

This way there would be no overhead when serving pages :)

Does anybody have figures about the decrease when GZIP (level 1) is enabled?

[ShiningArcanine]

When time comes, it will be ported to VB3 by its author.

I'm sort of new to the forums so I had no clue you were still around to port it. ^_^;;

[Logician]

I think it might be a good idea not to do this realtime, but when the templates are being parsed for conditionals (eg. in process_template_conditionals).

This way there would be no overhead when serving pages :)

I didnt check VB3 algorithm extensively yet but I'm not sure if it helps. The hack needs to apply a "preg_replace" to the page output code and I think it wouldnt matter in which step and where you apply it. It will add a very small amount of overhead at the moment it runs regardless of its location, dont you think?

The only workaround is to compress the template when it is formed and save the compressed form in database. It will save the overhead then but I think it will be a very bad idea because templates will be unreadable to the admin in the edit page as well. :)

[Andreas]

@Logician
It you take a look at the table template, you will see that vB3 keeps two versions of each template in database: Unparsed for editing reasons (field template_un) and a parsed one (template) which is being used for actual page generation.
So if you put your code into process_template_conditionals the compression will be only done "once" (each time a template is being saved to database).

This way, there would be no overhead when serving the pages, but the original layout (for editing) could still be preserved.

[Logician]

ok great, I'll look into it, thx! :)

[Princeton]

@Logician
It you take a look at the table template, you will see that vB3 keeps two versions of each template in database: Unparsed for editing reasons (field template_un) and a parsed one (template) which is being used for actual page generation.
So if you put your code into process_template_conditionals the compression will be only done "once" (each time a template is being saved to database).

This way, there would be no overhead when serving the pages, but the original layout (for editing) could still be preserved. that's a great idea!
-----------------------------------
Jelsoft has taken giant steps to make vB3 more adaptable; but, it has taken quite a few steps back when implementing javascript into to many of it's pages. They should have placed all javascripts into external files.

To take full advantage of the compressor you should compress EVERYTHING (even javascript and css). However, if you do this the user should be aware that they must remove all comment tags from any javascripts found within templates.

This could be an option to the user - COMPRESS JAVASCRIPT?, yes/no, 1. And give instructions to search for <!-- || --> || // -- they all must be removed.

I'm looking forward to the new release. :)

[Andreas]

One idea for the JavaScript issues:
Before applying the compression replace all instances of <script> ... </script> with $script[x].
Afterwards run a special compression on the script-snippets (which should just ignore <!-- and -->, or maybe strip them but not the text within), then run the compression on the template (as there are no <!-- or // within JavaScripts now there should be no problems) and finally re-substitue the $script[x] with the script(s).

[Zachery]

is it really so nessary with how vB3 is done?

[cirisme]

You can get information here:

http://leknor.com/code/gziped.php

Simply enable it on your forum then enter your forum's url and you can see what benefit you're getting ;)

[Princeton]

faranth,
yes, it does make a difference ... especially in the long run.
Less bytes = Less bandwidth / faster rendering (client side) / also, makes it harder to read source code (client side)

It's similar to putting entire source code (client side) in one line.
I like KirbyDE's idea - about doing the compression before hand.:up:

cirisme,
two different end results ... not the same thing

[Zachery]

faranth,
yes, it does make a difference ... especially in the long run.
Less bytes = Less bandwidth / faster rendering (client side) / also, makes it harder to read source code (client side)

It's similar to putting entire source code (client side) in one line.
I like KirbyDE's idea - about doing the compression before hand.:up:

cirisme,
two different end results ... not the same thing
i dont belive its so nessary anymore, with alot of the files stored externally, and with the option to store the CSS externaly. i really dont think its going to improve it as much as it used to

[Princeton]

all you have to do is look at the source code here and you will see a lot of




S P A C E
It's really a personal choice. However, as a web professional, I make sure my customers/friends get maximum results for their money.

[ShiningArcanine]

ok great, I'll look into it, thx! :)
Wouldn't the parsed templates need to be deleted before the hack will work? I guess this hack will require running a query on the MySQL database to install/uninstall it.

[eXtremeTim]

I used the vb2 version and it worked straight up for me. I have been using it for about a two weeks now with no problems. Then again im running a ported version of the vb2 microstats hack that i brought over a while back.