Title: epcur's Replies | WordPress.org

---

# epcur

  [  ](https://wordpress.org/support/users/epcur/)

 *   [Profile](https://wordpress.org/support/users/epcur/)
 *   [Topics Started](https://wordpress.org/support/users/epcur/topics/)
 *   [Replies Created](https://wordpress.org/support/users/epcur/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/epcur/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/epcur/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/epcur/engagements/)
 *   [Favorites](https://wordpress.org/support/users/epcur/favorites/)

 Search replies:

## Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[W3 Total Cache] Page Caching: html_gzip only? limit cache size, lifetime, inode count?](https://wordpress.org/support/topic/page-caching-html_gzip-only-limit-cache-size-lifetime-inode-count/)
 *  Thread Starter [epcur](https://wordpress.org/support/users/epcur/)
 * (@epcur)
 * [3 years, 7 months ago](https://wordpress.org/support/topic/page-caching-html_gzip-only-limit-cache-size-lifetime-inode-count/#post-16394521)
 * Thanks again for answering our questions. Much appreciated.
   Apparently, we missed
   the Brotli option or did not check the Browser Cache section carefully enough.
   Thanks! We do have the brotli extension installed on our server and, with W3TC
   supporting it, would only use .html_br, if possible (no plain .html and no .html_gzip).
   It is perfectly fine for our purposes if the vast majority of users/bots are 
   presented with brotli-compressed data and those who do not support it are served
   no page-cached files at all.You mentioned there is no easy way to disable the
   plain .html files. We need to ask you about this again in detail.1) In your implementation,
   are the plain .html files always being created first and only then compressed
   to gzip and/or brotli?2) If yes, is there a comparatively straightforward way
   to edit the plugin .php files in order to delete the plain .html files once the.
   html_br files have been created?3) If not, is there really no fairly clear way
   to disable the creation of plain .html files be editing the php source?We’re 
   developers, but not specialized in web development, familiar with php but not
   with rewrite rules/directives in particular. We searched the plugin .php files
   for occurrences of “.html”, “.html_gz”, “.html_br”, “_index.html”, “_index_ssl.
   html” and the like, but didn’t quite know what to edit. It’s perfectly fine we
   would have to do the same or similar editing with every plugin update. So if 
   disabling the creation of plain .html files is not too involved, we’d like to
   do it.Our page cache .html files are about 120 kB per file, the .html_br files
   only 18 kB at the current compression level, and only 14 kB for brotli compression
   level 11. Since we need to page-cache a lot of pages, the size of the plain .
   html files really is a problem here. But apart from this problem, W3TC does everything
   we’d like it to do, so we’d love to stick with it.
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[W3 Total Cache] Page Caching: html_gzip only? limit cache size, lifetime, inode count?](https://wordpress.org/support/topic/page-caching-html_gzip-only-limit-cache-size-lifetime-inode-count/)
 *  Thread Starter [epcur](https://wordpress.org/support/users/epcur/)
 * (@epcur)
 * [3 years, 7 months ago](https://wordpress.org/support/topic/page-caching-html_gzip-only-limit-cache-size-lifetime-inode-count/#post-16352666)
 * Thank you for the detailed explanation, much appreciated. With a larger SSD, 
   we can now page-cache many more pages and use W3TC the way it is intended to 
   be used with one exception: Could you please provide an option to disable the
   generation of .html files altogether? For our very large page cache, the gzipped
   files alone are sufficient and having the .html files present as well dramatically
   increases our disk space requirements. Also, gzip is supported by all commonly
   used desktop and mobile browsers today? If there are some users/bots which cannot
   be served gzip files, it’s perfectly fine if they are not provided with a page-
   cached version of a given URL as far as we are concerned. For those presumably
   rare cases, the object cache and the additional optimizations we enabled/implemented
   are sufficient.
 * If you cannot provide an option to disable .html altogether, is there a somewhat
   straightforward way to disable it by editing the plugin .php files directly (
   which, yes, we would have to do for each updated version of W3TC again)? We haven’t
   looked at the plugin .php files in detail yet, but, currently, we’re using a 
   Python script which runs 24/7 on our server to delete all the .html files generated
   by W3TC which is a bit of an awkward solution but is working fine for now.
 * Also, is there any particular reason you are using Gzip compression rather than
   Brotli or providing the option to use either Gzip, Brotli or both? Ideally, it
   would be nice if uncompressed HTML, Gzip and/or Brotli could all be enabled or
   disabled by the user.

Viewing 2 replies - 1 through 2 (of 2 total)