Performance: back-end

[tellyworth]

What back-end performance issues, current or potential, do we need to consider improving?

Server response time is the top issue raised by Lighthouse when running locally. Obviously that's affected by Docker speed. Are there any server-side issues in staging or likely in prod?

• Resize images
• Consider using webp (maybe? can Proton help with this?)
• Check wpdb query count
• Check object caching

[dd32]

Consider using webp

WordPress trunk has webp support

See #42

Check wpdb query count

This seems good, except for some stemming from Jetpack_PostImages. (Removing this query isn't super critical)

I believe that's why this filter ended up in all of the Page Templates: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/themes/pub/wporg-main/page-download.php?marks=64-67#L63

There's some duplicate queries from Rosetta_Sites but they already exist on the current site, and is unrelated to the initial en_US release.

Check object caching

This seems fine too.

[tellyworth]

What about CDN use for images and other assets? I mention it here because the solution might be some back-end filtering of URLs. Or Photon.

[tellyworth]

wporg-main and various other themes use a script_src() function that filters enqueued scripts and stylesheets to point them at the CDN. We could do that.

How do you think we should handle media files?

[tellyworth]

Oh, I see Dion is way ahead of me: WordPress/wporg-mu-plugins#173

[dd32]

How do you think we should handle media files?

Handling media files probably needs some work to make work well. To CDN them we'd need to have the site its' for in the URL path.

Ideally, we'd probably rewrite media urls to a specific cdn domain, something like:
https://u.w.org/example.wordpress.org/2022/08/example.jpg (ie. https://u.w.org/{Site}/{path}).

The other option, would be something like.. https://s.w.org/wp-content/blogs.dir/{SiteID}/{path} which would require minimal systems help, although have uglier URLs..

[tellyworth]

Let's do two things, one now and one later.

An immediate solution for launch

Commit and deploy image assets
Manually edit the content (and styles?) to point at CDN versions of those.

A sustainable ongoing solution

• Get a decision from Systems about CDN urls, rewriting or whatever
• Test and deploy a plugin that transparently CDN-izes all media URLs.

Does that sound reasonable? Any better immediate solutions?

[dd32]

Commit and deploy image assets

Due to how WordPress handles srcset, which we've currently got on the background images, as part of committing the image assets we'd loose that functionality. These minimal assets will be cached heavily by the load balancers I expect, so we might not need to move these to the CDN as a matter of urgency (although it would help with performance)

[tellyworth]

Got it. Ok, in that case let's forget about the sooner part and make a plan for the ongoing solution.

[tellyworth]

On DB queries: I noticed on the staging site that some pageviews have Cavalcade queries. Is that specific to the staging site or would it happen on the live site too? Can/should we bypass that on front page views?

[dd32]

I noticed on the staging site that some pageviews have Cavalcade queries.

This is a shortcoming of Cavalcade and the WP Cron system, while these queries are cached, the cache is short lived and difficult to cache for significant time without side effects.

By disabling those queries, we'd have further queries being made to insert cron entries, or, updating options. We could filter wp_next_scheduled() and return a timestamp in the future for all crons checked for the homepage, but I'm unsure if that would have a knock-on effect. We could also disable cron entirely, by returning false for next-scheduled and also for schedule-cron-plz functions.

Context: The cavalcade queries are triggered by wp_next_scheduled() which many plugins, and core itself too I believe, hook to plugins_loaded or init. Unhooking functions that check if crons are queued appropriately for certain requests would result in some performance gains (Jetpack crons primarily), but certain things such as Site Health and the Core Privacy also run upon file inclusion.

edit: Turns out on WordPress.org I added a 10s cache to these, I'd need to verify it still works correctly with core changes it appears to still work; See this upstream issue: humanmade/Cavalcade#93 (comment). You're likely seeing the queries on staging due to the low number of requests that hit it.

[ryelle]

Moving this out of the launch board, if anything still needs to be tweaked we can do that after launch.

[tellyworth]

I think this can be closed for now, though we should follow up server-side performance in depth later.