Using the "escape" attribute with the "tidy" value across site.

THE BLUE DRAGON · 2024-07-22 20:33:50

Hi, I’m using the escape="tidy" to the whole content of the site.
I wrapped everything in a variable and use the attribute as so:

<txp:variable name="page_default" escape="tidy" output>
The whole page code goes here.
</txp:varaible>

My question is, does this can cause any problems and does it actually makes the site faster or is it heavy and only makes it slower using it like that please?
Is there any catch? or is it really just awesome?!
(it just seems too good to be true)
If it isn’t the right way to achieve the goal to compress the whole site page into a single line for optimization, then what is the right way please?

jakob · 2024-07-22 21:12:14

I think escape="tidy" on its own just trim’s white space off the beginning and end and multiple spaces, tabs etc. into single spaces.

There is pat_speeder which strips down as much as the site, except for certain blocks, into a single line.

THE BLUE DRAGON · 2024-07-22 22:16:14

jakob wrote #337441:

I think escape="tidy" on its own just trim’s white space off the beginning and end and multiple spaces, tabs etc. into single spaces.

Thanks, from the docs :

escape="tidy" Remove extra spaces/newlines from the content and trigger a more thorough processing mode .

Here’s the code from the core taghandlers.php file where you can see it uses both preg_replace with the magical value of /\s+/ and trim:

case 'tidy':
    $tidy = true;
    $thing = preg_replace('/\s+/', ' ', trim($thing));
    break;

So the question is does using preg_replace like that for the whole page is bad or is it actually fine and good for optimization?

jakob wrote #337441:

There is pat_speeder which strips down as much as the site, except for certain blocks, into a single line.

Nice I will also check it, does it lighter and better than using tidy (preg_replace) please?

Last edited by THE BLUE DRAGON (2024-07-22 22:20:20)

jakob · 2024-07-23 07:45:50

THE BLUE DRAGON wrote #337442:

Here’s the code from the core taghandlers.php file where you can see it uses both preg_replace with the magical value of /\s+/ and trim.

Yes, I looked at that too. You’ll see in that function that using tidy modifies some of the other escape settings, but (I think) only when used in combination in the escape attribute.

Nice I will also check it, does it lighter and better than using tidy (preg_replace) please?

Well pat_speeder also uses preg_replace but is more selective about what it compresses. Probably not lighter, but caters for some special cases you may or may not have in your site.

Bloke · 2024-07-23 09:17:55

/\s+/ will probably remove spaces inside quoted strings so you might need to check. But if the selector only operates at the tag level and not the content-within-tags level you might be able to get away with it.

THE BLUE DRAGON · 2024-07-23 10:56:02

Interesting stuff! thank you Julian and Stef 👍🙏

etc · 2024-07-23 12:40:00

I wouldn’t recommend using tidy for compression, since it can e.g. break js blocks: a valid

var i = 0
i++

becomes an invalid

var i = 0 i++

More generally, I think using some server compression is enough to get most of it.

THE BLUE DRAGON · 2024-07-24 18:06:42

Thanks Oleg, I will see and check if there are any cases where using tidy or pat_speeder plugin and so may break my site code 👍

colak · 2024-07-25 05:06:16

pat_speeder works well as you can exclude the compression of php, javascript, <pre><code> tags etc.

THE BLUE DRAGON · 2024-07-25 14:52:59

colak wrote #337455:

pat_speeder works well as you can exclude the compression of php, javascript, <pre><code> tags etc.

Thank you Yiannis 👍

skewray · 2024-07-25 15:59:46

I would posit that the incremental speed improvement from crushing out a few extra spaces and tabs is negligible when server-side gzip compression is enabled. The LZ77 algorithm that gzip is based on will make that kind of stuff disappear.

ps…My server has DEFLATE (gzip) enabled automatically; ie, without any reference to compression in my .htaccess file.

Last edited by skewray (2024-07-25 16:35:44)

phiw13 · 2024-07-26 01:22:55

skewray wrote #337461:

I would posit that the incremental speed improvement from crushing out a few extra spaces and tabs is negligible when server-side gzip compression is enabled. The LZ77 algorithm that gzip is based on will make that kind of stuff disappear.

Indeed. The only benefit of minification is going beyond white-space removal/collapsing/… and also remove all redundant HTML/CSS/JS comments that might exist in the source file, before gzipping. pat_speeder does not seem to remove the HTML comments.

Most JS and CSS minifiers do this, and that can reduce the file size significantly – the source CSS file for my TXP admin Sandspace theme is about 240KB, with lots and lots comments. after minifying it goes down to 127KB, and then compression reduces the size further by half to ~65KB.

(all those CSS / JS /HTML comments are only useful for development & documentation, there is no need to send those over the wire and waste resources)

Textpattern CMS

Textpattern CMS support forum

#1 2024-07-22 20:33:50