Add friendly names to URLs

[patrickhulce]

Split from https://github.com/GoogleChrome/lighthouse-ci/pull/342#issuecomment-638430510.

It'd be great if you could assign friendly names to the URLs that are stored in LHCI projects. A urlToNameMap per project as Paul suggests might work nicely.

[connorjclark]

urlToNameMap seems cumbersome. Would prefer accepting {name: string, url: string} instead of string.

[patrickhulce]

from @vividhsv in https://github.com/GoogleChrome/lighthouse-ci/issues/387#issue-664193620

---

Current in collect we can only specify urls like so

ci: {
  collect: {
      url: [
        `${AUT_BASE_URL}/alerts/1234`,
        `${AUT_BASE_URL}/alerts/5678`,
        `${AUT_BASE_URL}/alerts/9012`,
      ]
  }
}

It would be great if we could name these urls as well.

Example:

ci: {
  collect: {
      url: [
        {name: '/alerts/id - high', url:`${AUT_BASE_URL}/alerts/1234`},
        {name: '/alerts/id - medium', url:`${AUT_BASE_URL}/alerts/5678`},
        {name: '/alerts/id - low', url:`${AUT_BASE_URL}/alerts/9012`},
      ]
  }
}

Also dashboard should show the names instead of the url. This way we could change the underlying url with different id in collection but still use the same name to compare results in dashboard.

[JannikZed]

we are actually facing kind of the same issue using Vercel and automatic CI tests. As every commit gets an individual preview URL in vercel, we can never compare results in Lighthouse server... very sad actually. I also couldn't find a way to just skip the URL selection and just use branches. So compare all URLs of the same branch with each other ..

[patrickhulce]

@JannikZed that problem is slightly different and can be solved using the urlReplacementPatterns option

https://github.com/GoogleChrome/lighthouse-ci/blob/master/docs/configuration.md#urlreplacementpatterns

[zleight1]

Just a thought, it might be nice to have an enable/disable flag per route object.

Rather than having to inject/build the urls, you could easily turn on or off certain routes.

For example we’re using a micro front end approach, and we do a full performance regression on staging.

But since the front ends can be deployed individually, it’d be really useful to run partial builds on pull requests that are scoped to the front end it changed.

Just saw this feature request and thought this would be easy to tack on to the designs you had proposed.

[patrickhulce]

I'm not sure I understand your suggestion @zleight1. Can't you do this already with a lighthouserc written in javascript that uses process.env to decide what URLs to run? What configuration would you propose in LHCI that would make this significantly easier?

[zleight1]

@patrickhulce you could do it that way, but by having it along with the friendly name, it'd be easy to differentiate between partial and full builds.

With this you could perhaps mark it as such on the lhci server as a partial build of 5/10 urls for example.

Probably the best would be to just generate it like you're saying, unless somehow knowing a partial vs. full build has a difference.

i.e. one of the "apps" causes a serious performance impact when in a full build but in partial builds it behaves properly.

[patrickhulce]

Sorry, my question was ill-specified. Let's take a step back.

With this you could perhaps mark it as such on the lhci server as a partial build of 5/10 urls for example.

What exactly is the "this" in the sentence there? It sounds now to me like you want a label on each build whether it was "full" or "partial" based on whether it contained all of the URLs that master did. From my perspective this is orthogonal to friendly names for the URLs. We could do this today without doing friendly names or we could add friendly names for each URL and still not have these labels.

If I'm interpreting this correctly, best to move conversation to a new issue.

If I'm not, more explanation of how this is related to friendly names for URLs would be much appreciated :)

[zleight1]

Sorry, my question was ill-specified. Let's take a step back.

With this you could perhaps mark it as such on the lhci server as a partial build of 5/10 urls for example.

What exactly is the "this" in the sentence there? It sounds now to me like you want a label on each build whether it was "full" or "partial" based on whether it contained all of the URLs that master did. From my perspective this is orthogonal to friendly names for the URLs. We could do this today without doing friendly names or we could add friendly names for each URL and still not have these labels.

If I'm interpreting this correctly, best to move conversation to a new issue.

If I'm not, more explanation of how this is related to friendly names for URLs would be much appreciated :)

"this" seems to be a scope issue in JS 😂 and in "this" thread so I apologize for the loss of "this" context.

You are absolutely correct that my suggestion is probably best suited for another separate issue, but I believe it can leverage the friendly names to be done a bit cleaner. I got excited when I saw the friendly names issue and replied here rather than a new issue.

Basically, what I was proposing was to use each of the friendly names as roughly analogous for a micro-front-end, which would help identify issues that are local in scope (to one MFE) or a problem that is somehow brought about at integration time (since we're doing run-time/client-side integration).

I didn't fully think it through, and having a partial build as I proposed brings about bigger issues such as having the same git commit hash on multiple runs but somehow combining them.

If you go ahead with the friendly URLs we can open a separate issue to explore the feasibility of what I'm proposing, as it might not be a common enough use case to warrant.

If you're interested I've seen similar solutions in a few other tools I could pass along.

[patrickhulce]

Gotcha thanks for explaining!

If you're interested I've seen similar solutions in a few other tools I could pass along.

A few examples of other tools doing what you're describing in a new issue would be great 👍 :)

[patrickhulce]

After some discussion in https://github.com/GoogleChrome/lighthouse-ci/issues/586 it would be great if assertions could benefit from labels as well. In addition, having a single URL display map for the project wouldn't serve long-lived projects very well whose content may change over time. i.e. what if you moved the /help page to /contact and /help was completely different.

We'll expand this issue's scope to encompass some sort of ID + display name that can be decided at collection time (might also solve the mobile + display problem of #138 ).

[ntkoopman]

This would also help with unicode urls, since they get urlencoded and are thus completely unreadable.