search

WordPress / performance

Performance plugin from the WordPress Performance Group, which is a collection of standalone performance modules.
https://wordpress.org/plugins/performance-lab/
GNU General Public License v2.0
365 stars 100 forks source link

Review current plugin names and their descriptions for their accuracy and helpfulness #1046

Closed felixarntz closed 7 months ago

felixarntz commented 8 months ago

See https://github.com/WordPress/performance/issues/1031#issuecomment-1989043559: We should revisit our current standalone plugins' names and descriptions for how accurate and useful they are. In particular, we should consider the following:

For reference, here are our current plugin names and descriptions to review:

Let's brainstorm.

cc @adamsilverstein @joemcgill @mukeshpanchal27 @swissspidy @westonruter

westonruter commented 8 months ago

Example: "WebP Uploads" would probably be better as something like "WebP Images" (the term "Uploads" is only used because of Media Library jargon).

Further, we discussed ideally not including WebP here either, so it would be rather "Modern Images".

  • Our plugins are not products. They are features for WordPress core. As such, we should avoid plugin names that sound too much like a product / brand name, and instead simply find a good name that clarifies the feature. Example: "Optimization Detective" doesn't clarify what it does.

To be fair, to myself, I did do quite a bit of outreach including a survey to come up with this name. Naming things is hard. Ultimately, if the feature is intended to get merged into WordPress core, the name shouldn't matter so much. (No cool name is needed for branding.) On the opposite extreme of slick branding the plugins could be named with random words, like "Apple Rain Hammer", as Glitch does. That goes too far as the names need to have association with the feature.

What matters is having a unique and concise project name that collaborators can refer to, while also having a name that end-users will be able to associate with the functionality (hopefully understood from the name itself). But perhaps this cannot be achieved in a single name. Indeed, Jetpack does not. It has multiple ways to refer to the same functionality: the name, short description (i.e tagline), and the long description. The name is short and easy to remember, and the tagline reminds the user of what it does. I think that's what we should follow as well. The names can err on the side of being generic, e.g. "Modern Images", and the descriptions can further clarify and evolve as aspects come and go while being merged into core.

Aside: I found that Jetpack CRM's plugin slug is zero-bs-crm. So we shouldn't feel shy about the slug being one thing but the name being something else (e.g. renaming WebP Uploads to Modern Images but leaving the slug webp-uploads).

Jetpack Feature Data

slug plugin_slug plugin_names name title description long_description
anti-spam akismet akismet/akismet.php Akismet Anti-spam Jetpack Akismet Anti-spam Stop comment and form spam Save time and get better responses by automatically blocking spam from your comments and forms.
backup jetpack-backup jetpack-backup/jetpack-backup.php, backup/jetpack-backup.php, jetpack-backup-dev/jetpack-backup.php VaultPress Backup Jetpack VaultPress Backup Save every change Never lose a word, image, page, or time worrying about your site with automated backups & one-click restores.
boost jetpack-boost jetpack-boost/jetpack-boost.php, boost/jetpack-boost.php, jetpack-boost-dev/jetpack-boost.php Boost Jetpack Boost Speed up your site in seconds Jetpack Boost gives your site the same performance advantages as the world’s leading websites, no developer required.
creator jetpack jetpack/jetpack.php, jetpack-dev/jetpack.php Creator Jetpack Creator Create, grow, and monetize your audience Create, grow, and monetize your audience with powerful tools for creators.
crm zero-bs-crm zero-bs-crm/ZeroBSCRM.php, crm/ZeroBSCRM.php CRM Jetpack CRM Nurture your contacts to grow your business All of your contacts in one place. Build better relationships with your customers and clients.
extras jetpack Extras Jetpack Extras Basic tools for a successful site Secure and speed up your site for free with Jetpack's powerful WordPress tools.
jetpack-ai jetpack jetpack/jetpack.php, jetpack-dev/jetpack.php AI Jetpack AI Experimental tool to add AI to your editor Jetpack AI Assistant brings the power of AI right into your WordPress editor, letting your content creation soar to new heights.
protect jetpack-protect jetpack-protect/jetpack-protect.php, protect/jetpack-protect.php, jetpack-protect-dev/jetpack-protect.php Protect Jetpack Protect Powerful, automated site security Protect your site and scan for security vulnerabilities listed in our database.
scan jetpack jetpack/jetpack.php, jetpack-dev/jetpack.php Scan Jetpack Scan Powerful, automated site security Automatic scanning and one-click fixes keep your site one step ahead of security threats and malware.
search jetpack-search jetpack-search/jetpack-search.php, search/jetpack-search.php, jetpack-search-dev/jetpack-search.php Search Jetpack Search Custom instant site search Help your site visitors find answers instantly so they keep reading and buying. Great for sites with a lot of content.
security jetpack jetpack/jetpack.php, jetpack-dev/jetpack.php Security Jetpack Security Comprehensive site security, including VaultPress Backup, Scan, and Akismet Anti-spam. Comprehensive site security, including VaultPress Backup, Scan, and Akismet Anti-spam.
social jetpack-social jetpack-social/jetpack-social.php, social/jetpack-social.php, jetpack-social-dev/jetpack-social.php Social Jetpack Social Auto-publish to social media Promote your content on social media by automatically publishing when you publish on your site.
starter jetpack jetpack/jetpack.php, jetpack-dev/jetpack.php Starter Jetpack Starter Essential security tools: real-time backups and comment spam protection. Essential security tools: real-time backups and comment spam protection.
stats jetpack jetpack/jetpack.php, jetpack-dev/jetpack.php Stats Jetpack Stats Simple, yet powerful analytics With Jetpack Stats, you don’t need to be a data scientist to see how your site is performing.
videopress jetpack-videopress jetpack-videopress/jetpack-videopress.php, videopress/jetpack-videopress.php, jetpack-videopress-dev/jetpack-videopress.php VideoPress Jetpack VideoPress High quality, ad-free video High-quality, ad-free video built specifically for WordPress.
Raw JSON ```json [ { "slug": "anti-spam", "plugin_slug": "akismet", "plugin_names": [ "akismet/akismet.php" ], "name": "Akismet Anti-spam", "title": "Jetpack Akismet Anti-spam", "description": "Stop comment and form spam", "long_description": "Save time and get better responses by automatically blocking spam from your comments and forms." }, { "slug": "backup", "plugin_slug": "jetpack-backup", "plugin_names": [ "jetpack-backup/jetpack-backup.php", "backup/jetpack-backup.php", "jetpack-backup-dev/jetpack-backup.php" ], "name": "VaultPress Backup", "title": "Jetpack VaultPress Backup", "description": "Save every change", "long_description": "Never lose a word, image, page, or time worrying about your site with automated backups & one-click restores." }, { "slug": "boost", "plugin_slug": "jetpack-boost", "plugin_names": [ "jetpack-boost/jetpack-boost.php", "boost/jetpack-boost.php", "jetpack-boost-dev/jetpack-boost.php" ], "name": "Boost", "title": "Jetpack Boost", "description": "Speed up your site in seconds", "long_description": "Jetpack Boost gives your site the same performance advantages as the world\u2019s leading websites, no developer required." }, { "slug": "creator", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Creator", "title": "Jetpack Creator", "description": "Create, grow, and monetize your audience", "long_description": "Create, grow, and monetize your audience with powerful tools for creators." }, { "slug": "crm", "plugin_slug": "zero-bs-crm", "plugin_names": [ "zero-bs-crm/ZeroBSCRM.php", "crm/ZeroBSCRM.php" ], "name": "CRM", "title": "Jetpack CRM", "description": "Nurture your contacts to grow your business", "long_description": "All of your contacts in one place. Build better relationships with your customers and clients." }, { "slug": "extras", "plugin_slug": "jetpack", "plugin_names": [], "name": "Extras", "title": "Jetpack Extras", "description": "Basic tools for a successful site", "long_description": "Secure and speed up your site for free with Jetpack's powerful WordPress tools." }, { "slug": "jetpack-ai", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "AI", "title": "Jetpack AI", "description": "Experimental tool to add AI to your editor", "long_description": "Jetpack AI Assistant brings the power of AI right into your WordPress editor, letting your content creation soar to new heights." }, { "slug": "protect", "plugin_slug": "jetpack-protect", "plugin_names": [ "jetpack-protect/jetpack-protect.php", "protect/jetpack-protect.php", "jetpack-protect-dev/jetpack-protect.php" ], "name": "Protect", "title": "Jetpack Protect", "description": "Powerful, automated site security", "long_description": "Protect your site and scan for security vulnerabilities listed in our database." }, { "slug": "scan", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Scan", "title": "Jetpack Scan", "description": "Powerful, automated site security", "long_description": "Automatic scanning and one-click fixes keep your site one step ahead of security threats and malware." }, { "slug": "search", "plugin_slug": "jetpack-search", "plugin_names": [ "jetpack-search/jetpack-search.php", "search/jetpack-search.php", "jetpack-search-dev/jetpack-search.php" ], "name": "Search", "title": "Jetpack Search", "description": "Custom instant site search", "long_description": "Help your site visitors find answers instantly so they keep reading and buying. Great for sites with a lot of content." }, { "slug": "security", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Security", "title": "Jetpack Security", "description": "Comprehensive site security, including VaultPress Backup, Scan, and Akismet Anti-spam.", "long_description": "Comprehensive site security, including VaultPress Backup, Scan, and Akismet Anti-spam." }, { "slug": "social", "plugin_slug": "jetpack-social", "plugin_names": [ "jetpack-social/jetpack-social.php", "social/jetpack-social.php", "jetpack-social-dev/jetpack-social.php" ], "name": "Social", "title": "Jetpack Social", "description": "Auto-publish to social media", "long_description": "Promote your content on social media by automatically publishing when you publish on your site." }, { "slug": "starter", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Starter", "title": "Jetpack Starter", "description": "Essential security tools: real-time backups and comment spam protection.", "long_description": "Essential security tools: real-time backups and comment spam protection." }, { "slug": "stats", "plugin_slug": "jetpack", "plugin_names": [ "jetpack/jetpack.php", "jetpack-dev/jetpack.php" ], "name": "Stats", "title": "Jetpack Stats", "description": "Simple, yet powerful analytics", "long_description": "With Jetpack Stats, you don\u2019t need to be a data scientist to see how your site is performing." }, { "slug": "videopress", "plugin_slug": "jetpack-videopress", "plugin_names": [ "jetpack-videopress/jetpack-videopress.php", "videopress/jetpack-videopress.php", "jetpack-videopress-dev/jetpack-videopress.php" ], "name": "VideoPress", "title": "Jetpack VideoPress", "description": "High quality, ad-free video", "long_description": "High-quality, ad-free video built specifically for WordPress." } ] ```

Data scraped from the products directory.

ThierryA commented 8 months ago

Our plugins are not products. They are features for WordPress core. As such, we should avoid plugin names that sound too much like a product / brand name, and instead simply find a good name that clarifies the feature. Example: "Optimization Detective" doesn't clarify what it does.

It is not a matter of product vs not product, it is a matter of user experience (and by the way the definition of product is subject, arguably these a products). One talking point though is whether or not is should be an easily recognizable Suite of plugins, for example all prefixed with "PL" or "Performance Lab". Personally, I see only benefits for users to easily recognize that it is part of the PL Suite (Plugin name length should not be an stopper here). Product or not product, the vision, the purpose, the trust, the team etc... of the PL project is applicable throughout all plugins and for it to be part of the plugins name make a lot of sense and goes a long way. My vote goes for adding a prefix!

swissspidy commented 8 months ago

@felixarntz Is this issue for the feature names & descriptions on the PL admin screen or for the plugin repo? Because I think we should make a distinction there.

To be fair, to myself, I did do quite a bit of outreach including a survey to come up with this name. Naming things is hard. Ultimately, if the feature is intended to get merged into WordPress core, the name shouldn't matter so much.

+1 to this.

It is not a matter of product vs not product, it is a matter of user experience (and by the way the definition of product is subject, arguably these a products).

In the context of the PL admin screen I see these more as individual features to enable.

One talking point though is whether or not is should be an easily recognizable Suite of plugins, for example all prefixed with "PL" or "Performance Lab".

We could do this kind of prefixing & grouping just in wp-admin, but not on WordPress.org — would that suffice? Not sure I like adding a prefix everywhere on the plugin repo, especially with the PL admin screen being the entry point for adding new plugins anyway.

For the PL admin screen we could start with naming like this:

Feature Description
Auto-sizes for lazy-loaded Images Instruct browsers to automatically choose the right image size for lazy-loaded images.
Media Placeholders Creates good-looking placeholders based on an image's dominant color.
Optimization Detective Use actual visitor data to improve heuristics WordPress applies on the frontend to improve image loading priority.
Performant Translations Making internationalization/localization in WordPress faster than ever before.
Page Preloading Enable browsers to speculatively prerender pages when hovering over links.
Modern Image Formats Convert images to more modern formats such as WebP or AVIF during upload.

Aside:

ThierryA commented 8 months ago

We could do this kind of prefixing & grouping just in wp-admin, but not on WordPress.org — would that suffice? Not sure I like adding a prefix everywhere on the plugin repo, especially with the PL admin screen being the entry point for adding new plugins anyway.

I am advocating for prefixing plugin names (deployed to .org) to make it easily recognizable everywhere. By the way, it is a pretty common practice ;)

felixarntz commented 8 months ago

@swissspidy

Is this issue for the feature names & descriptions on the PL admin screen or for the plugin repo? Because I think we should make a distinction there.

At the moment, it's for both. After further discussion yesterday, we're thinking maintaining separate names and descriptions just for PL is a maintenance burden without a real benefit. If we think our plugin names and descriptions do not adequately describe what they do, we should change those names and descriptions rather than working around it in "duplicated" versions just for PL. At least this is a more reasonable foundation to start with. I don't see a good reason why the plugin name / description would need to differ. They just need to be improved from what they are now, at least for some of our plugins.

For the PL admin screen we could start with naming like this: [...]

Pretty much everything you have in that table sounds better to me than what we currently have for those plugins. So that supports my point above, there's no need for separately maintained feature descriptions as long as the plugins already describe the features they add. Make each description start with a third-person verb, and it'll work for both the plugin description and the feature description in PL.

I think your list is a good start to discuss the names and descriptions further. At a first glance, my only points of feedback are:

felixarntz commented 8 months ago

Regarding the prefixing, I'm not sure. Prefixing within Performance Lab makes no sense, this you're already in the Performance Lab UI. If we decide to prefix all plugins on .org, I'd rather say that we should put logic in PL that (just for the PL settings screen) removes the "Performance Lab" prefix from the plugin name. If the names are predictable as such, that would be easy to do.

So for whether to prefix or not? On the one hand, it's great for recognizability and spreading the word of the "Performance Lab" brand. On the other hand, it may not be in line with the overarching idea of making the plugins standalone. Of course they'd still be technically standalone, but I'm not sure a strong connection with the Performance Lab plugin or brand is desirable in light of the original objective.

I'm totally not sold on either, curious to hear other opinions.

westonruter commented 8 months ago

"Optimization Detective" does not at all describe what it does, other than optimizing something. The "Detective" term carries zero meaning. Something like "Optimized Image Loading", "Optimized Image Orchestration", or even the previous "Image Loading Optimization" are better names IMO as they convey more. FWIW I'm not saying those names are great, but I think they are better.

  • I acknowledge that part of the idea is to reuse this infrastructure for all kinds of other features. But let's not just look at this from a technical perspective: What this plugin does is optimize how images are loaded, anything else is a distinct feature, so I'm not even sold it should be in the same plugin. If it needs to use the infrastructure, it could still be in its own plugin - especially now that we have plugin dependencies.

I disagree. It does describe what it does. It's using the client to detect optimizations. The client is the detective. It's not limited to just images, although that's what was first implemented. I don't want to pigeonhole it to just be about images. For example, it can also be used to apply content-visibility, reserve space to improve CLS, add preconnects for embeds, or store CWV metrics as a RUM tool. Adding additional plugins for non-image aspects to me just adds overhead.

felixarntz commented 8 months ago

@westonruter But those are lots of different features. Just because they technically rely on the same infrastructure doesn't make a good reason for them to all be in the same plugin. Users that want to only test the image optimization shouldn't have to get the other features too, for instance. And if the solution is to offer toggles for the individual functionalities, we're back at Performance Lab all over again.

IMO this name and positioning is purely for technical reason and not intuitive for end users.

westonruter commented 8 months ago

I don't think it is sustainable to relegate every distinct feature to a separate plugin. We have to group some related functionalities into common plugins.

swissspidy commented 8 months ago

"Media Placeholders" should be "Image Placeholders" IMO. That's easier to understand and more precisely what it is about. Similar to how "Modern Image Formats" is not called "Modern Media Formats", for a good reason.

FWIW with this I was mainly hinting at enhancing the plugin a little bit. There's no reason this functionality shouldn't also work for video posters (which are images, but the experience is for videos), hence Media Placeholders. Whereas the Modern Image Formats is only for images obviously. Hope that makes sense.

felixarntz commented 8 months ago

@swissspidy

Whereas the Modern Image Formats is only for images obviously.

That's the part I don't get. There may be modern video formats as well. I really don't see any difference between why one plugin should use the general "Media" and the other one "Image". Both equally can apply to other formats. But at the moment they don't. So in order to adequately describe what they do, "Image" is more accurate. If the scope later expands to other media, it can still be renamed (again) - but we don't know whether that'll ever happen.

felixarntz commented 8 months ago

@westonruter

I don't think it is sustainable to relegate every distinct feature to a separate plugin. We have to group some related functionalities into common plugins.

That's speaking from an engineering perspective. I don't disagree. But it was also easier from a maintenance perspective to ship all features in Performance Lab, yet here we are. We cannot make those decisions purely from an engineering perspective. There is clearly a tradeoff between UX, DX, and what we should be doing according to project leadership, so we have to balance those points.

Grouping multiple features in one plugin is a no-go as far as previous conversations have indicated.

swissspidy commented 8 months ago

That's the part I don't get. There may be modern video formats as well.

WordPress can't do server-side video transcoding, and doing that client-side is still far away. When that becomes possible, it can be renamed to Media Formats too.

But at the moment they don't. If the scope later expands to other media

That's exactly what I am saying: we should update the dominant color plugin, hence I suggested the name. Makes sense?

felixarntz commented 8 months ago

That's exactly what I am saying: we should update the dominant color plugin, hence I suggested the name.

Is there an issue for that? FWIW that plugin hasn't seen any updates in a long time, and this is the first time I'm hearing about this. Unless, or until the plugin contains non-image functionality, IMO it shouldn't be using "media", just as you're saying for the "Modern Image Formats" plugin, it can be renamed once/if it has the functionality.

swissspidy commented 8 months ago

Is there an issue for that? FWIW that plugin hasn't seen any updates in a long time, and this is the first time I'm hearing about this.

I don't think there is. This was mostly a spontaneous idea. As per my other comment we could also just remove the plugin.

Unless, or until the plugin contains non-image functionality, IMO it shouldn't be using "media"

Again, we're saying the same thing :)

Anyway, didn't wanna derail the conversation further.

Grouping multiple features in one plugin is a no-go as far as previous conversations have indicated.

So about that Optimization Detective feature IMHO it's a matter of finding the right balance for how many features to put into a plugin vs. splitting things up.

westonruter commented 8 months ago

So about that Optimization Detective feature IMHO it's a matter of finding the right balance for how many features to put into a plugin vs. splitting things up.

For what it's worth, I see the Optimization Detective features more of a package deal and not individual things you would turn on or off. By activating the plugin, it detects opportunities based on client-side metrics to optimize the response which wouldn't be possible using server-side heuristics alone. Similar to a proposed Image Formats plugin, it could enable both WebP and AVIF, without needing to have toggles for the different image formats to enable.

felixarntz commented 8 months ago

For what it's worth, I see the Optimization Detective features more of a package deal and not individual things you would turn on or off.

Based on the features you mentioned as examples in https://github.com/WordPress/performance/issues/1046#issuecomment-1992036090, I don't see any meaningful relationship between them, except that they use the same technical foundation. Again, from a technical perspective grouping them makes sense to me, but not from a feature perspective.

By activating the plugin, it detects opportunities based on client-side metrics to optimize the response which wouldn't be possible using server-side heuristics alone.

This sounds quite complicated to understand for a non technical user. Hence, I don't think it's a good framing for the plugin, unless it is aimed at developers.

Similar to a proposed Image Formats plugin, it could enable both WebP and AVIF, without needing to have toggles for the different image formats to enable.

IMO that's a very different point on the spectrum. Both WebP and AVIF are image formats. Just as both loading="lazy" and fetchpriority="high" could be handled by the same plugin as they both optimize image loading. But the features you mentioned in https://github.com/WordPress/performance/issues/1046#issuecomment-1992036090 aren't related to each other to the same degree.

westonruter commented 8 months ago

All of the PL plugins are technical to some extent. End users who are not technical will have trouble understanding functionality in most of the plugins. PL is positioned as a beta testing plugin. But let's say Optimization Detective is split out into a plugin specifically for Image Loading Optimization. Playing this out, when wanting to experiment with content visibility or preserving space to reduce layout shift, and so on, will this mean adding additional plugins for each feature? To an end user, these are difficult to position independently as well. They are very technical. To the end user, they just want to have an optimized loading experience. They don't care about the technical specifics. How the optimization is accomplished is just an implementation detail.

So for end users, I don't see how splitting into multiple plugins will make it more end-user friendly. Conversely, as you note, breaking up these functionalities into separate plugins would be complicated from an engineering standpoint since they all depend on this same underlying foundation to work. This is different from other PL plugins which are actually independent from each other: they are truly standalone. But if the initial plugin is exclusively for images, and then we introduce other plugins that are not for images, would they be made to depend on the plugin for images? That wouldn't make sense to a user either. Otherwise, do we copy the same foundational logic into each of these plugins? I think this gets overly burdensome and it isn't pragmatic.

ThierryA commented 8 months ago

Regarding the prefixing, I'm not sure. Prefixing within Performance Lab makes no sense, this you're already in the Performance Lab UI. If we decide to prefix all plugins on .org, I'd rather say that we should put logic in PL that (just for the PL settings screen) removes the "Performance Lab" prefix from the plugin name. If the names are predictable as such, that would be easy to do.

So for whether to prefix or not? On the one hand, it's great for recognizability and spreading the word of the "Performance Lab" brand. On the other hand, it may not be in line with the overarching idea of making the plugins standalone. Of course they'd still be technically standalone, but I'm not sure a strong connection with the Performance Lab plugin or brand is desirable in light of the original objective.

I'm totally not sold on either, curious to hear other opinions.

Regarding prefixing standalone plugins names with "PL" or "Performance Lab" on .org, as I can only see benefits and in a sense we are already re-using the same assets throughout all standalone plugins. When looking at a standalone plugin on the .org repo, the re-used assets already makes the user familiar from one plugin to another, however this is not the case in the wp admin plugin list (not in order, no common asset etc.), which is an issue for multiple reasons. Adding the prefix will fill that gap and compliment the re-used assets across all standalone plugins. Regarding the Performance Lab UI, If the standalone plugins names are prefixed with "PL" or "Performance Lab" on .org, it should be striped in the the Performance Lab UI (again, similar to Jetpack).

westonruter commented 8 months ago

@ThierryA how about https://github.com/WordPress/performance/pull/1052 which dynamically adds a "PL" prefix to the standalone plugin names when the Performance Lab plugin is active? It also adds a Performance Lab link to the plugin row meta pointing to the settings screen.

felixarntz commented 8 months ago

@westonruter

But let's say Optimization Detective is split out into a plugin specifically for Image Loading Optimization. Playing this out, when wanting to experiment with content visibility or preserving space to reduce layout shift, and so on, will this mean adding additional plugins for each feature? To an end user, these are difficult to position independently as well. They are very technical. To the end user, they just want to have an optimized loading experience.

I think it's possible to find names that are more accessible than just using the technical name of the API. Similar to how e.g. the "Speculation Rules" name I originally went with is probably not that great :)

Regarding end users wanting an "optimized loading experience", again that to me is a broad statement and mostly an argument to put all loading optimization features (a.k.a. almost any performance feature) into a single plugin, but we can't do that. And strictly speaking, CLS (e.g. content-visibility) has nothing to do with loading experience.

So for end users, I don't see how splitting into multiple plugins will make it more end-user friendly. Conversely, as you note, breaking up these functionalities into separate plugins would be complicated from an engineering standpoint since they all depend on this same underlying foundation to work.

This isn't really a good counter argument IMO. You're not saying why it's not more user friendly, but instead focus on DX, which is of course relevant but doesn't impact how user friendly whichever approach is.

But if the initial plugin is exclusively for images, and then we introduce other plugins that are not for images, would they be made to depend on the plugin for images?

That would indeed not make any sense. The proper way would probably be something akin to "Optimization Detective" being a library, or a pure infrastructure plugin (like "Plugin Dependencies") that provides the infrastructure but none of the features implemented on top of it. Could be a Composer package present in every plugin, or its own plugin that is then required via the new plugin dependencies feature in WordPress core.

Anyway, let's take a step back here. I think there are broader questions to answer before we can pinpoint a good name:

  1. I think what we've been discussing so far is: Do we organize and name standalone plugins by user-facing features, or is it also okay to group conceptually unrelated features in a single plugin because they use the same technical infrastructure?
  2. Another question that came to my mind related to this is: Do we focus our plugins on the average end user appeal, or rather on the proposed WordPress core merge?
    • Let me clarify this one with an example.
    • Something like “Image loading optimization” describes the user-facing feature. However, it is arguably not the core value proposition of the plugin (for instance, WP core already does image loading optimization, just by far not as good as this plugin because of its new infrastructure).
    • Something like “Optimization Detective” describes the core value proposition and what really is the essence proposed for WordPress core. However, it is not really a feature but rather technical infrastructure to implement different features, so it’s not very appealing for the average end user.

From a core perspective, it makes little sense to focus a plugin on "Image loading optimization" as that by itself doesn't sound like a win for core, as core already has that functionality. So from that perspective focusing on the key infrastructure makes more sense. But that doesn't change that for a non technical end user that approach is probably unclear. It doesn't mean we shouldn't go with that. But we have to define what our highest priorities are.

westonruter commented 8 months ago

@felixarntz

Regarding end users wanting an "optimized loading experience", again that to me is a broad statement and mostly an argument to put all loading optimization features (a.k.a. almost any performance feature) into a single plugin, but we can't do that.

If standalone plugins have no technical relation to each other, then indeed it makes no sense to have them all in one plugin. It makes no sense to have WebP Uploads, Speculation Rules, and Dominant Color Images bound up together since they are unrelated.

And strictly speaking, CLS (e.g. content-visibility) has nothing to do with loading experience.

Content visibility is not actually about CLS. It's about speeding up rendering performance by not spending time rendering content that isn't on the screen. This does help with the page loading experience. And, for CLS, reducing layout shifts also seems clearly related to improving the loading experience? I guess it depends on how technically you define "loading" as strictly to streaming bytes over the network or if it's more generally just the page loading until the load event.

This isn't really a good counter argument IMO. You're not saying why it's not more user friendly, but instead focus on DX, which is of course relevant but doesn't impact how user friendly whichever approach is.

It's more user friendly because users don't have to juggle having more discrete plugins installed than they have to. They don't have to try to figure out what a specific aspect of the page loading is being optimized. They just know that it is performing various related optimizations which are technically closely linked together.

That would indeed not make any sense. The proper way would probably be something akin to "Optimization Detective" being a library, or a pure infrastructure plugin (like "Plugin Dependencies") that provides the infrastructure but none of the features implemented on top of it. Could be a Composer package present in every plugin, or its own plugin that is then required via the new plugin dependencies feature in WordPress core.

IMO this adds additional overhead that isn't worth the effort. Having to go to the trouble of creating a Composer package would then mean the same code is duplicated across all the plugins and may be running concurrently, making it less efficient. And then there's the burden of making sure that if only one copy of the Composer package is actually running at once, that changes to it are done in a backwards-compatible way to prevent other consumers of the package from breaking. Having a common "Optimization Detective" infrastructure plugin would be a bit better, but to me this is going down a rabbit hole with excessive layers of abstraction than we actually need. Also, the plugin directory disallows such framework plugins (except by exception) meaning users would be unfamiliar with having a plugin installed that does nothing on its own.

If standalone plugins are truly standalone, then by all means keep them separate. However, if features are closely related either from a technical standpoint (e.g. depending on a core infrastructure piece like output buffering and URL metrics) or a semantic standpoint (e.g. WebP and AVIF image format support), to me it make sense to group them in common plugins.

felixarntz commented 8 months ago

@westonruter

It's more user friendly because users don't have to juggle having more discrete plugins installed than they have to. They don't have to try to figure out what a specific aspect of the page loading is being optimized. They just know that it is performing various related optimizations which are technically closely linked together.

But then why not ship all of those features in a single Performance Lab plugin in the first place? For some users what you're saying would certainly be better. But that's similar to grouping all features in Performance Lab, and we shouldn't be doing this grouping of semantically unrelated features anymore.

IMO this adds additional overhead that isn't worth the effort.

I'm not sure how much effort that really is. It's common for reusable infrastructure pieces to be in their own packages / libraries. The fact that we have plugin dependencies now is perfect for this kind of use-case. End users don't need to worry about it anymore: If they want for instance "Image loading optimization" (or whatever such a plugin would be called), the other plugin with the technical foundation would be installed for them automatically.

Having to go to the trouble of creating a Composer package would then mean the same code is duplicated across all the plugins and may be running concurrently, making it less efficient. And then there's the burden of making sure that if only one copy of the Composer package is actually running at once, that changes to it are done in a backwards-compatible way to prevent other consumers of the package from breaking. Having a common "Optimization Detective" infrastructure plugin would be a bit better, but to me this is going down a rabbit hole with excessive layers of abstraction than we actually need. Also, the plugin directory disallows such framework plugins (except by exception) meaning users would be unfamiliar with having a plugin installed that does nothing on its own.

A Composer package may indeed be overkill. But given we have a monorepo, deploying the single codebase either in its own plugin (via Plugin Dependencies) or bundled into the individual feature plugins (with e.g. prefixing to avoid any of the complexities and potential issues you're describing) would be relatively straightforward, without Composer. Again, since Plugin Dependencies just landed in WordPress, I'd say having an "API" or "infrastructure" plugin for that purpose would be a great solution. And for that plugin, a name like "Optimization Detective" would work well. It would provide a clean separation of concerns, and users would be able to pick which actual features they want to have, similar to how they can do with the other standalone plugins.

westonruter commented 8 months ago

@felixarntz

But then why not ship all of those features in a single Performance Lab plugin in the first place? For some users what you're saying would certainly be better. But that's similar to grouping all features in Performance Lab, and we shouldn't be doing this grouping of semantically unrelated features anymore.

Because the Performance Lab plugins are feature plugins which are being developed for potential core merge. Grouping technically-unrelated plugins doesn't make sense for core merge since they would be proposed separately. Having technically-related functionality in one plugin (like Gutenberg) makes sense to me from a core merge perspective.

I'd like to get some insights from others as well 😄

swissspidy commented 8 months ago

I knew naming things is hard but I didn't expect it to turn into such a fundamental discussion about the project 😄

I tend to agree with Weston here, it's a holistic way to optimize a page based on real user data, so makes sense to keep that all together. But I can see both sides and being able to cherry pick features has benefits too. There it depends on the features though, whether it actually makes sense to do that or if it should be an all-or-nothing approach.

Right now this is all theoretical though, we're just getting started with this feature and I don't really like overcomplicating* this already. Can't we just start with "Optimization Detective" with this 1 feature in it, and then go from there? Once there are more features cooking we can reevaluate it and decide whether it makes more sense to split things up or not.

*In regards to overcomplicating or over-engineering things I'm also wary of the maintenance burden. Plugin dependencies, composer packages, abstractions, etc. — this all costs time and effort that I would much rather spend on developing important new performance features for users.

ThierryA commented 8 months ago

@ThierryA how about https://github.com/WordPress/performance/pull/1052 which dynamically adds a "PL" prefix to the standalone plugin names when the Performance Lab plugin is active? It also adds a Performance Lab link to the plugin row meta pointing to the settings screen.

I think that would actually make it worth as suddenly the PL plugins start modifying plugin name in the WP Admin. On this one, I continue to believe that prefixing standalone plugins with "Performance Lab" without over-engineering workarounds would be hugely beneficial to tie these back to the overall project. Perhaps I should ask what down side you see (aside from length which IMO definitely doesn't outweigh the pros)?

Regarding bundling and feature names, I am sharing my two cents on this as well:

Taking the "Optimization Detective" as an example, it unfortunately goes against the two points above. To me the infrastructure/component/framework (you name it) could be named "Optimization Detective API" and each features built using the API should be its own plugin with the API/component/framework/package (you name it) bundled (some features may be bundled if they are very related and it make sense to do so). Of course deployment and bundling requires a bit more maintenance and thing like version conflict handling but from a user (whatever the type of user it is) it make a lot more sense.

Can't we just start with "Optimization Detective" with this 1 feature in it, and then go from there? Once there are more features cooking we can reevaluate it and decide whether it makes more sense to split things up or not.

In this case I would suggest to start with a plugin named by the 1st feature, "Optimization Detective" does not give any indication to the user of what that is, it is purely named by the technical infrastructure powering the feature ;)

westonruter commented 8 months ago

Alright, for Optimization Detective, how about this:

  1. We submit Optimization Detective (with the optimization-detective slug) to the plugin review team with its existing image loading optimization bundled. Having the feature in the plugin will likely make it easier for review.
  2. We create a new plugin for Image Loading Optimization as part of Performance Lab which makes Optimization Detective a dependency and move those aspects from Optimization Detective to Image Loading Optimization.
  3. We rename "Optimization Detective" to "Performance Lab Optimization Detective API" or whatever when we have settled on prefixing.
  4. At this point we list Image Loading Optimization exclusively among the plugins on the Perf Lab settings screen. The Optimization Detective plugin will only be installed as a dependency.
  5. Other plugins also integrate with Optimization Detective, either as being dependents in the case of "Content Visibility" or else as suggested, as in the case of Embed Optimizer (https://github.com/WordPress/performance/issues/1054).

Aside: I like the idea of renaming the Performance Lab plugin as Perf Lab, especially for the sake of prefixing.

How does this sound? If good, please review https://github.com/WordPress/performance/pull/1041 so it can be merged as soon as possible to unblock further work so I can get Optimization Detective submitted to the plugin review team next week. (I'm OOO the last week of March 😄.)

adamsilverstein commented 8 months ago

Coming in a bit late, mostly I want to say I mostly agree with this:

If standalone plugins are truly standalone, then by all means keep them separate. However, if features are closely related either from a technical standpoint (e.g. depending on a core infrastructure piece like output buffering and URL metrics) or a semantic standpoint (e.g. WebP and AVIF image format support), to me it make sense to group them in common plugins.

Bundling things to create a cohesive feature-set that uses serveral strategies to do one thing well like optimizing images or optimizing embeds or optimizing the loading prioritization of the LCP element (aka Monsieur lá Detective) feels like the right balance of perspectives to me.

One way of looking at this I like is - would this entire plugin get merged into core as a single enhancement? (and then no longer maintained) - if so, it makes sense to be a single plugin.

For the modern image plugin, it probably makes sense to bundle WebP, AVIF - and ideally picture element support - in one plugin (without any options). For Optimization Detective the oEmbed and Content Visibility features do seem more separate, so I like the direction of making this a library the other plugins depend on.

Aside: would the Image optimizer expand to include detecting other LCP elements (video and maybe iframes) and would you change the name then? I guess I feel it is more of a "Prioritization Optimizer" overall?

For the prefix conversation, I do agree we should have a more cohesive User Experience which I feel this helps support. I would also love to see us revamp the feature activation UI to make it less like the plugin installer screen (and more like Jetpack). Is there already an Issue for that?

westonruter commented 8 months ago

@adamsilverstein

Aside: would the Image optimizer expand to include detecting other LCP elements (video and maybe iframes) and would you change the name then? I guess I feel it is more of a "Prioritization Optimizer" overall?

Good point. Perhaps "Media Loading Optimization" would make more sense, so it can span images and videos. I think "Asset" would be too broad as this is not intending to optimize script and stylesheet loading. For iframes, would this fall under the scope of Embed Optimizer?

adamsilverstein commented 8 months ago

For iframes, would this fall under the scope of Embed Optimizer?

Probably yes, good point.

I remember there were some limitations in detecting iframe LCP elements, do you know if that is still the case?

Perhaps "Media Loading Optimization"

What about other LCP element types? Optimizing for those feels like part of the same "feature".

Here is some recent data on the LCP element types: https://almanac.httparchive.org/en/2022/performance#lcp-content-types, it seems like covering the top types are all part of one feature although images do make up 72/82% of LCP elements. I believe iframes are not included here not because they don't happen but because they aren't or weren't properly detectable in JavaScript. Also video % is miniscule, probably mostly served in iframes.

image

The divs are mainly containers for a background image:

image

I already offered my admittedly not great name suggestion: "Prioritization Optimizer" :) "Media" sounds like it excludes text?

joemcgill commented 8 months ago

What a lively conversation 😆! It seems to me like we're conflating two quite fundamental questions into one here, which is complicating things.

First, it seems like we don't have a great strategy for what constitutes a standalone plugin, which leads to disagreement about whether certain features should be bundled together and which should stay in separate plugins.

From a maintainability standpoint, and a user experience standpoint, I tend to agree with this sentiment shared by @adamsilverstein on this first point:

Bundling things to create a cohesive feature-set that uses several strategies to do one thing well like optimizing images or optimizing embeds or optimizing the loading prioritization of the LCP element (aka Monsieur lá Detective) feels like the right balance of perspectives to me.

Even so, I don't think it's easy to foresee how an initial feature might naturally expand in the future to be just one option in the service of a larger feature set.

As an example, the WebP module started as a way of both supporting WebP uploads in the media library AND generating WebP intermediate sizes rather than JPEG. Once upload support landed in core, the module (now plugin) persists as essentially a toggle to turn on intermediate sizes generation. Now that AVIF support is in Core, we could create another feature plugin for generating AVIF intermediate sizes, but that seems less ideal than having a single plugin for modern image support, where we can experiment with early support for uploading new formats (e.g. JPEG XL) and provide a way for sites to serve users images that use modern formats (i.e., intermediate image generation).

Already in this conversation it's clear that the API that @westonruter has been working on to be able to support optimization of asset loading based on front end data could have implications for many features in the future (asset loading optimizations, content visibility, responsive image heuristics, etc.), but those features don't necessarily relate as a single plugin unless we think of the API itself as the main feature, and the optimizations as examples of how that feature can be applied (e.g., the way some initial experimental blocks were used to demonstrate the Interactivity API).

Second, even if we had clear agreement on what constitutes a standalone plugin, we don't have a convention for naming each of our plugins in a way that are consistent and provides a cohesive user experience. I think this is an easier problem to solve, given that plugin titles can change fairly easily.

I would be fine prefixing all of our plugins with "Performance Lab". I don't love the redundancy that this would bring to the install UI we have in the main PL plugin (see example screenshot) but I agree with all of the other benefits this would bring to the plugins admin screen and in the main .org plugin repo.

proof of concept of updated names

It would also make our individual plugin names less important because they wouldn't need to stand on their own. The downside is that we're prioritizing "Performance Lab" as the main brand umbrella under which all of our work sits. PL does have more brand equity than anything else we could use at the moment, so that's probably not a bad thing. If we were to do so, then our convention could be something like:

westonruter commented 8 months ago

@adamsilverstein

I remember there were some limitations in detecting iframe LCP elements, do you know if that is still the case?

Oh yes, this is indeed the case. I'm able to get a video recognized as the LCP element, but it ignores iframe for cross-origin privacy/security concerns. Barry pointed me to https://web.dev/articles/crux-and-rum-differences#iframes. Therefore it seems that the Web Almanac report on most common LCP elements is missing a key piece of data. Even in DevTools an iframe LCP element is not detectable. Barry also pointed me to https://issues.chromium.org/issues/40939581 to address that. Maybe this would extend to Lighthouse getting support for LCP iframes, which would then result in Web Almanac getting iframe in that graph. I guess "Element Loading Optimization" would be generic enough to include media and text, although perhaps too vague for end users.

You're right about text being a good candidate as well, although this is trickier to optimize since it potentially involves stylesheet processing and font loading. But just because it is tricky doesn't mean we shouldn't do it 😄

ThierryA commented 8 months ago

"Prioritization Optimizer"

If it is about media, image or whatever else, it should be clear if possible. As a user, "prioritization optimizer" doesn't say much IMO.

I would be fine prefixing all of our plugins with "Performance Lab". I don't love the redundancy that this would bring to the install UI we have in the main PL plugin (see example screenshot) but I agree with all of the other benefits this would bring to the plugins admin screen and in the main .org plugin repo.

With the PL plugin UI, I would prefer it be cleaner than the screenshot sent, ie. without the icons and automatically strip the "Performance Lab: " (in this context only, as we are within the PL admin screen already).

felixarntz commented 8 months ago

Sharing my 2 cents on all the recent replies here: @joemcgill correctly pointed out that we are discussing two distinct topics here: One is whether to prefix all standalone plugins with "Performance Lab" (or another brand specific prefix). The other one is how to scope our standalone plugins (and based on that how to choose their names). While opinions differ on both, the latter seems more complex to discuss as there are more things factoring into the decision.

westonruter commented 8 months ago

@felixarntz

  • The proposal @westonruter shared in Review current plugin names and their descriptions for their accuracy and helpfulness #1046 (comment) partly looks good to me, though I don't see the benefit of submitting "Optimization Detective" at this point. I would much prefer that we suggest the current plugin, as is, as "Image Loading Optimization" (or any other suitable name that describes that feature). Here's why:

    • Image loading optimization is the only end user facing feature that the plugin comes with.
    • We have been building the plugin with this feature scope in mind from the beginning. While there has always been the idea of making the infrastructure reusable (which I am 100% in favor of!), those ideas only started materializing recently.
    • This means that the technical infrastructure, at least in my perspective, is not as ready to be released in an infrastructure plugin as the actual feature, from an end user perspective, is ready to be released in a feature plugin. APIs have extra requirements in terms of stability and flexibility, and I don't think we have thought of those aspects enough so far - because we didn't have to. Publishing as an image loading optimization plugin allows us to get the feature out there, including use of the current API, without having to release something that is IMO unfinished as "here is this new API" plugin. It gives us time to polish the API separately and pull it out into its own plugin once we're happy with it.
    • Submitting under that feature scope means we can later pull out the technical infrastructure without "breaking" user expectation. This plugin would be for image loading optimization, and always will be - even if later it may require another plugin dependency to the technical infrastructure plugin.

Here are two such non-image features for Embed Optimizer which depend on Optimization Detective:

These should land soon after Embed Optimizer launches because for embeds which are in the initial viewport, lazy-loading the embed will end up hurting LCP. The first issue would fix this and LCP would be further enhanced by the second.

So I would prefer that we get Optimization Detective out the door now as the foundational plugin (initially including the image optimization functionality). However, before we start promoting it in Performance Lab, we extract the image optimization functionality into a dependent plugin which is what we would actually promote to users. This will give more time to let the name bake. This would result in the least disruption to users because introducing a plugin dependency will cause friction in either direction we go:

  1. If the functionality is all inside of Image Loading Optimization and we later introduce a dependent Image Loading Optimization plugin, then a user will upgrade Optimization Detective only to find that they lost their optimizations and the plugin doesn't do anything.
  2. If we put all the functionality into an Image Loading Optimization plugin initially and then later introduce an Optimization Detective dependency, then the upgrade flow is similarly broken, because core does not (currently) block an update if the new version has a dependency.

For the second scenario, I just tested this and here's the flow...

First, a plugin update is available:

1

Update appears to be successful:

2

However, upon reloading the page, now the plugin is shown to be missing a dependency which is only advertised on this screen:

3

If I try updating the plugin via the Updates screen, there is no such warning:

Upgrade Available Update Successful Reload Updates Screen
Screenshot 2024-03-18 10 45 24 Screenshot 2024-03-18 10 45 44 image

So again, I request that we submit the plugin as-is with all the functionality in Optimization Detective. This initial release of Optimization Detective should be considered a developer preview (and we can indicate as much in the plugin name). We then work on creating the dependent plugin and release it the same time as an update to Optimization Detective with the additional API for plugins to extend (e.g. Embed Optimizer). Only at this point do we start promoting to users for testing. This will prevent an awkward upgrade path. WDYT?

felixarntz commented 8 months ago

@westonruter Thanks for testing the second flow. While I think in principle the second option gives a better user experience, the lack of core's support for introducing plugin dependencies after the plugin was already installed would indeed make that experience poor as well. (It's a bummer this is not supported, I hope it'll be added.)

Based on your first option though, I'd say in this case we shouldn't market it as or call it "Image loading optimization" at all as otherwise, like you're saying, users would lose the feature when updating, possibly without knowing, which IMO would still be even worse than the additional dependency. So if we submit it as optimization-detective now, let's call it that from the beginning. And we could put somewhere information like "The plugin currently also includes a feature that optimizes image loading performance, as a proof of concept for the underlying infrastructure.".

I would also agree that we should not promote this plugin in Performance Lab until we have completed the split into two plugins so that it's better suited for at-scale usage without encountering any of the quirks the two "migration" options would bring.

Is that in line with what you're thinking?

westonruter commented 8 months ago

@felixarntz Yes, exactly!

So if we submit it as optimization-detective now, let's call it that from the beginning. And we could put somewhere information like "The plugin currently also includes a feature that optimizes image loading performance, as a proof of concept for the underlying infrastructure.".

Yes, let's include this note in the readme as well as some "(Developer Preview)" in the plugin name. But perhaps do that after the initial plugin review by the plugin review team, to avoid confusion. So we can merge #1041?

felixarntz commented 8 months ago

@westonruter SGTM!

Let's separately review and consider the actual API surface and what that could look like decoupled from the image loading optimization. It may already be there, or very close, but I want to make sure we make it a mindful effort to get that ready for potential consumption by third-party code, in terms of future flexibility and stability.

felixarntz commented 8 months ago

Per the above, as we're going to move forward with submitting Optimization Detective with the intention of it being an API plugin and eventually having an image loading optimization plugin as well, this leads us to the following tentative list (based on https://github.com/WordPress/performance/issues/1046#issuecomment-1991201597, with a few iterations):

Plugin / Feature Slug Description
Auto-sizes for Lazy-Loaded Images auto-sizes Instructs browsers to automatically choose the right image size for lazy-loaded images.
Embed Optimizer embed-optimizer Optimizes the performance of embeds by lazy-loading iframes and scripts.
Image Loading Optimization TBD Optimizes the loading of the LCP image by leveraging client-side detection with real user metrics.
Image Placeholders dominant-color-images Displays placeholders based on an image's dominant color while the image is loading.
Optimization Detective optimization-detective Provides an API to use real user metrics to improve heuristics WordPress applies on the frontend to improve image loading priority.
Performant Translations performant-translations Makes internationalization/localization in WordPress faster than ever before.
Speculative Loading speculation-rules Enables browsers to speculatively prerender or prefetch pages when hovering over links.
Modern Image Formats webp-uploads Converts images to more modern formats such as WebP or AVIF during upload.

I added the slugs for reference. As always, those cannot be changed once established, which is the case for almost all of them.

I'm personally not super happy about "Image loading optimization", I wonder if there's a more catchy or precise name for what this does. The other thing is that I find the "Performant Translations" description (which other than using a third-person verb is the same as the current one) sound more like a tagline / marketing than a description, in particular the "faster than ever before" part.

Separately, keep in mind that each of them may be prefixed with "Performance Lab" or similar, based on the other discussion ongoing here. Though that shouldn't impact how we choose the actual plugin names and descriptions.

WDYT about these proposed plugin / feature names and descriptions? @joemcgill @adamsilverstein @westonruter @swissspidy

westonruter commented 8 months ago

I think the slug for Embed Optimizer would naturally be embed-optimizer.

For Optimization Detective, the description can be updated to omit "to improve image loading priority" since that's specifically what Image Loading Optimization would be doing (once it is split out).

As for naming that plugin, I think it's actually pretty precise already, but catchy it is not. What about "Image Prioritization" or "Image Prioritizer"?

westonruter commented 8 months ago

Just to confirm, we are agreed on embed-optimizer as the slug for that plugin? I don't want to submit it for review prematurely 😅

felixarntz commented 8 months ago

WFM. I don't think anyone has questioned that at any point, so we can probably submit. In any case, it's "only" the slug. 😆

swissspidy commented 8 months ago

At first glance: Improves accuracy of optimizing the loading of the LCP image by leveraging client-side detection with real user metrics. -> Optimizes the loading of the LCP image by leveraging client-side detection with real user metrics.

Otherwise let's just start with something instead of bikeshed any longer :)

felixarntz commented 8 months ago

I think before we open any PRs to change those plugin names and descriptions for further review, the other big question is: To prefix or not to prefix? In other words, should we have "Modern Image Formats" etc. or "Performance Lab Modern Image Formats" etc?

Alternatively, we move forward without the prefixing for now. Not at all because we shouldn't do it, but because this is another decision to make, and the original purpose of this issue was to revise the plugin names and descriptions for their accuracy rather than deciding on branding.

LMKWYT.

@swissspidy I've updated https://github.com/WordPress/performance/issues/1046#issuecomment-2005134234 with your suggestion.

swissspidy commented 8 months ago

Let's discuss the exact prefix separately.

I assumed the prefix would include a colon or something. "Performance Lab Modern Image Formats" reads a bit weird, "Performance Lab: Modern Image Formats" would look better.

westonruter commented 7 months ago

As for naming that plugin, I think it's actually pretty precise already, but catchy it is not. What about "Image Prioritization" or "Image Prioritizer"?

How do we feel about "Image Prioritizer"? This would work well for fetch priority as well as lazy-loading.

westonruter commented 6 months ago

Going back to the topic of prefixing the plugin names with "PL", I have an alternate proposal to use the plugin row meta to explicitly indicate that a feature plugin is coming from the Performance Lab plugin: #1222.