Topic developers would report slow render times, but the issue was often how their content was structured, not the platform itself. They asked whether there was a way to catch this earlier. At the time, there wasn’t.

Poor render performance usually traced back to:

• Unnecessary calculations
• Flows that packed too much conditional logic into a single path, instead of breaking work into smaller, more manageable pieces.
• Platforms on different package versions that may not have the latest optimizations.

Content could pass validation and still perform poorly in the product. Teams needed two things that didn’t exist yet:

• Impact visibility. Authors needed to understand how their content choices affected render time.
• Integrated feedback. That insight had to show up in the workflow they already used, not as a separate audit.

We analyzed P50 and P90 render times across real content samples to learn which complexity scores correlated with slower performance. That data became the baseline for making runtime cost measurable at validation time.

We used these trends to help inform warning and error thresholds against the P50 and P90 render times from discovery so authors got feedback they could act on before merge.

The first step was a complexity-checking plugin that runs during validation and returns a score for each content file, turning runtime cost from a production surprise into something authors could see before merge.

Under the hood, the plugin walks the content structure and adds points for each pattern it finds. Scoring draws on three configurable inputs from the complexity check plugin: base weights, optional overrides, and optional type weights.

The second step was a metrics export mechanism that could capture more than complexity alone, extending what teams could measure per file as well as define other project-level metadata that could be used for further reporting.

Open source

We shipped two open source plugins in Player Dev Tools that make runtime cost measurable in the workflows teams already use:

• Complexity check, which runs during validation and flags content that exceeds configured thresholds.
• Metrics output, which writes a structured, per-file metrics file for CI and downstream tooling.

The complexity check integrated into the Player CLI first; metrics export followed to capture additional data beyond the complexity score.

Internal

We also built internal plugins for editor and pipeline workflows:

• Per-file metrics, with breakdowns of assets and image usage, to support API change impact analysis and visual refreshes.
• Project-level metadata, including package versions with minVersions support (the minimum version a topic should target for each package across all platforms) and Maven properties extracted during validation.
• PR comment analysis, surfaced automatically via CI for easier discovery.
• Maven plugin, hooking into the common Maven build lifecycle to support topics at scale.

Example output

{
  "minVersions": {
    "@player-ui/player": "1.0.0"
  },
  "properties": {
    "maven.property": "true",
    "other.property": "false"
  },
  "complexity": {
    "maxWarningLevel": 90,
    "maxAcceptableComplexity": 10,
    "typeWeights": {
      "action": 4,
      "input": 8
    }
  },
  "content": {
    "topic-1.tsx": {
      "stats": {
        "complexity": 10,
        "assets": {
          "image": 1,
          "video": 0
        },
        "images": [
          "image-1.png",
          "image-2.png"
        ]
      },
      "features": {
        "sourceType": "dsl"
      }
    }
  }
}

The metrics export work required close coordination with the CGDS design and engineering teams, who owned how plugins integrate into the Player CLI. We needed shared clarity on what was worth exporting and a format that would be straightforward to support and extend.

Rollout also depended on:

• A shared Jenkins library to add new pipeline steps
• Parent-level topic updates to enable new metrics-based capabilities.

Learnings

• I didn’t get to the data-lake export support in this phase. That would have unlocked deeper analysis and reporting across teams.
• Player CLI and Maven follow different lifecycles; supporting both took deliberate effort to keep behavior consistent.

What I’d carry forward

• Making runtime cost measurable changes the conversation from “this feels slow” to “this score is above threshold. Here’s why.”
• Balancing open source and internal plugins was a useful exercise, generic enough for the community and specific enough for our pipelines.

This demo uses fictional metrics export data from two topics. Each topic exports project-level metadata once per build, plus per-file stats and features for its content.

How to explore

1. Choose a topic. Use the dropdown in the header to switch between exports.

2. Review project metadata. A complexity summary shows how files distribute across thresholds; package versions and properties sit below.

3. Select a file. Use the left nav, or open a flagged file from the summary. Choose Project details to return.