`/xb-components` takes multiple seconds when *many* SDCs are present

Huh — odd that neither @tedbow nor @bnjmnm pointed that out 😅

I do know that now we're computing + preloading a lot of information on that endpoint. Will investigate and propose a way forward.

I tested this again with xdebug and loading the endpoint takes >23s. 😅

Yep, not surprised. See #2.

@Wim Leers, if you're ever interested in automated performance testing, I have experience using PHPBench on Composer Stager. It's extremely nice. I use it to compare the performance of different design decisions, and I run it on CI to detect regressions. I can show it to you sometime, if it interests you.

Will remember that, thanks @traviscarden!

I certainly ran into hints of this in 📌 HTTP API: update /xb-component/{component_id} to list possible prop sources for current entity context Fixed as I had to fix test failures related to /xb-components now completing after the layout preview.

The difference wasn't noticeable enough on my machine to have me concerned, but I suspected this endpoint would eventually get bogged down. Fortunately, AFAIK, this is very cacheable - the response content only changes if an XB-SDC is added/removed/edited, and if the cache is repopulated when SDCs change then there wouldn't even be slowness on the initial request.

#7++ :)

Ted will take this on — he noticed in his review of 🐛 The component preview should have a background: include theme's global asset libraries for component preview Needs work that this is a blocker to that.

See https://git.drupalcode.org/project/experience_builder/-/merge_requests/2....

From the summary:

Now with the changes it takes >5s to get a response.

I am not see this performance at all in 0.x

1. on a fresh install of Drupal I am consistently seeing ~350 ms for /xb-components in Chrome inspector when I first load xb/node/1
2. When I reload xb/node/1 I then get ~300 ms
3. If I log another user into the site using an anonymous browser session I then see ~300 ms
4. If reload xb/node/1 I will even sometimes get as low as ~270ms

Has maybe something changed in 0.x that has made this faster since 📌 HTTP API: update /xb-component/{component_id} to list possible prop sources for current entity context Fixed ?

What exactly is the UI lag effect I should be looking to improve? That's why I added Needs issue summary update presumably that should be the most important thing, correct?

could it be because I am using 10.3.x and others are using 11.x? Will try that next

Ok talked to @wim leers and apparently I need to use the theme in https://www.drupal.org/project/demo_design_system → to have enough components to see the performance issues. working on that now

Updated issue summary per how I always interpreted @bnjmnm ran into this issue — I indeed also cannot reproduce it with "only" XB.

I did install the Demo Design System.

The first request is about ~4 secs about the ones after that even for another user are around <90ms!

I think this is good enough to get in and then we can look at ways to make sure the cache is warm.

Assigning to @wim leers but @bnjmnm or others could review it otherwise

OMG! So much faster 😍

This looks great to me, the cache tag is correct as per ConfigEntityType so the cache will be invalidated if any of the component config entities are updated:

core/lib/Drupal/Core/Config/Entity/ConfigEntityType.php
66:      $this->list_cache_tags = ['config:' . $definition['id'] . '_list'];

@kristen pol thanks for testing!

@longwave thanks for reviewing!

There's 2 failures in the E2E tests:

1. one is known: 🐛 `components-slots.cy.js ` is sometimes failing Active
2. The other (xb-general.cy.js) is not a known failure, but I can get it to pass reliably locally.

There appear to be significant GitLab CI Runner issues on d.o today, because there's lots of nonsensical failures across the board for today's only 0.x commit: https://git.drupalcode.org/project/experience_builder/-/commit/e6af2f761...

So going ahead and merging.

After merging, CI is green: https://git.drupalcode.org/project/experience_builder/-/commit/94014b2ff... 👍

That confirms the problem was d.o's GitLab CI runner.