#Performance

Updated the IS proposed resolution to match the work done so far.

Rebased to get a fresh test failure baseline. Removing needs tests tag because these were added.

Combined MR with 📌 Pass RenderContext around in the Renderer Active is green now and removes about 500 lines of code.

To see a larger reduction in the number of database queries on cold caches, we need 📌 Use a lazy builder/placeholder for the top bar Active and 📌 Views entity rendering should use a lazy builder/placeholder Active - but those can happen independently of this issue.

I think it would be good to have all options available. Although we see it as an edge case, it may be useful for others.

Here is an article with a section about using the `low` option on above the fold images (as @damien already said a carousel is one of the scenarios).

catch → closed merge request !11784

catch → changed the visibility of the branch 3496369-with-more-placeholdering to hidden.

I'll be honest, there was no intent of using this module for large lists of nodes when built. If someone wants to work on a more performant filtering option (perhaps as a sub-module) I'm open to it, but for large amounts of entries an entity reference autocomplete is probably the better option.

Closing this as a duplicate of 📌 [meta] Replace lazy service proxy generation with service closures Active which will change all of core's proxy classes to use service closures.

What about this in the 3.0.x branch instead

We have a simple select for "new" and "search for existing book" if they select the 2nd then an autocomplete field appears regardless of how many books there are?

Since one of the other library split issues got committed this one needed a rebase with updated performance metrics. I also updated the deprecation version, but I'm not going to roll back the RTBC status for that, especially since @alexpott allowed self-RTBCing in the other issue for the same minor update.

This issue can be added to the CR I made yesterday for the 11.3.0 splits: [#3530832].

https://thephp.foundation/blog/2025/06/08/php-30/ - 30 years of PHP: FrankenPHP is now part of the PHP organisation

Next performance improvement: #3510896-8: Remove candidate `DynamicPropSource`s from `/xb/api/v0/config/component` to a new internal HTTP API for `ContentTemplate`s instead of → .

Done: #3510896-8: Remove candidate `DynamicPropSource`s from `/xb/api/v0/config/component` to a new internal HTTP API for `ContentTemplate`s instead of → .

There's plenty more low-hanging fruit, see https://git.drupalcode.org/project/experience_builder/-/merge_requests/1....

There's also 📌 [PP-1] Refactor GeneratedFieldExplicitInputUxComponentSourceBase and FieldForComponentSuggester to need only SDC's ComponentMetadata, not SDC plugin instances Postponed to decouple this from SDCs.

But here's the real kicker: we don't need any of this until a ContentTemplate UI exists! So I've been wanting to remove dynamic_prop_sources from the /xb/api/v0/config/component response for a good while. Which is why 📌 Move `PropSourceEndpointTest` into new `XbConfigEntityHttpApiTest::testComponent()` Active has been assigned to me for months. That will simply remove these computations from the critical path!

Because the ContentTemplate UI should be able to just request the candidate dynamic prop sources on a per-content entity-t bundle basis. There's never a need to list them all across all entity types/bundles — I did that only for early PoC/testing purposes!

Yep, I knew this: #3515510-2: Improve backend API performance: add caching to shape matching → 👈 that's why I moved it to the issue queue component :) This essentially does exactly what I intended 😃

This is so old, thanks for keeping the dream! My patches were for D7 so I'm hiding them.

I’ve created a patch based on the latest version of merge request !97, introducing a few adjustments to ensure that redirect patterns are matched against URL aliases rather than just internal paths like /node/[nid]. This change supports a specific client requirement where redirects should be defined using node aliases, e.g., example-node-alias/*.

We should review this patch to verify its compatibility across different use cases and evaluate its potential impact on performance.

I don't see any more the get-data call so i guess I have another issue, thank you.

I will try to find out, non I don't have gin_toolbar my backoffice theme is claro.
Thank you for your return anyway.

📌 Get coffee data only when the search box is opened Active should have changed things so that the request isn't made until the search box is opened. If that's running all the time, something else is broken. Do you have e.g. gin_toolbar enabled?

yes I have tested with 2.0.1

@yonailo can you confirm you're already on version 2.0.1 of coffee?

I am experiencing big performance issues when editing a node. The get-data coffee's call is blocking the loading of ckeditor for 2-3 seconds, what can I do ?

Amending attribution.

Salacious title update

This was causing cypress fails for me locally due to the time out.

MR improves performance by 80%

Merged into 1.2.x and cherry-picked to 2.x, for a change.

Updated MR per feedback and adjusted tests.

@alexpott I think we'd need to leave the config key as optional permanently if nothing happens after this issue. We could open a follow-up to make it non-optional and try to implement that using the to-be-decided APIs in 🌱 [meta] Just in time updates Active and 🐛 Block plugins need to be able to update their settings in multiple different storage implementations Active though.

@catch asked my opinion on the nullable approach. I think it is a good one because the new key is not added during a config import so you're not getting unexpected changes. The one thing that gives me pause is how are we going to tell any modules or recipes that supply this config that they need to update. I.e. will we leave tis key as optional...

I was more concerned about how long we'd need to handle the missing config.

After looking at the actual code it's not really a huge concern.

The issue with this is how often do these blocks get resaved?

Here, it doesn't much matter because NULL/undefined is the same as FALSE for the new property, and FALSE is always a valid value.

It'd be an issue for any new block property that doesn't work like that. What I suggested in #15 could help address that, but if there are constraints where the default value is not valid with existing configuration, that would be another problem.

The issue with this is how often do these blocks get resaved?

Yes, the issue with LB overrides mentioned in 🐛 Block plugins need to be able to update their settings in multiple different storage implementations Active , among others, is why I wanted to avoid doing an upgrade path. I think it's okay to have the config key introduced over time on block saves?

For block entities specifically, I wonder if we can change get()<code> so that calling <code>get('settings') will merge in configuration from the plugin collection. That way additions in defaultConfiguration() from the plugin will be picked up in the loaded block entity. That doesn't really change anything here, but it could maybe apply to other situations?

Re: #15 (.loading class LCP issue) Thank you. I'll try to make sense of what you're saying and get to the bottom of this soon. But happy to have a PR if you know what the fix would be offhand. (The project is setup for DDEV running locally).

Re: #16 (SQIP) While SQIP is a "superior" image, there are two major reasons it is problematic: it is both resource intensive on the server-side and on the client-side. For the server-side, even if we were to reimplement `sqip` in PHP, I expect it will be a fair bit more resource intensive than simply scaling down a raster image to 8x8 and applying a simple box blur, which Drupal image styles can do for us OOTB today. On the client-side, the problem is the <g filter="blur(12px)"> which is applied via browser rendering. you can inspect https://3523781-drupal-lqip.elementalidad.com/images/hero.sqip.svg to see the file that was generated by the npm library.

The sqip command took about 2.6 seconds to run, used about 4 CPU cores, (thats >10s total compute time) for the 400kb image.

If you look at the animated GIF demonstrating the processing progression of the underlying binary used by sqip, it becomes fairly obvious this is intensive work: https://github.com/fogleman/primitive?tab=readme-ov-file#progression

Since there's been no follow up to #13 going to close out, but if still a valid task please re-open.

Ran the test-only feature and unfortunately it passed when it was expected to fail. So think the test needs a little tweaking

This looks great to me now.

The last remaining question for me is the nullable config. It avoids having to have an upgrade path, but it means saving menu blocks in the UI will gradually introduce the new config key over time. The other option would be to make it not nullable, and have a config entity update to add the default everywhere, as well as a hook_entity_presave() for exported config.

After discovering 🐛 Block plugins need to be able to update their settings in multiple different storage implementations Active I think this is probably the way we should start doing things though - e.g. allow a gradual update over time with runtime code compatibility.

MR updated per #12.

That looks good. I couldn't think of a good wording for 'the current page may or may not be in the active trail' but ""active-trail" class added to menu links in the current page's menu hierarchy." covers it implicitly really well.

Made the text changes and pushed. Thinking about this now, though:

When this is checked, the menu will have the same markup on every page. Otherwise the current page's position in the menu structure will be calculated and an 'active' class added to relevant menu links if it is found.

The class added in the core theme templates is menu-item--active-trail. There's also an is-active class added to a menu link if it is the current page, but that is added through JS. Still I wonder if "active" is not informative enough? Also, I'm not sure what the antecedent to the final "it" in the description text is.

My attempt/suggestion for an edit:

When this is checked, the menu will have the same markup on every page. Otherwise, the current page's position in the menu structure will be calculated and an "active-trail" class added to menu links in the current page's menu hierarchy.

Would be good to get recipe/Drupal CMS installer performance up to the same level as module installs everywhere else, so tagging with 11.3.0 release priority/highlights.

Merged into 2.x and cherry-picked to 1.2.x. Thanks!

Straightforward.

Some tests failed in the MR run, but performance tests are green which is the only change here https://git.drupalcode.org/issue/drupal_cms-3530523/-/jobs/5581535

Though maybe setting the value of the new property in defaultConfiguration() to TRUE makes that concern go away?

As in NULL and TRUE would be treated the same? I don't remember doing this but it seems possible. However:

Thought about this some more. If we have the new "track active trail" (wording TBD) field control the level and expand_all_items, and assuming "level" is set to 2, or expand_all_items unchecked, then when going from "track active trail" checked to unchecked, those fields would be hidden. And the result might be a bit unexpected to the user, even if help text is provided.

Yeah it starts getting complicated, good to think about how much work it would be before doing all the work.

Part of the problem might be the 'active trail' wording which is really an arcane internal menu system concept.

What about this for the checkbox label:

Show the same menu markup on every page

With description:

When this is checked, the menu will have the same markup on every page. Otherwise the current page's position in the menu structure will be calculated and an 'active' class added to relevant menu links if it is found.