Unnecessary initialization and operations of SEOMatic

[janreges]

Describe the bug

Hi nystudio107 guys :)

First of all, I want to thank you for your great work on Craft CMS plugins. We are happy to pay for a number of your plugins on multiple projects and they are of significant value to us. But allow me feedback on one important aspect. We will therefore be grateful if you make the review and similar improvements/optimizations in your other plugins as well.

SEOmatic performs a series of operations on absolutely every request within Craft CMS movement and throws 145 events, even if SEOmatic is not being used for anything on that CMS page. It's an unnecessary burden and slows down the CMS.

We use Craft CMS for several of our projects and are appalled at how much overhead some plugins cause and hinder absolutely all requests within the administration or frontend. We strive to point out these issues, because when using multiple plugins, it creates absolutely unnecessary tens or hundreds of milliseconds per request, decreasing the user experience, reducing resistance to DoS/DDoS attacks, and burning unnecessary electricity.

In the case that lazy-loading cannot be effectively applied for some reason, please also consider a tagged cache of entire instances of PHP classes. In the event that the SEOmatic settings are not reconfigured, it is certainly not necessary to perform a whole series of operations for each request. I have communicated this to Brandon in a similar vein as part of other performance issues within Craft CMS/Neo/SuperTable and he will take this into consideration as well - craftcms/cms#13297

To reproduce

Steps to reproduce the behaviour:

1. Go to any page in Craft CMS which has absolutely no need to work with SEOmatic (for example PHP info in Utilities, see screenshot below)
2. In the debug console of Craft CMS, you will see that 145 events from SEOmatic are thrown on each admin panel page, which indicates that with each request in the CMS, a number of completely unnecessary operations are performed, which slows down the CMS.

Expected behaviour

SEOmatic initializes only the absolutely necessary (e.g. basic information about the plugin), but everything else is done by lazy-loading and only in pages/functionalities where it is really needed.

Screenshots

Versions

• Plugin version: 4.0.27
• Craft version: 4.4.14

[khalwat]

I would not classify this as a bug, but rather as a performance optimization.

The number of events thrown isn't particularly relevant, what matters is any overhead added in terms of total request time.

Do you have any timings with regard to that? I'm happy to look into any optimizations that can be done, but SEOmatic does need to initialize itself for any entry pages. A possible optimization could be that if the sidebar is turned off, it doesn't do anything, but we'd need to be very careful to ensure there are no regressions in doing so.

I'm happy to go down this route, assuming there is actual performance overhead that is problematic. The events you're mostly showing as listed as events that are thrown by an Model in the CMS.

[khalwat]

Also, I should note that SEOmatic does implement a two-layer caching system, wherein it caches the meta containers for a particular request, as well as the parsed result of the meta containers.

[janreges]

Hi @khalwat - thank you for your response :)

On my idle Ryzen 5950x (which is 2-4x faster than average server CPU in single-core performance with average busy load) difference between enabled and disabled SEOmatic plugin on page like "PHP Info" in CMS, is 14 ms and executes 5 DB queries less (see screenshots below). On an average server, this load will mean an extra 28 - 56 ms.

It may seem small to you, but if I imagine that this overhead is reflected in all requests within the CMS, or, for example, when generating a preview of the page content, I am horrified.

Before switching to Craft CMS, in our original CMS, we were used to generating pages on the frontend completely in the order of tens of milliseconds, more complex parts in the order of lower hundreds of ms. Our CMS also used a robust framework (Nette), templating engine (Latte) and ORM (based on Nette Database). Everything is 5-10x slower in Craft CMS, and we and our clients are understandably not happy about it. We are therefore looking for ways to improve it. On the front-end side, fortunately, we can benefit from Blitz or proxy-cache on Nginx, but also movement in the CMS or front-end requests, which must be handled by PHP due to dynamics, must be reasonably fast.

Andrew, thank you very much for understanding and possible implementation of any improvement that can reduce the load for requests where SEOmatic is not directly used.

SEOmatic enabled

SEOMatic disabled

[khalwat]

14ms with SEOmatic enabled sounds what I'd call acceptable, given what it does. It sounds like you have a larger issue with how Craft CMS is architected, coming from a custom framework like Nette.

That said, this change 43565e6 in SEOmatic 4.0.29 & 3.5.58 fixes an oversight in the way SEOmatic was caching the MetaJsonLdContainer. This change will result in:

• Significantly lower overhead for cache hits, because the rendered metadata is now being properly cached
• Smaller cache sizes, due to only the rendered data being cached, not the entire array of MetaJsonLd objects

So this should improve cache hit times a bit.