Static HTML file caching in Drupal Core - Boost

Varnish needs much more resources comparing to boost and it is much more complicated to setup for end users. It is also overkill for most simple websites specially if they don't allow users to login. We used boost for almost all the websites we made and it made it possible to serve thousands of users a day using Drupal even on very cheap hosting services.
By porting it to core it becomes even easier to setup, just a tick in performance settings and suddenly you can have tons of visitors without having to be worried about server's capability

So great thumbs up for this

I found some working examples, some are psr7 and even psr6 compliant :
- https://github.com/JosephSilber/page-cache
- https://packagist.org/packages/sylweriusz/webcache-middleware
- https://github.com/clickalicious/caching-middleware
- https://github.com/zfegg/page-cache-middleware

Thanks for new PHP ecosystem and standards like psr6 psr7, great deal of what boost does is already available as separate components which greatly reduces the amount of code required for this feature

Another good this is Drupal 8 already support psr7 and psr6 :)

Imho the Static HTML cache should be mandatory for big sites. No matters if they are using Varnish, Nginx or whatever.

Many site admins love and use Boost, however, I do not understand the argument for this feature being in Drupal Core. I hope this idea is not only a result of frustration over Boost not being available yet for Drupal 8.

Even if there existed consensus that this idea is worth pursuing, there are roadblocks. There does not exist a Drupal 8/9 compatible version of Boost as of today. The 7.x version supports Apache fully but only semi-supports other web servers. Also, Boost would have to be made significantly easier to set up, on all web servers that Drupal Core supports.

So this is as of now just an idea. Does anyone have a practical plan for carrying this out?

Agreed with @cilefen that this does not seem like a feature that is appropriate for core since it would typically depends on details of how the webserver/hosting is set up to a degree that would make this very hard support and test as a core feature.

Seems like finding/funding maintainers would be a higher priority.

Also, I think some of the comments in this thread may be missing this point - if you are looking at an existing middleware that's not what boost does - the value is avoiding any Drupal / PHP code execution, as far as I understand, but looking for an on-disk file version before going to the index.php. The drupal core page cache is already more-or-less a solution if you are willing to accept a Drupal bootstrap cost.

Just to break this down: If i get it right, D8 boost would be
- a sort of file backend for the page_cache module
- rewrite rules for major web servers to serve that pages without bootstrap
- invalidation logic for the files

And yes, that should mature in contrib.

@giorgio79: Thanks for pointing to tome. So that does the yob for purley static sites, but not for static caching of only parts of the site.

Related (duplicate even?)

Definitely related, but AFAICT not duplicate.

This issue is about keeping Drupal running as today, but basically improve the Page Cache module (which accelerates anonymous responses): avoid Drupal's involvement altogether and serve the page statically.

#3230448: Add a static generation tool to core AFAICT is about generating/exporting a static site, so that you do not have to deploy a working Drupal instance to your web server?

True, in my mind this issue would be a subset of the generation tool one. Because you could export the static pages for anon and keep classic drupal for auth users at the same time.

👍

As it stands, can the Drupal core page cache store the cached output as an html file (with some extensions / customization) in the filesystem and deliver it through htaccess magic?

We do have File Cache module which stores drupal cache on server disk space.

This though does not work as boost does but will be efficient enough with sites having large disk space for files and especially for small buget sites with adequate user traffic, where they have resource constrains like can't use or invest on Redis/Memcache with additional memory spaces e.g. shared hosting.

From my experience core Page Cache module gives almost same result. When cache hit happens it makes just one or two queries to the database backend. And if the backend is powered by Filecache or Memcache it won't establish DB connection at all. In such case the response TTFB would by 3-10 ms which is almost same as for static files.