#Performance

Automatically closed - issue fixed for 2 weeks with no activity.

I think this might be covered by 📌 Add CacheOptionalInterface to more blocks Needs review , moving to postponed until that's done, then we can revisit whether there's anything missing after that.

Back to green after ✨ Optimize redirect chain retrieval in VariationCache Active

There has been similar code in Umami since it was committed to core, most recent change was 🐛 Umami page.tpl.php breaks block placeholders Needs review .

Also just found 🐛 Umami theme ignores placeholders and HTML replaced elements when checking for empty regions Needs work which looks similar.

Rebased 📌 Recursively replace placeholders in CachedStrategy Active which was postponed on this issue.

Tagging for release highlights because we should summarise the overall rendering performance gains between 11.1 and 11.2 somehow.

It is. It's the new API that we introduced here.

The CachedStrategy itself isn't that CR-worthy (IMO) as it is merely an optimization.

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

Implemented the recursion. We don't have double-nested, cached, placeholders in core or at least not that I can think of, or that are covered by performance tests, but this does show the improvement for the single-nested cached placeholders in the navigation bar - e.g. shortcut and user menu placeholders now are now one multiple get instead of two gets.

The change record that is linked to this issue is not correct it seems?

berdir → closed merge request !9798

berdir → changed the visibility of the branch 2232375-make-language-switcher to hidden.

Seems like a good backport.

Attempt at a new title

Created a MR for the interface backport.

Not the same thing but given they both affect SystemMessagesBlock adding the placeholder strategy denylist issue too - both are based on the system messages block being extremely cheap to render overall.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

As quickly discussed on slack, changing how the links are build is challenging because it's a pluggable system depending on your language negotiation settings. See \Drupal\language\Plugin\LanguageNegotiation\LanguageNegotiationUrl::getLanguageSwitchLinks, session/cookie based language adds its own query parameter that it then uses on the given request to put it back into a cookie. It's not impossible but tricky with BC and relying on this happening and so on.

FWIW, I'm reasonably certain that building this is faster than fetching from cache, based on renderering time debug output (had to hack it to show times also for non-cacheable elements), it's also the same right now in HEAD. But there might indeed be edge case such as it being the only thing it has to render with twig.

I also verified that this fixes OpenTelemetryFrontPagePerformanceTest.php with 🐛 [pp-3] Bubbling of elements' max-age to the page's headers and the page cache Postponed , which currently fails as this block prevents it from being a page cache hit.

It's also no change compared to HEAD. The block is currently being autoplaceholdered and not cached as well, just also in a way that that information up.

I also created 📌 Add CacheOptionalInterface to more blocks Needs review as a follow and want to add a change record for this.

🐛 Page cache creates vast amounts of unneeded cache data Active is getting more attention recently (maybe more bad crawlers around?), and the dynamic_page_cache not varying by query parameters unless it actually has to is one of the mitigations for that issue. Both varying the dynamic page cache by query params, or introducing a separate cache item that does, would make that particular issue worse for people I think. So for me that leads strongly towards option #c.

I did think of one other possible approach when reading the IS:

What if we made a special placeholder (similar to CSRF placeholder handling) for only the query string and replace only that? Then we could remove the query string cache context but handle it all in PHP still.

This also made me wonder how bad would it be if we dropped the query string entirely - usually when I change language on a site I'm either testing, or it's the first thing I do when I land on the site, not 5 pages into a pager (which might not show the same results anyway). But probably if we did that someone would be relying on it somewhere.

Issue summary updated

Leaving at needs work, need to update the issue summary with the options and questions.

Rebased.

Rebased.

Thank you for creating this issue to improve Drupal.

We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

AVIF is expensive (x2-x3 vs WEBP on compression) so fits for hires images mostly

While AVIF is better for compression, I am finding it hard to come to a conclusion as to whether AVIF is a good recommendation vs WEBP purely from an environmental impact of power consumption perspective. I.e., the power needeed to compress/decompress WEBP seems to be compared to PNG, but all I can find is random blog posts without any quantitative analysis that keep saying AVIF compress/decompress is more expensive, outweighing the savings from reduced data transfer/bandwidth. I really find it hard to find anything conclusive though - has anyone else looked into it from that perspective?

Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.