Gabor pointed out in slack that the first request to the site after the installer is very slow.
This is partly because it builds a lot of caches like Twig templates that are not necessarily even rebuild after a full cache clear (because they're on disk and cached differently).
One possible thing that would help would be prewarming some caches at the end of the last installer request just after the redirect is sent.
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | Screenshot from 2026-06-17 17-29-42.png | 283.07 KB | catch |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
catchAttaching an xhprof/xhgui screenshot of the prewarm call - you can see it spends 100ms-ish trying to prewarm caches.
Whether it actually helps the first request to the front page is a bit unprovable though.
Comment #4
nicxvan commentedOh this is interesting!
I guess my question is does this placement save that much time? Are there pieces we can cache earlier?
Comment #5
catchIt doesn't save a lot of time, although if we find more things to prewarm it might save more.
I was profiling the config translation sync + first front page request when installing Umami.
The biggest improvement we could make would be switching to a live container for later parts of the installer. Right now we compile the installer container for every batch iteration, even after all modules are installed. Then we compile it on the first request to the site too, since it's the first real container to get requested.
If we moved that first rebuild to the site information form submission step and had a real site to work with after that, then the container and the router would be in place much earlier.
Would need an install.php route that we can redirect to from the installer proper or something.