Slow admin/config page load

The idea of this is to alert system admins to problems when they might not be looking for them - however, agreed it's very expensive to do this every time you're browsing to this page. I also wonder if people actually follow the link vs. just doing what they're trying to do.

Tagging for product manager and usability review, since removing the warning altogether seems like a decision for them.

If we can't completely remove it, I wonder if we could put it behind flood control instead, so that it only runs every 24 hours or similar? That way if there's a persistent warning on the status report, you'll get alerted to it within a day, but you don't get the performance hit every time you visit the page.

Another possibility might be to check this on cron once every 24 hours (again using flood control or a timestamp to avoid running it too often), set a value if it's OK, and then we could look for that and skip the check if so. If it's not OK, then run the check as we currently do (to avoid showing an error if things have been fixed in-between).

Think also a test case could benefit in showing the issue. Though not sure how to simulate a large site and if it's testing load time.

If the status check is indeed the culprit, that would also explain why admin/reports/status also takes a good few seconds to load for me on sites that also have this slow loading issue on admin/config. I think a fast loading UI should be the priority on both routes, and have the status check done asynchronously with the results displayed from cache if possible. Doing the checks on cron can be part of the solution, but there will be places where getting that info updated (such as on admin/reports/status) on command will be necessary, so an ideal solution would be if it can be run as a batch operation or something similar that shows progress like checking for updates does.

As for how to replicate this in a test, one way might be create a whole bunch of test modules that add additional \hook_requirements() implementations that do file system checks or other things that might introduce a bit of overhead. Short of just pulling in a bunch of existing contrib modules for the test, that's how I'd try to accomplish it. If that doesn't work, it might be good to take an inventory of the modules in use on sites that are experiencing this, and then figure out what checks they're doing that might be a performance issue, to replicate those in a test.

Confirming this patch has a huge improvement on complex websites when visiting the configurations screen. In my project it went from a 10 second pageload to a 1 second pageload. This is what Drupal should be capable of, running complex content management systems, which work fast in day to day content and configuration manipulations.
I agree that this should not run on the configuration screen, but only on a dedicated page as the report status or by implementing a cronjob task as suggested inside this thread.

Another option on top of #5 would be to put this in a lazy builder, then at least with bigpipe it won't block the page from loading.

I've tested the provided patch and observed a significant improvement in the load times for the admin/config page. This change greatly enhances the usability of the configuration page in larger projects.

I agree with the suggestion to run these checks less frequently, such as through a cron job or lazy loading, to ensure we still catch potential issues without affecting performance. Implementing this would provide a balanced approach to maintain site health without compromising speed.