Make WordPress Core

Opened 10 months ago

Closed 9 months ago

Last modified 9 months ago

#59465 closed task (blessed) (fixed)

Twenty Twenty-Four performance assessment and opportunities

Reported by: flixos90's profile flixos90 Owned by: flixos90's profile flixos90
Milestone: 6.4 Priority: normal
Severity: normal Version: 6.4
Component: Bundled Theme Keywords:
Focuses: performance Cc:

Description (last modified by flixos90)

With Twenty Twenty-Four being the new default theme starting with WordPress 6.4, this ticket is focused on assessing the performance of the theme and to identify potential performance improvements that can be made.

As a starting point, I conducted several benchmarks comparing performance of TT4 with TT3, which makes sense as a reference point since it is the current/previous default theme and is also a block theme.

Two URLs were tested in these benchmarks:

  • The home page with default content: Note that TT4 provides a lot more, and richer content than TT3, so it is expected that TT4 will load slightly slower - simply because more content / more features mean higher cost.
  • The singular view of the default "Hello world!" post, with a featured image added as the only change: This should be a more "fair" comparison given the content of those URLs is less different between TT4 and TT3.

Two sets of benchmarks were conducted:

  • One focused on overall Web Vitals (via `benchmark-web-vitals`): This provides a holistic performance overview considering both server-side (TTFB) and client-side (LCP-TTFB).
  • One focused on only Server-Timing (via `benchmark-server-timing`, also see this docs article): This provides an overview on server-side load time performance only, however those metrics are more stable and trustworthy than the TTFB from above, due to less variance.

Here's a summary of the data:

  • For the home page:
    • Overall load time (LCP) is 58.8% slower. 🔴
    • Client-side performance (LCP-TTFB) is 93.5% slower. 🔴
    • Server-Timing (wp-total) is 71.8% slower. 🔴
  • For the singular post:
    • Overall load time (LCP) is 3.9% slower. 🔴
    • Client-side performance (LCP-TTFB) is 40.1% faster. 🟢
    • Server-Timing (wp-total) is 42.3% slower. 🔴

Here is the spreadsheet with the full benchmark data.

Again, let's not over interpret the home page metrics. They are only that much slower because TT4 provides a lot more feature rich content out of the box than TT3. However, given the huge difference, and given that for the singular post it is also slightly slower, we should take a closer look at opportunities for improving the performance of TT4.

Lighthouse reports for the TT4 home page and the TT4 singular post flagged primarily the following issues:

  • Images aren't properly sized and are missing width and height attributes (which effectively is a result of the same problem, see the already opened ticket #59464)
  • 4 render-blocking stylesheets are being flagged:
    • 1 from the core/navigation block
    • 1 from the core/image block
    • 1 from the TT4 theme itself (button-outline.css)
    • 1 from the block library (common.min.css)

Interestingly, the server-side performance difference between TT4 and TT3 seems to come almost exclusively from the number of block editor features used by the theme, but not by any problems from the theme itself. In fact, the theme only includes a single function of PHP logic. It does however include more complex content than TT3 and comes with a large number of patterns, so potentially that plays a role there. We should profile further which concrete parts of TT4's usage of core features lead to the server-side slowdown.

I am hopeful that between the TT4 team and the Core Performance Team we can collaborate on identifying any further opportunities and implementing fixes to improve performance by the time TT4 fully launches with 6.4 stable.

This ticket serves simply for an overview and for higher level discussion on the performance of TT4. More specific tickets for individual issues are:

Attachments (1)

Screenshot 2023-09-26 at 17.57.55.png (426.0 KB) - added by spacedmonkey 10 months ago.

Download all attachments as: .zip

Change History (29)

#1 @flixos90
10 months ago

Pinging @joemcgill @spacedmonkey @luminuu @onemaggie for visibility.

I have self-assigned this for now, however feel free to reassign if you intend to own this effort.

I am dedicated to investigating performance opportunities here further, however I will be on vacation between September 27-October 4, so just a heads up that I'll only be able to continue once I'm back. :)

#2 follow-up: @westonruter
10 months ago

@flixos90 I noticed in the doc that WP_DEBUG was disabled when running the benchmarks, but what about SCRIPT_DEBUG? I presume so since that is included in the docs, but just wanted to be sure.

#3 @flixos90
10 months ago

See #59466 and https://github.com/WordPress/wordpress-develop/pull/5321 for a fix regarding the render-blocking button-outline.css file.

#4 in reply to: ↑ 2 @flixos90
10 months ago

Replying to westonruter:

@flixos90 I noticed in the doc that WP_DEBUG was disabled when running the benchmarks, but what about SCRIPT_DEBUG? I presume so since that is included in the docs, but just wanted to be sure.

Correct, SCRIPT_DEBUG was false as well for all the benchmarks.

#5 @luminuu
10 months ago

Thank you for looking into this. Shall updates to the theme be done here in Trac or better in our Github repo for the theme? Ping @desrosj

#6 follow-up: @onemaggie
10 months ago

I'd rather centralize development on GH until the RC when we will close that repo, let's not make it more confusing for contributors

#7 @onemaggie
10 months ago

I think the benchmark data is very interesting. The two themes we are comparing don't play in the same league. TT3 was streamlined and made to be extended, while TT4 is full-featured and tries to make extensive use of the site editor tools. This doesn't mean that the data extracted is not valid. In fact, it definitely shows us what an actual use case versus a base theme looks like. As you mentioned, TT4 is not adding any features in itself; it's merely using patterns and adding a few block styles, so anything we find here to fix is liable to benefit every single block theme that's out there, not just TT4, which I think it's fantastic.

This ticket was mentioned in Slack in #core-performance by joemcgill. View the logs.


10 months ago

#9 @spacedmonkey
10 months ago

After doing some profiling, I noticed that there is larger number of calls to file_get_contents. This is becuase in _register_theme_block_patterns, this calls get_file_data then file_get_contents. Unlike other core themes, this new theme register many block patterns. When a block pattern is registered, it is loading into memory to read the file headers. Loading 50+ php files into memory is slow and make this theme slower than normal.

I think we should consider, either adding some caching _register_theme_block_patterns or performance tweak or remove the patterns from the theme.

I strongly believe that we should be pushing out the door a new core theme that is a lot slower than the last core theme.

It is worth noting that I noted similar performance issue with the popular block theme frost. Profile data.

#10 @priethor
10 months ago

@spacedmonkey, could you provide the relative numbers in milliseconds and percentage-based compared to the last default theme? Do you know the absolute numbers when loading TT4 apart from those specific DB queries?

I'm trying to understand how significant the impact is for users, as the TT3 experience was so performant that TT4 being somewhat slower might not be perceivable by the user.

#11 @spacedmonkey
10 months ago

@priethor Here is the comparing profile. It is 50% slower.

Version 0, edited 10 months ago by spacedmonkey (next)

This ticket was mentioned in Slack in #core-themes by onemaggie. View the logs.


10 months ago

#13 @priethor
10 months ago

Thanks a lot, Jonny!

My two cents is that although the changes are noticeable, the patterns themselves are a key feature of TT4 and most block themes, and removing them would be detrimental. I personally wouldn't consider it a blocker, but an excellent flag to look at ways to optimize pattern loading.

#14 in reply to: ↑ 6 @desrosj
10 months ago

Replying to onemaggie:

I'd rather centralize development on GH until the RC when we will close that repo, let's not make it more confusing for contributors

Yes, I think changes should flow through GitHub until final release. It's fine to have tickets in Trac, we'll just want to mention them in commits where the code from GitHub is being merged.

#15 @desrosj
10 months ago

  • Keywords needs-patch added
  • Version set to trunk

#16 @flixos90
10 months ago

I completely agree with @priethor that we shouldn't remove patterns from a theme. That would remove key features of the theme in favor of performance, and doesn't solve the problem at all.

However, as @spacedmonkey said, the performance here is a lot worse than in TT3 (partly >70% worse as seen in the ticket description), so we need to prioritize a solution for that.

The problem needs to be tackled in Core/Gutenberg: Uncashed file lookups for all the patterns on every page load is a huge performance burden, and as @onemaggie mentioned above, fixing that would benefit performance of all other block themes as well.

So, just to clarify, there is nothing wrong with TT4 in that regard. It just uncovered a severe core problem, that we should prioritize, given we don't want to ship a slow default theme.

Last edited 10 months ago by flixos90 (previous) (diff)

#17 @spacedmonkey
10 months ago

As this issue is not related to TT4, but all themes with lots of patterns, I think we should create a ticket for performance issues with _register_theme_block_patterns.

I have put together a little PR of POC for, caching patterns a transient. That has some promising results.

#18 @spacedmonkey
10 months ago

Create a new issue for performance issues with _register_theme_block_patterns #59490.

This ticket was mentioned in Slack in #core-performance by dmsnell. View the logs.


10 months ago

#20 @dmsnell
10 months ago

Based on some testing I ran today, I see evidence suggesting that cutting down on the number of patterns rendered on the home page would remove some of the added delay. That is, for single pages with fewer patterns the added delay isn't as bad. This is another way of saying that twentytwentyfour is slower than twentytwentythree on the home page because it's rendering more, and rendering more slow things.

#21 follow-up: @flixos90
10 months ago

  • Description modified (diff)

Thank you for the additional input @dmsnell!

A mentioned earlier, I think the root problem with the server-side performance lies in core itself, and is now being further explored via #59490. Regarding TT4 itself, there may be room for a bit of optimization, but IMO it wouldn't tackle the problem at its root. That said, there are a few instances where I would question the use of patterns to be excessive, for example:

Couldn't all those 6 patterns simply be referenced in the root templates/home.html file? Why the 2 additional "patterns" in between, which don't really add anything AFAIK? Curious if you can share come context on that @onemaggie @luminuu.

I've added links to the 3 more specific tickets related to the performance issues to the description.

#22 in reply to: ↑ 21 @onemaggie
10 months ago

Replying to flixos90:

Thank you for the additional input @dmsnell!

A mentioned earlier, I think the root problem with the server-side performance lies in core itself, and is now being further explored via #59490. Regarding TT4 itself, there may be room for a bit of optimization, but IMO it wouldn't tackle the problem at its root. That said, there are a few instances where I would question the use of patterns to be excessive, for example:

Couldn't all those 6 patterns simply be referenced in the root templates/home.html file? Why the 2 additional "patterns" in between, which don't really add anything AFAIK? Curious if you can share come context on that @onemaggie @luminuu.

I've added links to the 3 more specific tickets related to the performance issues to the description.

The way it works is:

  • page-01-business-home.php has the content between the header and the footer, and makes it available as a full page pattern to be used in any page on the page creation flow (you will get a popup that shows you the theme patterns that are tagged as "page" patterns with the post-content block type
  • template-home-business.php is the full page with header and footer, and it needs to exist as a pattern so that it's available on the template creation/swapping flow. As of now, only patterns show in this flow, not existing templates. If we remove it, the user will not be able to go back to the original template using this flow (they would have to find the "clear customizations" option to do so)
  • home.html is what you would expect and uses the previous pattern

The only one we could lose is template-home-business.php but I would rather address this were a last resort because it's a worse user experience

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


10 months ago

#24 @flixos90
10 months ago

Posting an update here since I just ran another set of benchmarks with 6.4 Beta 2 and the latest version of TT4. I benchmarked against the regular WP build from the ZIP file on a local install powered by Local, to avoid any influence by the WP core dev environment. Summary:

  • With Beta 2, TT4 loads in 166.02ms, compared to 179.82ms in Beta 1, i.e. 7.67% faster.
  • For reference, TT3 in that setup loads in 99.89ms. While therefore TT4 appears to load 60% slower than TT3 and at a first glance that may still sound alarming, this is really comparing apples with oranges. TT4 provides a much richer feature set and layout, so a higher cost is expected.

See full results

Let's continue exploring ways to further improve performance of more complex block themes (e.g. things like #59544), but all that is to say I think we are working in the right direction. An almost 8% win between Beta 1 and Beta 2 is massive!

Last edited 10 months ago by flixos90 (previous) (diff)

#25 @flixos90
10 months ago

Sharing here https://core.trac.wordpress.org/ticket/59383#comment:31 for visibility. I'm not 100% sure this is true yet, but if it is accurate, there is a massive opportunity to improve TT4 there with an existing PR. Curious to get clarification on that ticket/PR.

#26 @joemcgill
9 months ago

  • Keywords needs-patch removed

Given that this is just a tracking ticket for ongoing performance analysis of the new Twenty Twenty-four theme. Any new issues discovered will be handled in separate tickets, no patch is needed to resolve this issue. We'll close it at the end of this release cycle.

#27 @flixos90
9 months ago

  • Description modified (diff)
  • Resolution set to fixed
  • Status changed from assigned to closed

I am very excited to report that most (if not all) of the server-side performance concerns have been addressed, via additional general performance fixes that landed in core since, most importantly [56765], [56805], and [56807]! 🎉

Here are new Server-Timing benchmarks comparing TT4 and TT3 with latest core trunk:

  • TT4 home page loads in 85.91ms, compared to 78.08ms in TT3.
    • 10.0% slower, but before was 71.8% slower 🎉
  • TT4 "Hello world!" post loads in 96.44ms, compared to 86.35ms in TT3.
    • 11.7% slower, but before was 42.3% slower 🎉

Given how much richer the content and layout of TT4 is compared to TT3, this is a major accomplishment, and there is no need to worry about the remaining performance difference due to that.

I think it is safe to say that this completes the crucial server-side performance enhancements related to TT4. For the client-side performance enhancements, the related #59464 and #59577 are still outstanding, but they require more thought and time investment and therefore have been milestoned for the 6.5 release. As such, I am going to close this ticket as completed. Please follow along on the two tickets mentioned for remaining related work.

This ticket was mentioned in Slack in #core by flixos90. View the logs.


9 months ago

Note: See TracTickets for help on using tickets.