The designLoader plugin loads too much data Magento\Theme\Plugin\LoadDesignPlugin

[ilnytskyi]

Summary (*)

When we create custom controllers they will be always affected by design loader plugin
DI definition

    <type name="Magento\Framework\App\ActionInterface">
        <plugin name="designLoader" type="Magento\Theme\Plugin\LoadDesignPlugin"/>
    </type>

When we take a look what it does; It leads to \Magento\Framework\View\DesignLoader::load method
The method does too much work. It loads design, translation, and design updates.

        $area = $this->_areaList->getArea($this->appState->getAreaCode());
        $area->load(\Magento\Framework\App\Area::PART_DESIGN);
        $area->load(\Magento\Framework\App\Area::PART_TRANSLATE);
        $area->detectDesign($this->_request);

Examples (*)

This plugin adds its overhead to controllers dispatching. It affects performance and increases cache storage usage (read).
Even if controller does not use design updates or translations those data still being loaded from cache.

It leads to some overhead on custom controllers, or additional ajax requests.
Moreover many requests like this can increase network transfer to application and hardware usage that increases the price of hosting bills and affects store performance.
Big design and translations objects can add 500Kb or more to network transfer/disk usage on every requests
As described in docs https://devdocs.magento.com/guides/v2.4/config-guide/cache/two-level-cache.html

A standard Magento instance transfers around 300kb per request

300kb from stock is already a lot
And in the real magento's world when merchants install more extensions, the transfer can be even bigger.

Possible workaround is to disable native design loader, and replace it with custom for needed controllers

    <type name="My\Custom\Controller\Implementation">
        <plugin name="designLoader" disabled="true"/>
        <plugin name="customLoader" type="My\Custom\Controller\Plugin\CustomDataLoader"/>
    </type>

Proposed solution

Sometimes it's not enough to just disable the designLoader plugin
That would be better to separate the designLoader plugin in 3 different plugins like

    <type name="Magento\Framework\App\ActionInterface">
        <plugin name="designLoader" type="Magento\Theme\Plugin\LoadDesignPlugin"/>
        <plugin name="translationLoader" type="Magento\Theme\Plugin\LoadTranslationPlugin"/>
        <plugin name="somethingElseLoader" type="Magento\Theme\Plugin\SomethingElseLoader"/>
    </type>

That would give the developers more control over controllers out of box
If we need to disable translation and something else, just do it in DI

    <type name="My\Custom\Controller\Implementation">
        <plugin name="translationLoader" disabled="true"/>
        <plugin name="somethingElseLoader" disabled="true"/>
    </type>

In this case the My\Custom\Controller\Implementation can be used as a fast and ligth endpoint to return some data to frontend.
And in many cases there no need to use XML layout, blocks or translate the data
This can be the way to create fast custom controllers or optimize existent.

It also can be documented that devs can disable unneeded plugins if their data is not required
List of them here:

"storeCheck"
"designLoader"
tax-app-action-dispatchController-context-plugin
"customerNotification"
"catalog_app_action_dispatch_controller_context_plugin"
customer-app-action-dispatchController-context-plugin
weee-app-action-dispatchController-context-plugin

The same is applicable to API and GraphQL controllers e.g.
One of the fastest in magento that used in checkout do not really need to load translations or other cached data, but because of the
designLoader plugin they still consume resources.
POST /rest/all/V1/customers/isEmailAvailable or POST /rest/all/V1/guest-carts/{cart_id}/estimate-shipping-methods

---

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• Severity: S0 - Affects critical data or functionality and leaves users with no workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @ilnytskyi. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

🕙 You can find the schedule on the Magento Community Calendar page.

📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[ilnytskyi]

Guys who worked recently with controllers improvement for 2.4, your opinions needed
@lbajsarowicz @lenaorobei @ihor-sviziev

[lbajsarowicz]

@ilnytskyi Great idea to optimize that. I'm putting that on my list and will be back with the review soon.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 14 days if no further activity occurs. Is this issue still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? Thank you for your contributions!

[ihor-sviziev]

I think this still valid, and as it's related to performance - I think it would be s2 p2.
@sidolov @sivaschenko, what do you think?