GZIP et minify (css, js, html)

[B4rb3rouss]

Juste pour ne pas oublier, je pose ça là :

• Activer la compression gzip pour les pages (déjà prêt), mais aussi pour les fichier js et css
• Minifier le code js, css et html et le garder en cache.

Toujours dans un but d'améliorer les performances d'un Blogotext auto-hébergé.

[ragnar76]

just my 2 cents...

compressing and/or caching should be a job of the webserver (for example, apaches mod_deflate and mod_cache) . Sure, it a hell of config but after it, it's blazing fast and there is no need to minify the files at all. But if you still want to have a look at googles mod_pagespeed

[remrem]

@ragnar76, there are several use cases where cache management and compression by the web server (apache/nginx...) is not the "optimal" solution.

Since BT 3.7, I see some points that can cause problems :

• with addons, if a blog uses uses a lot of addons and each uses its own JS/CSS files, we multiply http requests, disk accesses (...), with a BT side cache we group them together, we minify them (which mod_deflate / mod_cache doesn't do (it seems to me)), so we go from X http requests / file access to 1 or 2.
• mastering its server / technical knowledge, some are on a shared server, others host on a small NAS, raspeberry (...) in short, some do not have the tools/knowledge/resources to set up a powerful and well configured web server

There are still a few other cases that I do not mention.

For information, on my working version (3.8), I finished the cache/versionning/compression/minify system for CSS /JS / SVG (admin side), as soon as I have some time I will make a comparison, and I will put you the results, but without having looked in details, the working version is more powerful than the 3.7.6 (for now).

In any case, when BT 3.8 will be in test/freeze, we can always decide to remove this feature if it is problematic or not really necessary.

[remrem]

Small benchmark, to take into consideration:

• BT 3.8-WIP, under development
• On the admin "articles" page
• the cache system differs a bit for the public side (direct HTTP access to the BT cache, no PHP for the public cache)
• local WAMP server (dev settings)
• no server side benchmark (for the moment)
• php 7.2.4
• apache 2.4.33
• the script that gathers the files is enabled (limits HTTP requests)
• BT cache storage is enabled (the cache is generated once per BT version or at cache purge)
• test on the 1st HTTP request
• mozilla firefox client 61.0.1 64bits
• for each test
  • 1° without flow limitation
  • (2) "regular 3G"
• on some screenshots the transferred volume is at "0", I decided to leave it as is, the time graph speaks enough. (Laziness: D)

The test protocol is not the best and not very reliable, I consider it more as an indicator than as a reliable measure.

1 First, a baseline: All systems disabled (no minify/compression (BT or apache)...)

2 BT systems disabled, apache deflate enabled

3 BT systems disabled (except gzip), apache deflate disabled, GZIP by php (BT)

4 BT systems all active, apache deflate disabled

5 BT systems all active, apache deflate activated

Voilà, as I said at the beginning, I wait to see what it will look like during the freeze, when everything will be pretty much operational to see the impact on the client and server sides...