The get subscribed events function should not contain that much logic when possible. It would be better to get rid of the whole system plugin at all.

To explain why @laoneo is correct - this has next has no peformance impact in the frontend because we are still loading the plugin and acl checking it before we boot it to get the plugin events. Where the check happens in the context of that is relatively small scale. If this is only intended for the backend a dedicated plugin group is better (for extension devs too to save the same stuff that is loaded inside of AdministratorApplication. As I suggested in the original PR

To explain why @laoneo is correct - this has next has no peformance impact in the frontend because we are still loading the plugin and acl checking it before we boot it to get the plugin events. Where the check happens in the context of that is relatively small scale. If this is only intended for the backend a dedicated plugin group is better (for extension devs too to save the same stuff that is loaded inside of AdministratorApplication. As I suggested in the original PR

You also suggested in the original PR that if we do that, we take away the possibility to bring guided tours to the frontend in future developments. That's an option we should not close either.

You also suggested in the original PR that if we do that, we take away the possibility to bring guided tours to the frontend in future developments. That's an option we should not close either.

If that's the plan then I'd leave the code as it is. Although nothing stops you adding it to SiteApplication as well in the future. The most important thing will be that you validate that your in an html application IF that is the plan. But I've also not seen anything documented that that is the plan (and for 3PD's implementing this - that's a very relevant fact for their 3rd party plugins - which will also be system plugins???)

A lot of this has been raised because you've introduced a system plugin (which will impact to a degree site load times) which currently only loads in the admin client. So you're impacting google load times for something currently exclusive to the admin.

To be honest, I understand your points but I have no idea how I would implement this. This is completely unfamiliar to me.

I made another approach in #40046 where the template itself is loading it as I have believe that the template must somehow support that feature.

This should do the trick without fancy hacks.
The plugin:

protected $autoloadLanguage = false;
protected static $enabled = false;

public function __construct($subject, $config = [], $enabled = false)
{
    $this->autoloadLanguage = $enabled;
    self::$enabled = $enabled;

    parent::__construct($subject, $config);
}

public static function getSubscribedEvents(): array
{
    return self::$enabled ? [
        'onAjaxGuidedtours'   => 'startTour',
        'onBeforeCompileHead' => 'onBeforeCompileHead',
    ] : [];
}

The plugin provider:

$app    = Factory::getApplication();
$plugin = new GuidedTours(
    $dispatcher,
    (array) PluginHelper::getPlugin('system', 'guidedtours'),
    $app->isClient('administrator')
);

What @wilsonge and me are trying to explain here, is that the whole approach is not right. There should be no system plugin at all which is loaded on every page request. This is what should be avoided, not only registering events, loading the whole plugin. That's why I made #40046. This change here has little to no effect, loading the plugin is what counts here.

I have tested this item ✅ successfully on 697cc72

I have tested this item ✅ successfully on 697cc72

Downloaded prebuilt and was able to successfully run tour

RTC

I'm sorry I missed the updates here but what is merged here is wrong. You can't have the constructor for a non-static method influencing the behaviour of a static method. That's totally wrong.