GoogleChrome/lighthouse · error · Error

Responsiveness currently unsupported by simulated throttling

Error message

Responsiveness currently unsupported by simulated throttling

What it means

Thrown as a plain Error from Responsiveness.compute_() when settings.throttlingMethod is 'simulate'. The Responsiveness metric (a proxy for INP) measures real user interaction latency from trace events, which is inherently an observed-only metric — there is no Lantern simulation model for it. The error is thrown immediately before any trace processing begins.

Source

Thrown at core/computed/metrics/responsiveness.js:140

      throw new Error(`no interaction event found for responsiveness type '${interactionType}'`);
    }
    // TODO: seems to regularly happen up to 3ms and as high as 4. Allow for up to 5ms to be sure.
    if (minDurationDiff > 5) {
      throw new Error(`no interaction event found within 5ms of responsiveness maxDuration (max: ${maxDuration}, closest ${bestMatchEvent.args.data.duration})`); // eslint-disable-line max-len
    }

    return bestMatchEvent;
  }

  /**
   * @param {{trace: LH.Trace, settings: LH.Audit.Context['settings']}} data
   * @param {LH.Artifacts.ComputedContext} context
   * @return {Promise<EventTimingEvent|null>}
   */
  static async compute_(data, context) {
    const {settings, trace} = data;
    if (settings.throttlingMethod === 'simulate') {
      throw new Error('Responsiveness currently unsupported by simulated throttling');
    }

    const processedTrace = await ProcessedTrace.request(trace, context);
    const responsivenessEvent = Responsiveness.getHighPercentileResponsiveness(processedTrace);
    if (!responsivenessEvent) return null;

    const interactionEvent = Responsiveness.findInteractionEvent(responsivenessEvent, trace);
    return JSON.parse(JSON.stringify(interactionEvent));
  }
}

const ResponsivenessComputed = makeComputedArtifact(Responsiveness, [
  'trace',
  'settings',
]);
export {ResponsivenessComputed as Responsiveness};

View on GitHub (pinned to 9515cd4e58)

Solutions

  1. Use throttlingMethod: 'devtools' or 'provided' (observed mode) when the Responsiveness metric is needed
  2. If you must use simulation mode, exclude Responsiveness from your metric list and handle its absence
  3. Wrap the request in a try-catch and treat the throw as 'metric not applicable' rather than a failure

Example fix

// before
const settings = { throttlingMethod: 'simulate' };
const responsiveness = await Responsiveness.request({trace, settings}, context);

// after
const settings = { throttlingMethod: 'devtools' };
const responsiveness = await Responsiveness.request({trace, settings}, context);
Defensive patterns

Strategy: validation

Validate before calling

// Guard against simulation mode before requesting Responsiveness
if (data.settings.throttlingMethod === 'simulate') {
  // Responsiveness is observe-only — skip or switch mode
  return null;
}
const responsiveness = await Responsiveness.request(data, context);

Try / catch

try {
  const responsiveness = await Responsiveness.request(data, context);
} catch (e) {
  if (e.message === 'Responsiveness currently unsupported by simulated throttling') {
    // Simulation mode — metric not available
    return null;
  }
  throw e;
}

Prevention

When it happens

Trigger: Calling Responsiveness.request() with a settings object where throttlingMethod === 'simulate'. The check at line 139 fires the throw before the method does any work. This is an intentional guard, not a bug — simulation-based INP is not supported.

Common situations: Using Lighthouse's default or custom config with simulated throttling and attempting to compute the Responsiveness metric. Programmatically requesting the Responsiveness computed artifact without checking the throttling method. A pipeline that iterates all metrics regardless of throttling mode.

Related errors


AI-assisted analysis of GoogleChrome/lighthouse@9515cd4e58 (2026-08-13). Data as JSON: /api/errors/7c779b937619bdcb. Report an issue: GitHub.