[WIP] Add core web vitals report type

[sarahfossheim]

Note:

• ! Work in progress / Prototype
• The PR can be reviewed already, but the outcome is not a production-ready app :)

The PR is focused on:

• Configuring the new CWV tech report
• Putting in place
• Adding configuration and template and component structure for the tech report
• Load in the data
• Creating a basic frame and way of displaying the data as a proof of concept

Included:

• Text, labels, and other config in the techreport.json config file
• Landing, Drilldown, Comparison page template files
• Filters (apps, region, rank) can be set through selects, need to press update button to update the filter
  • This also updates the URL
  • The correct page skeleton is drawn on the server-side based on the filters (URL) and the configuration (techreport.json)
  • The geo and rank filters carry over between the pages
  • The APP name is case sensitive and needs to be formatted the same as in the API
  • The category dropdown filters the technology dropdown
  • On the comparison page it’s possible to select multiple technologies
• The data is fetched and drawn client-side
  • On the client we fetch the data through .json files in one global class
  • When the data is fetched, it gets processed and then the HTML gets updated with it
• The data can be further filtered without requiring a new API call by the following criteria:
  • Client, on the page level
  • Sub-metric, on the component level
• The following components are added:
  • Report navigation, to switch between the different pages
  • Technology (+category), rank, geo filters
  • Summary cards on the drilldown page
  • Summary table on the comparison page
  • Timeseries per metric (Good CWVs, lighthouse scores, page weight, adoption)
    • Consists of line chart (Highcharts), summary stats, and table alternative
    • Possible to select sub-metric that updates all the contents of the timeseries
  • CWV sub-metric comparison table
• Start of the styling the pages and components
• More info in: docs/cwv_tech_report.md

To be added

PR can be reviewed even though these are not added yet:

• Charts in the comparison page
The comparison page currently consists only of tables, add the Highcharts timeseries there too
• Code cleanup
  • Make summary cards and table follow the same format as the charts
  • Fetch all text labels from a settings file (easier to update in one central location)
  • Continue documentation
  • Linting
• Bugfixes
  • Category filter doesn’t work when adding new techs in the comparison view

In follow-up PR(s) this autumn:

• Switch from JSON files to the new API
• Styling of the filters
• Improved styling of the page and charts
• UX improvements & improved search
• Copywriting / correct text labels
• Accessibility & performance updates
• Additional charts based on the metrics we have
• …
• See Notion / Figma

Later:

What we know of already:

• Improved functionality and styling
• Additional metrics and charts:
  • Median CWVs
  • Distribution of the CWV values
  • Breakdown / compare / explore by rank
  • Lighthouse audits / opportunities
  • …
• …
• See Notion / Figma

[sarahfossheim]

@tunetheweb using mock responses for the data for now. This is the structure we discussed a while back, but would be great with a sample output with realistic data.

[tunetheweb]

Going to try to play with an alternative approach this week and next. Will let you know how it goes.

[sarahfossheim]

@tunetheweb I guess an alternative to including the "across all technologies with the same filter applied" value like this is always returning an object for "technology": "all" along with the selected technologies.

eg:

{
  "result": [
      {
         "technology": "squarespace",
         "dates": [ ... ],
      }, 
      {
         "technology": "wordpress",
         "dates": [ ... ],
      }, 
      {
         "technology": "all",
         "dates": [ ... ],
      }
  ]
}

[tunetheweb]

Not started playing with it, but I think we should have one API call per technology. And include dates, mobile, desktop, Core Web Vitals, Lighthouse...etc. in it.

all will also count as a technology too.

[sarahfossheim]

@tunetheweb something to discuss: to which extend do we want to configure the pages / sections / components in a json file vs. building the page structure directly in the techreport templates?

[tunetheweb]

I'm OK with NOT putting too much into JSON. It works well for the other reports where they are all basically copies of each other with different config. But this will be it's own, individual one so quite different.

Then again, having the labels in JSON would allow us to potentially offer the report in alternative languages. But should be easy enough to convert the hardcoded labels to config later.

[sarahfossheim]

@tunetheweb is it correct that we'll have one api per metric? or will adoption, metadata, CWVs, lighthouse audits, etc. all come as a result from the same call?

[tunetheweb]

As per above, I've not started playing with it, but I think we should have one API call per technology. And include dates, mobile, desktop, Core Web Vitals, Lighthouse...etc. in it.

all will also count as a technology too.

[sarahfossheim]

As I'm configuring some of the components now, it feels like it would indeed be easier to have one API call per tech and then include everything in there.

Would also be useful if the results will be formatted more or less the same way, so we can do something reusable along the lines of tech.results[metric][selected_client] (with metric being eg. origins, good_cwvs, lighthouse_performance, etc) to render the values.

[tunetheweb]

One minor nit. Do you have editorconfig set up on your IDE? We have a config file to auto add final line breaks (plus other things) to stop GitHub flagging these:

[sarahfossheim]

yes, will fix