Note that Minify slows down (usually)
-
This is just a note for those thinking about whether to use minification or not:
With minification enabled but the page cache disabled (for logged in users), W3 Total cache actually slows down the site by a couple of 100 ms.
This is because all HTML & inline JS+CSS is buffered, minified and sent to the browser at PHP shutdown at once. WordPress will not send intermediate rendered bytes while generating the page, so the CPU/Network pipeline is not properly exhausted.
This applies whenever ” Disable minify for logged in users” is unchecked (on no page cache for logged ins)
-
I didn’t mean the bundling process (aka. merging, vulcanizing) of JS/CSS files. Its about the JS/CSS inside the HTML markup.
True with slow connections, but with gzip the actual saving is not that big, considering that usually (with good plugins) there is few JS inlined in the page HTML.
I think in W3 Total Cache there is a confusion between “Minification” (the actual code compression) and “Bundling” (merging multiple JS/CSS) files into a single one.
(As a side note: Bundling looses importance with HTTP/2, see https://stackoverflow.com/questions/30861591/why-bundle-optimizations-are-no-longer-a-concern-in-http-2 )
My sentece about CPU/Network is the actual reason for the issue I’m talking about.
It would be interesting to see how much you could win, if you pass a callback to
ob_start()that receives the chunks, minifies them, and outputs as soon as they are ready, for example after a ‘</script>’ in HTML
- The topic ‘Note that Minify slows down (usually)’ is closed to new replies.
