Update metrics presented on import flow

[renatho]

Proposed Changes

• Overhaul of the metrics presented on the import flow, presenting more real and relevant numbers and copy.

Discussion and more context: p1715972644965929-slack-C02NWDZBL0H

Default items

Dynamic items

Why are these changes being made?

• Some of the previous numbers and copy weren't very accurate.

Testing Instructions

• Checkout branch or use the live link.
• Navigate to: /setup/site-migration/site-migration-upgrade-plan?siteSlug={FREE_SITE_SLUG}&from=https://unknown.unknown&option=everything.
• See the defaults, and check if it makes sense.
• Manually update the line siteMetricData?.basic?.fid?.value in the codebase to 150 (a not good FID).
• Navigate to: /setup/site-migration/site-migration-upgrade-plan?siteSlug={FREE_SITE_SLUG}&from=https://www.mazdausa.com&option=everything.
• Check that the dynamic information was displayed and it makes sense.

Pre-merge Checklist

• [ ] Has the general commit checklist been followed? (PCYsg-hS-p2)
• [ ] Have you written new tests for your changes?
• [ ] Have you tested the feature in Simple (P9HQHe-k8-p2), Atomic (P9HQHe-jW-p2), and self-hosted Jetpack sites (PCYsg-g6b-p2)?
• [ ] Have you checked for TypeScript, React or other console errors?
• [ ] Have you used memoizing on expensive computations? More info in Memoizing with create-selector and Using memoizing selectors and Our Approach to Data
• [ ] Have we added the "[Status] String Freeze" label as soon as any new strings were ready for translation (p4TIVU-5Jq-p2)?
• [ ] For changes affecting Jetpack: Have we added the "[Status] Needs Privacy Updates" label if this pull request changes what data or activity we track or use (p4TIVU-aUh-p2)?

[github-actions[bot]]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-108924

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-108924&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-108924&env=a8c-for-agencies

[matticbot]

Here is how your PR affects size of JS and CSS bundles shipped to the user's browser:

Sections (~122 bytes added 📈 [gzipped])

name                     parsed_size           gzip_size
import-hosted-site-flow       +400 B  (+0.0%)     +122 B  (+0.0%)
import-flow                   +400 B  (+0.0%)     +122 B  (+0.0%)

Sections contain code specific for a given set of routes. Is downloaded and parsed only when a particular route is navigated to.

Legend

What is parsed and gzip size?

Parsed Size: Uncompressed size of the JS and CSS files. This much code needs to be parsed and stored in memory. Gzip Size: Compressed size of the JS and CSS files. This much data needs to be downloaded over network.

Generated by performance advisor bot at iscalypsofastyet.com.

[donnapep]

I ran some of the copy through ChatGPT as it didn't sound quite right but I was having trouble improving readability. Let me know what you think about these:

Google data shows that 24% more WordPress.com sites have good Core Web Vitals as compared to other WordPress hosts.

Higher speed WordPress.com has 30% more sites that are faster than those on other WordPress hosts.

For this one:

98% of sites on WordPress.com respond fast, in accordance with Google recommendations.

I have no sense of what "fast" is so it feels sorta meaningless. Could we replace "fast" with whatever Google's definition of fast is? Something like:

98% of sites on WordPress.com respond within x seconds on the first interaction, in accordance with Google recommendations.

Same question for Higher speed now that I think about it.

And finally, for this one:

Higher availability WordPress.com has zero downtime, compared to 63 minutes per month for other WordPress hosts.

As a user, I'd be pretty skeptical of the claim that we have no downtime. I'm also used to seeing the inverse; that is, an uptime measurement (e.g. 99.99% uptime) as opposed to downtime. WDYT about comparing uptime instead of downtime?

[renatho]

Thank you for your suggestions, @donnapep!

I applied them (https://github.com/Automattic/wp-calypso/pull/90966/commits/f03892b4a6482de3d1d344aa3a974ff33a7f53ca) to iterate and took new screenshots. It seems the texts are big, and maybe not align very well with what was discussed here p1716389806691159/1715972644.965929-slack-C02NWDZBL0H? Maybe too much specific? WDYT of the current version?

---

I have no sense of what "fast" is so it feels sorta meaningless. Could we replace "fast" with whatever Google's definition of fast is? Something like:

Same question for Higher speed now that I think about it.

To make it more clear here in the PR, "Higher Speed" is about the LCP:

LCP reports the render time of the largest image or text block visible in the viewport, relative to when the user first navigated to the page.

And "Faster Response" is about the FID:

FID measures the time from when a user first interacts with a page (that is, when they click a link, tap on a button, or use a custom, JavaScript-powered control) to the time when the browser is actually able to begin processing event handlers in response to that interaction.

---

Same question for Higher speed now that I think about it.

I tried to apply the same idea of the other text here:

98% of sites on WordPress.com renders the largest image or text block visible in the viewport within 2500 milliseconds, in accordance with Google recommendations.

---

As a user, I'd be pretty skeptical of the claim that we have no downtime. I'm also used to seeing the inverse; that is, an uptime measurement (e.g. 99.99% uptime) as opposed to downtime. WDYT about comparing uptime instead of downtime?

In this case, we'd say 99.99% against 99.85%. It seems more relevant for me if we have it in downtime minutes. Make sense for you when you see these numbers?

[donnapep]

Higher speed

Oh yes, higher speed is much too verbose. 😅 I don't think we need such a technical explanation, but I'm struggling to make it sound good. So maybe for now we can just keep "fast" for that one.

Would this still be an accurate statement?

WordPress.com has 30% more sites that display faster than those on other WordPress hosts.

Faster response

Do we need the "in accordance with Google recommendations" bit? The default ones don't have that disclaimer, so I'm just trying to figure out where it came from. Is it to make the metric sound more official / reputable? I also converted to seconds since that's an easier measurement to grok.

98% of sites on WordPress.com respond within 0.1 seconds on the first interaction.

Uptime

In this case, we'd say 99.99% against 99.85%. It seems more relevant for me if we have it in downtime minutes. Make sense for you when you see these numbers?

Yes, I think that comparing uptime percentages makes more sense (unless there's been conversation elsewhere to use downtime?). The 0 minutes would make me not trust WordPress.com since it's impossible to achieve on an ongoing basis. We also talk about uptime on the move landing page. So perhaps this?

WordPress.com boasts a 99.99% uptime, compared to 99.85% uptime for other WordPress hosts.

Do these suggestions make sense given the discussions that you've seen in P2 comments and posts for what we're trying to communicate?

[renatho]

@donnapep, I tweaked the copy based on the last suggestions. https://github.com/Automattic/wp-calypso/pull/90966/commits/36dac8bb3e5a79adf02fea375f1632754740f93a

---

Would this still be an accurate statement?

WordPress.com has 30% more sites that display faster than those on other WordPress hosts.

Thinking a little more, I changed it to "WordPress.com has 30% more sites that display fast compared to other WordPress hosts.". WDTY?

The logic behind that is that we have 78.3% of sites with good LCP (2.5 seconds or less) on WPCOM against 47.9% of sites with good LCP in other hosts.

So I think we could have more (or less) faster sites than WordPress hosts, but here we're just comparing the percentage of sites that is considered fast (with a good LCP in this case).

If you think the "faster than" still makes sense with that, let me know and I'll change it back.

Do we need the "in accordance with Google recommendations" bit? The default ones don't have that disclaimer, so I'm just trying to figure out where it came from.

It came when I updated the original copy from "30% faster" for the first time. The reason I added was to justify what is "fast". When you used "faster" it solved this, and maybe I broke it again changing back to "fast". Anyway, I think the last version is not super bad. WDYT?

Yes, I think that comparing uptime percentages makes more sense (unless there's been conversation elsewhere to use downtime?). The 0 minutes would make me not trust WordPress.com since it's impossible to achieve on an ongoing basis. We also talk about uptime on the move landing page. So perhaps this?

Good point! It makes sense to keep it aligned with what we already present! =)

Do these suggestions make sense given the discussions that you've seen in P2 comments and posts for what we're trying to communicate?

I hope so! I know that design wanted to have less text, but I think it's very hard to achieve because the information is not so simple.

[donnapep]

Thinking a little more, I changed it to "WordPress.com has 30% more sites that display fast compared to other WordPress hosts.". WDTY?

I get what you're saying, though it still reads awkwardly. How about this?

WordPress.com has 30% more sites that load quickly compared to other WordPress hosts.

All the other metrics look good. 😃

[renatho]

I get what you're saying, though it still reads awkwardly. How about this?

WordPress.com has 30% more sites that load quickly compared to other WordPress hosts.

Looks good to me! Updated in https://github.com/Automattic/wp-calypso/pull/90966/commits/1d0c70d90d8ce83139e2cdbd1e1151c3ea4613c5 Thank you for all the help with it, Donna! 🫶

[renatho]

Since it had many string changes, I added the String Freeze label. I'll wait for it before deploying. Meanwhile, if someone has any other insights, we can iterate. ;)

[a8ci18n]

This Pull Request is now available for translation here: https://translate.wordpress.com/deliverables/13555535

Thank you @renatho for including a screenshot in the description! This is really helpful for our translators.

[a8ci18n]

Translation for this Pull Request has now been finished.