Incorrect span timing in trace view

[purplecandy]

Is there an existing issue for this?

• [X] I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• [X] I have reviewed the documentation https://docs.sentry.io/
• [ ] I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nextjs

SDK Version

7.110.0

Framework Version

NextJS 12

Link to Sentry event

https://gosprinto.sentry.io/performance/trace/9e6329bd84a84c7a81c70e04a36601f3/?fov=0%2C5903.199951171875&node=trace-root&search=intranet&statsPeriod=1h&timestamp=1716992863

SDK Setup

  Sentry.init({
    dsn: SENTRY_DSN,
    integrations: [
      new Sentry.browserTracingIntegration({
        heartbeatInterval: 10000,
        idleTimeout: 5000,
      }),
      new Sentry.Integrations.Breadcrumbs({
        console: false,
      }),
    ],
    tracesSampleRate: 0.8,

    beforeSend: (event, hints) => {
      const location = window?.location?.href
      const area = getAreaFromUrl(location)
      event.tags.area = area
      return event
    },

    ignoreErrors: [
      // Ignore all `ResizeObserver loop limit exceeded` errors
      'ResizeObserver loop limit exceeded',
      'ResizeObserver loop completed with undelivered notifications',
    ],
  })

Steps to Reproduce

I'm trying to understand why some of our traces have a large period. Upon closer inspection, it seems like the span browser-request should represent the correct TTFB metric which is 867ms but in the Trace View, it reports the TTFB is 2.8s.

Also, when you look at the trace view's JSON payload, you can't find this leading time. The event start time and the browser request start time closely match. So, not sure how Sentry is calculating these metrics on the dashboard.

Expected Result

The correct trace view should be like this.

Actual Result

Now, in the initial 2s as shown in the screenshot there is nothing taking place and when you look at reviews there is no indicator that suggests why there should be this delay. It has completely ruined the aggregated metrics for us because it's not the case with all traces, like 30% of the time it captures traces like this with an initial leading time.