#Performance

I think the previous title was a bit more succinct in what we're fixing here.

The "knock on" effects are exactly what we're fixing here, the performance benefits of simply not attempting to build any sections if layout builder is not enabled are the fix.

I've updated the IS a bit.

Although the IS mentions sort of 'knock-on' effects of the main issue, might help to distinguish which of those 'knock-on's' getting 'knocked on the head' by this issue. Are there any follow-ups required?

Attempt to simplify the title after reading through the comments.

I think this is still a valid idea.

Addressed the outstanding MR comments. I think the cache contexts for the LanguageBlock might not be as complex as thought, unless I'm missing something, but I also think it's fine to handle in a follow up if not adequately addressed.

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!

In that case lets do it! Fingers crossed

catch → closed merge request !12701

Thanks for the 10.x MR, committed/pushed to 10.6.x and cherry-picked to 10.5.x too.

It affects one project with an issue and a super easy BC compatible fix, I think we're safe to move forward.

Another dumb question if it's a breaking change should we wait for D12? Or think 11.3 is fine?

Posted an MR against 10.5.x (that will also work for 10.6.x) as this is definitely worth back porting.

Rebased

catch → closed merge request !12683

Committed/pushed to 11.x and cherry-picked to 11.2.x, thanks! Doesn't cherry-pick cleanly to 10.6.x

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.

Cross-posted but I was going to say the same as #10 and add the needs follow-up tag which it now doesn't need because the follow-up exists.

✨ Add the notion of a 'configured layout builder block' to solve a number of content-editor and performance pain points Active and anything else that gets rid of derivatives would help with #14.

Opened a follow-up 📌 Add schema wrapper argument to \Drupal\Core\Config\StorableConfigBase::castValue() and do not store it as a property on the config object Active

We could deprecate the \Drupal\Core\Config\StorableConfigBase::$schemaWrapper property and add it as a third argument to \Drupal\Core\Config\StorableConfigBase::castValue(). But let's do that in a follow-up so we can backport this to 10.5.x and 11.2.x

Thanks, @alexpott. The way I tried testing before was:

1. install umami
2. export config
3. copy views config yml to a separate folder
4. install umami again
5. drush cim --partial --source={folder with views files exported before}

Which wasn't showing a lot of difference in memory usage.

But now, testing with:

1. install umami
2. export config
3. Run script to change views config per #8
4. drush cim

I'm seeing:
Before
[notice] Synchronized configuration: update views.view.archive. [1.3 sec, 26.3 MB]
[notice] Synchronized configuration: update views.view.articles_aside. [1.3 sec, 27.16 MB]
[notice] Synchronized configuration: update views.view.block_content. [1.31 sec, 28.65 MB]
[notice] Synchronized configuration: update views.view.content. [1.33 sec, 29.9 MB]
[notice] Synchronized configuration: update views.view.content_recent. [1.34 sec, 30.83 MB]
[notice] Synchronized configuration: update views.view.featured_articles. [1.35 sec, 30.05 MB]
[notice] Synchronized configuration: update views.view.files. [1.37 sec, 32.6 MB]
[notice] Synchronized configuration: update views.view.frontpage. [1.38 sec, 33.78 MB]
[notice] Synchronized configuration: update views.view.glossary. [1.39 sec, 33.74 MB]
[notice] Synchronized configuration: update views.view.media. [1.41 sec, 35.61 MB]
[notice] Synchronized configuration: update views.view.media_library. [1.44 sec, 38.83 MB]
[notice] Synchronized configuration: update views.view.moderated_content. [1.46 sec, 39.92 MB]
[notice] Synchronized configuration: update views.view.promoted_items. [1.48 sec, 39.83 MB]
[notice] Synchronized configuration: update views.view.recipe_collections. [1.48 sec, 40.52 MB]
[notice] Synchronized configuration: update views.view.recipes. [1.5 sec, 39.25 MB]
[notice] Synchronized configuration: update views.view.related_recipes. [1.51 sec, 40.2 MB]
[notice] Synchronized configuration: update views.view.taxonomy_term. [1.51 sec, 41.2 MB]
[notice] Synchronized configuration: update views.view.user_admin_people. [1.53 sec, 42.85 MB]
[notice] Synchronized configuration: update views.view.watchdog. [1.55 sec, 44.52 MB]
[notice] Synchronized configuration: update views.view.who_s_new. [1.55 sec, 45.15 MB]
[notice] Synchronized configuration: update views.view.who_s_online. [1.56 sec, 43.57 MB]
[notice] Finalizing configuration synchronization. [1.65 sec, 44.03 MB]
[success] The configuration was imported successfully. [1.66 sec, 44.03 MB]

After
[notice] Synchronized configuration: update views.view.archive. [1.07 sec, 26.37 MB]
[notice] Synchronized configuration: update views.view.articles_aside. [1.08 sec, 27.22 MB]
[notice] Synchronized configuration: update views.view.block_content. [1.09 sec, 28.71 MB]
[notice] Synchronized configuration: update views.view.content. [1.1 sec, 28.36 MB]
[notice] Synchronized configuration: update views.view.content_recent. [1.11 sec, 29.29 MB]
[notice] Synchronized configuration: update views.view.featured_articles. [1.12 sec, 27.03 MB]
[notice] Synchronized configuration: update views.view.files. [1.15 sec, 27.41 MB]
[notice] Synchronized configuration: update views.view.frontpage. [1.16 sec, 28.58 MB]
[notice] Synchronized configuration: update views.view.glossary. [1.17 sec, 27.96 MB]
[notice] Synchronized configuration: update views.view.media. [1.19 sec, 29.1 MB]
[notice] Synchronized configuration: update views.view.media_library. [1.22 sec, 31.11 MB]
[notice] Synchronized configuration: update views.view.moderated_content. [1.24 sec, 30.25 MB]
[notice] Synchronized configuration: update views.view.promoted_items. [1.25 sec, 29.06 MB]
[notice] Synchronized configuration: update views.view.recipe_collections. [1.26 sec, 29.74 MB]
[notice] Synchronized configuration: update views.view.recipes. [1.27 sec, 26.86 MB]
[notice] Synchronized configuration: update views.view.related_recipes. [1.28 sec, 27.81 MB]
[notice] Synchronized configuration: update views.view.taxonomy_term. [1.28 sec, 28.81 MB]
[notice] Synchronized configuration: update views.view.user_admin_people. [1.3 sec, 29.49 MB]
[notice] Synchronized configuration: update views.view.watchdog. [1.32 sec, 29.67 MB]
[notice] Synchronized configuration: update views.view.who_s_new. [1.32 sec, 30.3 MB]
[notice] Synchronized configuration: update views.view.who_s_online. [1.33 sec, 27.11 MB]
[notice] Finalizing configuration synchronization. [1.36 sec, 27.57 MB]
[success] The configuration was imported successfully. [1.36 sec, 27.57 MB]

Seeing a significant improvement! Moving to RTBC.

@godotislate you can easily see this with Umami...

Before

 [notice] Synchronized configuration: update views.view.archive. [1.04 sec, 53.45 MB]
 [notice] Synchronized configuration: update views.view.articles_aside. [1.05 sec, 54.3 MB]
 [notice] Synchronized configuration: update views.view.block_content. [1.07 sec, 55.4 MB]
 [notice] Synchronized configuration: update views.view.content. [1.1 sec, 56.36 MB]
 [notice] Synchronized configuration: update views.view.content_recent. [1.11 sec, 57.29 MB]
 [notice] Synchronized configuration: update views.view.featured_articles. [1.12 sec, 58.13 MB]
 [notice] Synchronized configuration: update views.view.files. [1.16 sec, 60.13 MB]
 [notice] Synchronized configuration: update views.view.frontpage. [1.18 sec, 60.92 MB]
 [notice] Synchronized configuration: update views.view.glossary. [1.2 sec, 62.38 MB]
 [notice] Synchronized configuration: update views.view.media. [1.24 sec, 62.76 MB]
 [notice] Synchronized configuration: update views.view.media_library. [1.29 sec, 64.87 MB]
 [notice] Synchronized configuration: update views.view.moderated_content. [1.32 sec, 65.27 MB]
 [notice] Synchronized configuration: update views.view.promoted_items. [1.34 sec, 66.98 MB]
 [notice] Synchronized configuration: update views.view.recipe_collections. [1.36 sec, 66.65 MB]
 [notice] Synchronized configuration: update views.view.recipes. [1.37 sec, 67.49 MB]
 [notice] Synchronized configuration: update views.view.related_recipes. [1.38 sec, 68.44 MB]
 [notice] Synchronized configuration: update views.view.taxonomy_term. [1.4 sec, 67.96 MB]
 [notice] Synchronized configuration: update views.view.user_admin_people. [1.43 sec, 69.54 MB]
 [notice] Synchronized configuration: update views.view.watchdog. [1.46 sec, 71.66 MB]
 [notice] Synchronized configuration: update views.view.who_s_new. [1.47 sec, 71.16 MB]
 [notice] Synchronized configuration: update views.view.who_s_online. [1.48 sec, 71.87 MB]

After

 [notice] Synchronized configuration: update views.view.archive. [1.16 sec, 53.45 MB]
 [notice] Synchronized configuration: update views.view.articles_aside. [1.17 sec, 54.3 MB]
 [notice] Synchronized configuration: update views.view.block_content. [1.19 sec, 54.55 MB]
 [notice] Synchronized configuration: update views.view.content. [1.22 sec, 53.74 MB]
 [notice] Synchronized configuration: update views.view.content_recent. [1.23 sec, 54.67 MB]
 [notice] Synchronized configuration: update views.view.featured_articles. [1.24 sec, 55.51 MB]
 [notice] Synchronized configuration: update views.view.files. [1.28 sec, 56.5 MB]
 [notice] Synchronized configuration: update views.view.frontpage. [1.3 sec, 55.66 MB]
 [notice] Synchronized configuration: update views.view.glossary. [1.32 sec, 57.12 MB]
 [notice] Synchronized configuration: update views.view.media. [1.35 sec, 56.18 MB]
 [notice] Synchronized configuration: update views.view.media_library. [1.41 sec, 55.13 MB]
 [notice] Synchronized configuration: update views.view.moderated_content. [1.45 sec, 54.43 MB]
 [notice] Synchronized configuration: update views.view.promoted_items. [1.47 sec, 56.14 MB]
 [notice] Synchronized configuration: update views.view.recipe_collections. [1.48 sec, 54.95 MB]
 [notice] Synchronized configuration: update views.view.recipes. [1.51 sec, 55.79 MB]
 [notice] Synchronized configuration: update views.view.related_recipes. [1.52 sec, 56.74 MB]
 [notice] Synchronized configuration: update views.view.taxonomy_term. [1.54 sec, 55.03 MB]
 [notice] Synchronized configuration: update views.view.user_admin_people. [1.58 sec, 54.87 MB]
 [notice] Synchronized configuration: update views.view.watchdog. [1.6 sec, 56.75 MB]
 [notice] Synchronized configuration: update views.view.who_s_new. [1.61 sec, 55.3 MB]
 [notice] Synchronized configuration: update views.view.who_s_online. [1.62 sec, 56.01 MB]

Here's a script to change something meaningless on each of umami's views....

foreach (\Drupal\views\Entity\View::loadMultiple() as $view) {
  $view->set('description', $view->get('description') . '1')->save();
}

Should this one be closed?

I don't have a test site with a ton of views, or at least, enough views, to validate the memory usage reduction. I tried installing umami, tweaking the views there, and running config import, but the numbers were not noticeably different.

That said, these changes make sense to me, and I validated that the schemaWrapper does not get used outside of save()/castValue() and is safe to set to NULL.

RTBC +1. Holding off moving in case someone wants to validate the memory leak fix.

While this fix will be most pronounced on config import - it will also benefit every config save where we don't set the trusted flag to true. So that's config forms, some post updates, hooks - lots of places.

🐛 Saving untrusted config results in memory leak Active fixes the config casting part of this :)

Finally we get around to fixing what @fabianx pointed out in #2294569-10: Determine cause of high memory consumption →

With this change we see a massive difference

 [notice] Synchronized configuration: update views.view.archive. [6.76 sec, 135.48 MB]
 [notice] Synchronized configuration: update views.view.association_entity_reference. [6.77 sec, 136.38 MB]
 [notice] Synchronized configuration: update views.view.associations_multiply. [6.79 sec, 137.76 MB]
 [notice] Synchronized configuration: update views.view.authmap. [6.8 sec, 138.55 MB]
 [notice] Synchronized configuration: update views.view.changelogs. [6.8 sec, 138.95 MB]
 [notice] Synchronized configuration: update views.view.channel_errors. [6.82 sec, 140.29 MB]
 [notice] Synchronized configuration: update views.view.channels. [6.83 sec, 141.26 MB]
 [notice] Synchronized configuration: update views.view.code_pools_collections. [6.84 sec, 141.95 MB]
 [notice] Synchronized configuration: update views.view.content. [6.86 sec, 135.06 MB]
 [notice] Synchronized configuration: update views.view.current_user_organizations. [6.88 sec, 136 MB]
 [notice] Synchronized configuration: update views.view.custom_forms. [6.9 sec, 138.02 MB]
 [notice] Synchronized configuration: update views.view.customer. [6.95 sec, 138.05 MB]
 [notice] Synchronized configuration: update views.view.customer_emails. [7.32 sec, 155.2 MB]
 [notice] Synchronized configuration: update views.view.easy_email_content. [7.33 sec, 156.01 MB]
 [notice] Synchronized configuration: update views.view.email_evs_to_customer_report. [7.34 sec, 157.57 MB]
 [notice] Synchronized configuration: update views.view.event. [7.35 sec, 158.29 MB]
 [notice] Synchronized configuration: update views.view.event_winners. [7.38 sec, 153.9 MB]
 [notice] Synchronized configuration: update views.view.events_list. [7.39 sec, 154.64 MB]
 [notice] Synchronized configuration: update views.view.events_summary. [7.4 sec, 155.43 MB]
 [notice] Synchronized configuration: update views.view.evs_file_upload_type. [7.4 sec, 155.73 MB]
 [notice] Synchronized configuration: update views.view.evs_to_customer_submissions. [7.43 sec, 154.71 MB]
 [notice] Synchronized configuration: update views.view.ffh_approval_queue. [7.47 sec, 154.67 MB]
 [notice] Synchronized configuration: update views.view.files. [7.49 sec, 156.25 MB]
 [notice] Synchronized configuration: update views.view.frontpage. [7.51 sec, 153.5 MB]
 [notice] Synchronized configuration: update views.view.glossary. [7.52 sec, 154.24 MB]
 [notice] Synchronized configuration: update views.view.manage_affiliates_banners. [7.53 sec, 154.92 MB]
 [notice] Synchronized configuration: update views.view.manage_channels. [7.54 sec, 155.62 MB]
 [notice] Synchronized configuration: update views.view.manage_offer_banners. [7.56 sec, 153.71 MB]
 [notice] Synchronized configuration: update views.view.manage_offer_groups. [7.58 sec, 155.09 MB]
 [notice] Synchronized configuration: update views.view.manage_offers. [7.64 sec, 156.49 MB]
 [notice] Synchronized configuration: update views.view.manage_organization_channel_mappings. [7.65 sec, 157.2 MB]
 [notice] Synchronized configuration: update views.view.manage_organizations. [7.68 sec, 160.52 MB]
 [notice] Synchronized configuration: update views.view.manage_poe_uploads. [7.69 sec, 161.13 MB]
 [notice] Synchronized configuration: update views.view.manage_pricing_promotion_announcements. [7.7 sec, 161.81 MB]
 [notice] Synchronized configuration: update views.view.manage_regions. [7.72 sec, 153.73 MB]
 [notice] Synchronized configuration: update views.view.manage_sbs_banners. [7.73 sec, 154.38 MB]
 [notice] Synchronized configuration: update views.view.manage_sub_offers. [7.77 sec, 155.81 MB]
 [notice] Synchronized configuration: update views.view.manage_telus_employees. [7.78 sec, 156.94 MB]
 [notice] Synchronized configuration: update views.view.manage_webstore_urls. [7.81 sec, 154.35 MB]
 [notice] Synchronized configuration: update views.view.message. [7.82 sec, 155.16 MB]
 [notice] Synchronized configuration: update views.view.offer_sub_offers. [7.85 sec, 153.86 MB]
 [notice] Synchronized configuration: update views.view.pricing_announcement. [7.86 sec, 154.78 MB]
 [notice] Synchronized configuration: update views.view.redirect. [7.87 sec, 155.66 MB]
 [notice] Synchronized configuration: update views.view.system_notifications. [7.91 sec, 155.07 MB]
 [notice] Synchronized configuration: update views.view.taxonomy_term. [7.92 sec, 155.56 MB]
 [notice] Synchronized configuration: update views.view.telus_channels. [7.92 sec, 156.22 MB]
 [notice] Synchronized configuration: update views.view.telus_store. [7.95 sec, 154.59 MB]
 [notice] Synchronized configuration: update views.view.telus_user_entity_reference. [7.98 sec, 154.55 MB]
 [notice] Synchronized configuration: update views.view.unconfigured_accounts_report. [7.99 sec, 155.32 MB]
 [notice] Synchronized configuration: update views.view.user_admin_people. [8.06 sec, 156.58 MB]
 [notice] Synchronized configuration: update views.view.view_all_epp_organizations. [8.09 sec, 153.86 MB]
 [notice] Synchronized configuration: update views.view.view_epp_organizations. [8.11 sec, 155.9 MB]
 [notice] Synchronized configuration: update views.view.track_announcement_acknowledgements. [8.14 sec, 154.3 MB]
 [notice] Synchronized configuration: update views.view.telus_request. [8.21 sec, 158.04 MB]
 [notice] Synchronized configuration: update views.view.splash_page_sbs_orgs. [8.22 sec, 158.43 MB]
 [notice] Synchronized configuration: update views.view.sbs_submissions_table. [8.48 sec, 175.01 MB]
 [notice] Synchronized configuration: update views.view.sbs_submissions_data_lake_report. [8.54 sec, 180.27 MB]
 [notice] Synchronized configuration: update views.view.sbs_data_lake_report. [8.58 sec, 184.39 MB]
 [notice] Synchronized configuration: update views.view.referral_results_dashboard. [8.67 sec, 160.15 MB]
 [notice] Synchronized configuration: update views.view.rebate_form_submissions. [8.73 sec, 156.97 MB]
 [notice] Synchronized configuration: update views.view.poe_audit. [8.76 sec, 160.05 MB]
 [notice] Synchronized configuration: update views.view.perks_campaign. [8.84 sec, 158.06 MB]
 [notice] Synchronized configuration: update views.view.migration_requests. [8.87 sec, 161.27 MB]
 [notice] Synchronized configuration: update views.view.master_event_report. [8.98 sec, 161.34 MB]
 [notice] Synchronized configuration: update views.view.manage_channel_mappings. [8.99 sec, 162.51 MB]
 [notice] Synchronized configuration: update views.view.lead_nurturing_for_dealers. [9.03 sec, 154.6 MB]
 [notice] Synchronized configuration: update views.view.hot_leads_reporting. [9.07 sec, 155.03 MB]
 [notice] Synchronized configuration: update views.view.evs_error_submissions. [9.11 sec, 155.97 MB]
 [notice] Synchronized configuration: update views.view.evs_customer_events. [9.16 sec, 155.95 MB]
 [notice] Synchronized configuration: update views.view.event_submission_report. [9.26 sec, 160.18 MB]
 [notice] Synchronized configuration: update views.view.event_form_submissions. [9.32 sec, 156.51 MB]
 [notice] Synchronized configuration: update views.view.epp_data_lake_report. [9.42 sec, 159.7 MB]
 [notice] Synchronized configuration: update views.view.dealer_traffic_reporting. [9.44 sec, 160.82 MB]
 [notice] Synchronized configuration: update views.view.customer_sbs_vip_referral_report. [9.55 sec, 160.18 MB]
 [notice] Synchronized configuration: update views.view.customer_sbs_referral_report. [9.69 sec, 162.86 MB]
 [notice] Synchronized configuration: update views.view.customer_iq_submissions. [9.73 sec, 166.37 MB]
 [notice] Synchronized configuration: update views.view.customer_event_tracking. [9.74 sec, 167.45 MB]
 [notice] Synchronized configuration: update views.view.customer_consumer_vip_referral_report. [9.82 sec, 158.14 MB]
 [notice] Synchronized configuration: update views.view.customers_multiply. [9.88 sec, 156.37 MB]
 [notice] Synchronized configuration: update views.view.customers_affiliates. [10.06 sec, 165.89 MB]
 [notice] Synchronized configuration: update views.view.customers. [10.35 sec, 177.81 MB]
 [notice] Synchronized configuration: update views.view.bib_request_queue. [10.45 sec, 159.49 MB]
 [notice] Synchronized configuration: update views.view.all_customer_codes. [10.62 sec, 166.13 MB]
 [notice] Synchronized configuration: update views.view.affiliates_data_lake_report. [10.67 sec, 170.31 MB]
 [notice] Synchronized configuration: update views.view.admin_form_submissions. [10.73 sec, 155.47 MB]

#14 should work and would allow other modules to tweak the output of the plugin without completely replacing it.

One solution could be for the system menu block to add a "fake" condition to the query (like system_menu_block = TRUE), and workspaces could check for that parameter condition before removing the enabled one.

catch → credited amateescu → .

I discusssed this with @amateescu in slack and he's not convinced that this is safe to do.

The workspaces code operates on any code that's loading a menu tree, not only the system menu block, so it's removing the condition in cases where it could have been added from elsewhere. Unless we add some kind of explicit alter hook for the system menu block itself, it's not going to be straightforward to target this only at that block.

Moving back to needs work and adding the subsystem maintainer review tag (even if the subsystem is more workspaces than system module.

smustgrave → credited mstrelan → .

Applied the suggestion, rest LGTM :)

Using some of your SVGs and trimming the others by reducing decimal precision and moving the Font Awesome credit to the repo license file . Dunno if that was worth the effort but I'll include it in the next release.

Re: #18

Thanks @jwilson for all your tests and elaborations!

I probably just noticed one thing in the the BPP calculation which might have a "significant" impact (8x) on the actual filesize of the first requested image.

In the link you posted it says

The threshold is currently 0.05 bits of image data per displayed pixel

and should be therefore divided by 8 since Google talks about bits and not bytes. So I guess it's effectively 40kb / 8 which would result in only 5kb instead which sounds a reasonable size for an own request and should not add a big delay (and transfer cost)?

The patch in 32, 42 and 44 breaks the ordering of the elements. You cannot change the order of the elements anymore.

Cool!

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!

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!

Changing the patch so and empty base url is set to an empty string in the md5()
Interdiff:
```
- $this->persistentId = $settings->get('persistent_id') ?? $settings->get('key_prefix') ?? md5($base_url);
+ $this->persistentId = $settings->get('persistent_id') ?? $settings->get('key_prefix') ?? md5($base_url ?? '');
```

The md5 in the constructor gives a deprecation warning as the $base_url can be NULL;

Left 1 small question on the MR. Rest looks good.

Committed f38f5f4 and pushed to 11.x. Thanks!

updated the CR too, thanks!

nod_ → closed merge request !11447

Committed c6d8e3f and pushed to 11.x. Thanks!

Replied on the MR - I think it would be a problem if that was possible, but I don't think it is for the menu block because there's no way alter this.

Thank you. The smaller viewport attribute is probably going to solve a longstanding bug where the icons sometimes paint oversize for a single frame while the CSS is loading.

My point of view is that if a site has 100 modules, and 25 of them add a computed field that takes 20ms to calculate, the site will have a response time that's 500ms slower just because of this.

In my use case, I have a computed field whose calculation is relatively expensive—it takes about 11 seconds every time it is calculated. This happens regardless of whether the computed field is actually used or accessed in the request. As a result, the whole request is delayed by 11 seconds, even when the computed field will not be read at all.

Most computed fields are used only in specific contexts (for example, when rendering a view or exporting structured data), and not in every code path that loads the entity. However, the current implementation calculates all computed fields for every entity load, causing substantial and unnecessary performance degradation.

Some key points to consider:

• As more computed fields are defined throughout a site, performance degrades incrementally, often in hidden or hard-to-detect ways.
• The impact is often only noticed when there are enough computed fields, or when one of them is slow to compute.
• Delaying (lazily evaluating) the calculation until field usage would avoid unnecessary work and make the impact of computed fields more predictable and manageable.
• This would bring Drupal in line with the principle of not doing expensive work unless and until it is explicitly needed by code.

To sum up:
Computed fields should not be evaluated unless their value is actually needed.
Implementing lazy evaluation would avoid hidden and potentially significant slowdowns in any site using computed fields.

Since there's been no follow up going to close out. If still a desired feature request then please re-open! Am saving credit though

Thanks!

The other two do not use $this->toolkitId as far as I see, so they don't require a change.

I'd create an issue in the other two add well just for visibility.

This needs significant from someone, I'm not sure who, but it seems like a low risk BC break.

@scott_euser here is some reason comparisons between the two:

• https://elementor.com/blog/webp-vs-avif/
• https://crystallize.com/blog/avif-vs-webp
• https://themeisle.com/blog/avif-vs-webp/

All three articles agree that AVIF’s superior compression leads to smaller image file sizes, which can reduce bandwidth usage and potentially lower energy consumption during data transmission. However, AVIF’s increased decoding time may require more processing power on the client side, possibly offsetting some energy savings.

Just adding some additional references here about the importance of this:

• https://ffw.com/en-GB/insights/thought/5-tips-to-achieve-a-100-performan...
• https://talkingdrupal.com/289

Just adding @dunx to the metadata of this issue.

Looking back at this issue now.

ImageAPI Optimize → looks quite flexible, it will work for D10 & 11 but does require another 3rd party system. It would be interesting to see if that could be incorporated into Drupal CMS but unsure if it would be a good candidate for Core. Image optimization should be easy, but building in a 3rd party into Core would be a problem (not matter which one).

Imagemagick → could also do the trick, and has more installs.

Some MIT projects that might be worth looking at:

• Spatie’s Image Optimizer (PHP)
• Gulp-Imagemin for JS-based workflows
• (JS)

This is better than I expected, as it saves not just the config but also the toolkit lookup and on a cache miss discovery on a regular request and it doesn't just postpone it, it should actually move it out completely to the actual image style request.

It's "only" two fast chained apcu cache lookups, but still.

> Anyway to cover with a deprecation. Like if Core version is 11.3 or great trigger a deprecation that toolkitId won't be set?

The problem is that it we still use the property but we switch to lazy initialize. There's still the setter as well, we can't drop that completely (although having the setter at all seems somewhat problematic as the service has then state and it could change. But that's out of scope.

The only idea I have is that we could introduce a new property and deprecate the old. But that's a quite a bit of complexity. I've already created an issue in the brandfolder project: 📌 Core change to ImageFactory might break this Active .