Remove isFront from system_js_settings_alter()

@dawehner pointed out that #2527846: Try to get rid of Url::fromRoute() in system_js_settings_alter() → looks like it has resolved these issues. Should this one be closed?

I think if possible it would be good to try to understand whether we really need all of these, would mean grepping contrib js.

  $path_settings = [
    'baseUrl' => $request->getBaseUrl() . '/',
    'pathPrefix' => $pathPrefix,
    'currentPath' => $current_path,
    'currentPathIsAdmin' => $current_path_is_admin,
    'isFront' => \Drupal::service('path.matcher')->isFrontPage(),
    'currentLanguage' => \Drupal::languageManager()-                            >getCurrentLanguage(LanguageInterface::TYPE_URL)->getId(),
  ];

• baseUrl: >100 occurrences
• pathPrefix: ~30 occurrences
• currentPath: ~30 occurrences
• currentPathIsAdmin: 13 occurrences
• isFront: 9 occurrences
• currentLanguage: ~20 occcurrences

Not sure which conclusions to draw from this.

baseUrl has pretty much zero perf overhead and is used the most. The rest cost some performance, but also have some use. I suspect isFront is the most expensive and also has the lowest use. If that does represent the bulk of the performance cost, I'd vote to remove only that.

Yeah isFront is the most suspicious for me too, although to really benefit we'll probably need to take it out of some preprocess too.

I think we should remove the isFront here, we can't deprecate it - would it have to be an 11.x only change with a change record?

I think so?

How do we warn/inform sites on 10.x if deprecation is impossible?

isFront only has 3 or so real usages, the others are false positives. For those 3 contrib projects we could just open an issue there. Doesn't deal with custom so, but yeah, all we can do is a change record. There might be a way to detect it, but it's JS, which we don't really support yet in our tools I think?

That said, the performance data here is very old and I'm wondering if removing this won't just move the cost somewhere else as it's likely the first call to that function that is expensive? So we should definitely evaluate if this is a) actually still relevant and b) that removing it won't just make that cost pop up somewhere else, before we spend time on deprecations and so on.

Hmm ideally we'd have #3070521: Trigger deprecation notifications on JavaScript deprecations to notify developers that deprecated code is being used → but for Drupal settings.

@Berdir we'd immediately see it again in template_preprocess_page() and template_preprocess_html(), but I also want to remove the is_front handling from that or do 📌 Replace template_preprocess() and possibly other things with Twig global variables/functions Active so that it's only calculated when it's actually requested.

So yeah we'd need to remove it from at least those three places to see any improvement but I think those are the only places that absolutely 100% require it on every HTML response from Drupal.

More detail on #24.

There's two things we have to get to know if we're on the front page - the current route match, which we can't avoid doing elsewhere, so we won't save anything there.

The other bit is (from PathMatcher):

   if (!isset($this->frontPage)) {
      $this->frontPage = $this->configFactory->get('system.site')
        ->get('page.front');
    }

system.site is also used in the branding block - but that block is cacheable so it won't be getting that config every request. I don't think it's used anywhere else on every-page building by default.

So what we'd actually save is loading the system.site config and a few function calls.