Skip to content

feat: track external redirect estimates#1011

Draft
ramboz wants to merge 2 commits intomainfrom
redirect-time-tracking
Draft

feat: track external redirect estimates#1011
ramboz wants to merge 2 commits intomainfrom
redirect-time-tracking

Conversation

@ramboz
Copy link
Collaborator

@ramboz ramboz commented Nov 13, 2025

Provides an updated redirect facet that highlights the time lost in redirects and also separates internal vs. external ones.

Description

With adobe/helix-rum-enhancer#516, we are introducing a more fine-grained redirect checkpoint for which the value will change from 1 (redirect count) to 1:150 or 2~237 (redirect count and redirect time)

The goal here is to update the redirect facts to:

  • surface the time lost in those redirects
  • allow slicing and dicing by internal vs external redirects in our analysis.

Motivation and Context

See discussion in https://cq-dev.slack.com/archives/C07198KKQ07/p1761333727781429

How Has This Been Tested?

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • I have signed the Adobe Open Source CLA.
  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

@aem-code-sync
Copy link

aem-code-sync bot commented Nov 13, 2025

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

  • Re-run PSI checks
  • Re-sync branch
Commits

Copy link
Contributor

@trieloff trieloff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably don't need a redirectDuration metric.

I'd split the facets into: redirect.type, redirect.source, redirect.count, redirect.duration and use a histogram facet for redirect.duration (similar to loadresource.target)

ramboz added a commit to adobe/helix-rum-enhancer that referenced this pull request Jan 21, 2026
## Use Case

As a marketer, I want to know how redirects impact my performance scores so that I can avoid undesired redirect chains.

## Problem

At the moment, the OpTel Explorer only reports on internal redirects, not external ones. We've seen in customer discussions that external redirects could cause major increases to the TTFB that were hard to detect and debug.

## Solution

Leveraging the `PerformanceNavigationTiming` APIs, we can track the time spent on external redirects before we land on the page, and can also estimate the number of redirects accordingly.

Technically, the idea is to track the redirect count and time in the `target` for the `redirect` checkpoint:
- `<redirectCount>:<redirectTime>` for internal redirects
- `<estimatedRedirectCount>~<redirectTime>` for external redirects

## References

adobe/helix-website#1011

See background discussion in https://cq-dev.slack.com/archives/C07198KKQ07/p1761333727781429


## Test URL
https://redirect-time-tracking--helix-rum-enhancer--adobe.aem.page/test/fixtures/otsdk-with-banner.html
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants