Strip commercial tag properties for DCR tag pages

[jorgeazevedo]

What is the value of this and can you measure success?

Applies withoutCommercial stripping to the tag pages DCR endpoint, mirroring what was done for fronts in #27894. This will lead to reduced CPU usage and latency in the tag-page rendering service.

Let's take the response from https://www.theguardian.com/tone/minutebyminute.json?dcr=true as an example.

Every tag instance inside contents[].properties.maybeContent.tags.tags[].properties has 10 properties, for example:

{
  "id": "football/series/saturday-clockwatch",
  "url": "/football/series/saturday-clockwatch",
  "tagType": "Series",
  "sectionId": "football",
  "sectionName": "Football",
  "webTitle": "Clockwatch",
  "webUrl": "https://www.theguardian.com/football/series/saturday-clockwatch",
  "description": "Catch up with the scores and gossip from all of the day's major football fixtures kick-offs with our minute-by-minute reports",
  "references": [],
  "commercial": {}
}

All of these properties show up as properties in the DCR type FETagType except for commercial.

As it happens, commercial accounts for 60% to 70% of the size of the total size of the DCR payload, and given it's not in FETagType it means the data being sent by Frontend, parsed, but not used by the client at all.

How has this change been tested?

To confirm that the data isn't used in some indirect way, I tested this change by comparing the html returned by DCR with and without the commercial property using the following process.

I first obtained the JSONs from main and from this PR by

Deploying main to CODE and running

curl -s 'https://m.code.dev-theguardian.com/tone/minutebyminute.json?dcr=true' -o minute-code.json
curl -s 'https://m.code.dev-theguardian.com/tone/minutebyminute+australia-news/australia-news.json?dcr=true' -o australia-code.json
curl -s 'https://m.code.dev-theguardian.com/profile/josh-taylor.json?dcr=true&page=8' -o profile-code.json

Deploying this PR to CODE and running

curl -s 'https://m.code.dev-theguardian.com/tone/minutebyminute.json?dcr=true' -o minute-trimmed.json
curl -s 'https://m.code.dev-theguardian.com/tone/minutebyminute+australia-news/australia-news.json?dcr=true' -o australia-trimmed.json
curl -s 'https://m.code.dev-theguardian.com/profile/josh-taylor.json?dcr=true&page=8' -o profile-trimmed.json

I then individually posted all of the JSON to DCR using a series of curl calls like curl -X POST https://localhost:9000/TagPage -H "Content-Type: application/json" -d @profile-code.json -o profile-code.html and made sure I got the same exact number of bytes per html file both the trimmed and non-trimmed version of the JSON.

URL	main JSON	HTML from DCR	PR JSON	HTML from DCR
/tone/minutebyminute.json?dcr=true	651KB	336,554 bytes	227KB (−65%)	336,554 bytes
/tone/minutebyminute+australia-news/australia-news.json?dcr=true	1.1MB	289,505 bytes	362KB (−68.5%)	289,505 bytes
/profile/josh-taylor.json?dcr=true&page=8	829KB	348,071 bytes	281KB (−66%)	348,071 bytes

Performance impact

By using the new tracing functionality (currently a WIP) we're able to see the impact quite clearly. While the request handler performance is the same, receiving the json over the network and parsing it becomes significantly quicker.

Here's a before and after using the australia news payload (which is a worst case)

Before

After

Checklist

• Tested locally, and on CODE if necessary
• Will not break dotcom-rendering
• Any new test data/database files generated by tests are committed with this PR (the tests will fail in CI if you've forgotten to do this) => does not apply
• Meets our accessibility standards => does not apply
  • Tested with screen reader
  • Navigable with keyboard
  • Colour contrast passed

[github-actions]

Deploy build 7501 of dotcom:frontend-all to CODE

All deployment options

• Deploy build 7501 of dotcom:frontend-all to CODE
• Deploy parts of build 7501 to CODE by previewing it first
• What's on CODE right now?

---

From guardian/actions-riff-raff.