WordPress.org

Making WordPress.org

Opened 5 months ago

Last modified 5 months ago

#5731 new enhancement

Add performance index to each theme and plugin in the repository

Reported by: oglekler Owned by:
Milestone: Priority: normal
Component: General Keywords:
Cc:

Description

To add a performance index to each theme and plugin in the repository is a big thing, but this will make authors think about performance, how many queries to a database they are making and how difficult their code is to execute and users of this theme or plugin can have a better understanding if usage of it worth at all.

I think it's something that the Tide Team can do for the greater good.

When an e-shop with one purchase in a couple of days has a heavy premium theme and a mountain of plugins, many of which can be disabled easily, and using costly hosting just for all this to run, it is a bit ridiculous. Hopefully, by having good examples at hand such site owners will start asking high-performance from authors to whom they are paying and we will raise standards and save more energy for purposes of fighting global warming as a side effect.

Change History (4)

#1 @jonoaldersonwp
5 months ago

Nice! However... many performance bottlenecks are increasingly front-end, not back-end. Slow database queries can pale into insignificance when compared to poorly constructed CSS, improperly loaded images, and similar.

As such, I suggest we also consider running Lighthouse via command line (see https://developers.google.com/web/tools/lighthouse) against a stable/known setup (e.g., a homepage request, with no other active themes/plugins).

#2 @derekherman
5 months ago

@jonoaldersonwp Tide already does a Lighthouse (LH) audit for themes. Doing it for plugins is a challenge as there is no way to know what a plugin does or where you can audit the visuals of it on the front-end. Also, there's still a need to convert the LH audit into a smaller performance payload as the size of the JSON for LH can be very large. All that to say Tide can support automating the actual reporting, but would still need to work out what to report on and how to gather that payload.

#3 @jonoaldersonwp
5 months ago

Understood, but I think as a basic approach we could make a considerable impact just by catching plugins which enqueue resources on the homepage (and therefore, likely globally). This is a common enough issue that'd make a marked impact on the overall performance of the web if we just managed to prevent plugins from globally enqueuing JS/CSS which might only be used in specific contexts/templates/etc.

We don't need the whole audit, we just need the CWV metrics.

#4 @oglekler
5 months ago

It looks like we need to collect data from real users sites and for this, we need a plugin or some other tool providing information to the repo.

Jeff Paul suggested that it looks like a Site Health related, so here is the ticket in addition:
https://core.trac.wordpress.org/ticket/53186

Note: See TracTickets for help on using tickets.