DEV Community

Cover image for Turn a Lighthouse export into tickets with traceable threshold evidence
Tim Zinin
Tim Zinin

Posted on

Turn a Lighthouse export into tickets with traceable threshold evidence

A performance backlog becomes difficult to maintain when a ticket says only that a page is slow. The developer needs the measured value, the device strategy, the source capture time and the rule that made the issue actionable. Without those fields, a later audit can appear to contradict the ticket even though it measured a different page state.

PageSpeed Remediation Backlog Builder processes an existing audit batch. It accepts compatible normalized rows and native Lighthouse result objects, then produces a report for each usable URL and strategy pair. Collection remains a separate step. This makes the transformation useful when a team already has a PageSpeed export and wants an inspectable engineering queue.

Keep a small source projection

This example retains measured values from the installed public September snapshot. Its source capture time is deliberately preserved. The figures describe that saved example; they do not describe the website today.

{
  "items": [
    {
      "url": "https://www.bbc.com/",
      "strategy": "mobile",
      "performanceScore": 0.56,
      "LCP": 7170.740664599693,
      "CLS": 0.11022084164631413,
      "TBT": 315,
      "FCP": 3021.000657027039,
      "SI": 6007.5946841464975,
      "metricSource": "lab",
      "metricUnits": {
        "LCP": "ms",
        "CLS": "unitless",
        "TBT": "ms",
        "FCP": "ms",
        "SI": "ms"
      },
      "fetchTime": "2026-09-23T05:03:03.710Z",
      "lighthouseVersion": "13.5.0"
    }
  ],
  "maxInputRows": 100,
  "maxResults": 10
}
Enter fullscreen mode Exit fullscreen mode

The input projection keeps the units beside the measurements. LCP, FCP, TBT and Speed Index use milliseconds, while CLS is unitless. A performance score has its own zero-to-one range. Check these conventions in the receiving application before building a dashboard that combines several audit providers.

Make the ticket explain its rule

The installed transformation applies one disclosed fixed threshold model to mobile and desktop records. Store thresholdModel with the report. That gives a future reviewer enough information to distinguish a changed measurement from a changed triage policy.

For example, the fixed model treats LCP above 4000 milliseconds as poor. A ticket can preserve the literal measured LCP and the corresponding band, then attach the source's named opportunities. This is a reproducible triage decision. It does not establish how much a particular implementation change will improve the next audit.

Missing and invalid metrics need explicit treatment. A missing metric stays unavailable; a negative duration or conflicting declared unit should not become a healthy zero. Keep the evidence describing the exclusion so the source collection problem can be repaired separately from the page.

Add your team's priority after transformation

Reports follow the source's first occurrence of a URL and strategy. The Actor does not calculate a cross-page business priority. Add your own owner, release milestone and affected customer journey in the ticket system rather than implying that source order is an impact ranking.

The named opportunities also retain source order. Estimated savings belong to individual source audits when their units are explicitly time. Adding overlapping savings can double-count the same browser work, so preserve those estimates individually. A ticket should distinguish measured evidence from a developer's proposed remedy.

Define acceptance around a new measurement

Before importing, check the run summary for source coverage and delivery limits. Stage useful reports, retain diagnostics, and keep mobile and desktop identities separate. A partial batch can support individual tickets while still being unsuitable for a complete portfolio report.

When a developer finishes a task, collect an authorized new audit and compare the relevant metric under a comparable strategy. Record the new capture time instead of replacing the old evidence. This gives the ticket a clear history from observation through triage to verification. The local example check used for this article validates the pure transformation only; it supplies no new performance measurement.

Price and verification scope

Listing pricing read on 23 October 2026 is $0.015 per result-found event on the FREE tier. The documented unit is: One useful remediation report delivered with source evidence and a recommended next step. Source errors, invalid rows and budget diagnostics request no result event. Other platform tiers have their own rates. This pricing record has no separate start event. A usable result from an illustrative input can still be billable; inspect the applicable listing and run spending limit before executing it. maxResults is an output cap, separate from the platform's Max total charge option.

This article uses the installed source contract from build 0.1.9 (mGQZfciQKwTXrAYf1). The example is a shortened historical source projection, with local pure-transform validation only. No new Apify cloud build or run was started for this article. Local output does not establish cloud delivery, customer acceptance or commercial results.

Inspect the Actor's current input and pricing.

AI-assisted draft; independent technical and cover review is required before publication.

Top comments (0)