Verhindern Sie, dass Coralogix RUM Ihr frühes Netzwerk stiehlt

Ein RUM-Tool hat eine Aufgabe: die UX zu messen, die Ihre Nutzer tatsächlich erhalten. Coralogix tut während des Ladevorgangs das Gegenteil. Es beginnt in dem Moment mit dem Senden von Beacons, in dem Sie init aufrufen. Wenn sich dieser Aufruf also in Ihrem Haupt-Bundle befindet, feuert das SDK seinen ersten Batch in das Lade- und Hydratationsfenster und stiehlt genau dem LCP Netzwerk, das es eigentlich messen soll. 

Das Tool verschlechtert zuerst die Zahl und meldet sie dann. Das ist verdreht. Deshalb schreibe ich hier einen Workaround, der die Daten puffert und sie beim Verlassen der Seite an die Coralogix-API sendet (genau wie CoreDash es standardmäßig tut, falls Sie also nach einem besseren RUM-Tool suchen, sollten Sie einen Wechsel in Betracht ziehen).

Coralogix denkt, es sei wichtiger als Ihre Seite

Sehen Sie sich an, womit dieser Beacon konkurriert. Ihr Hero-Image. Ihre Schriftarten. Das Skript, das die Seite hydratisiert. Über Glasfaser bemerken Sie es vielleicht nie. Aber Ihre Nutzer sind nicht alle über Glasfaser verbunden. Auf einem Smartphone, in einem Zug, im Hotel-WLAN ist die Bandbreite knapp, und dieser Beacon kämpft mit Ihren eigenen Inhalten darum. Die Besucher mit den schlechtesten Verbindungen werden es bemerken. Und wofür??

Und hier ist der Teil, der Sie stören sollte: Es gibt keinen Grund für all diese frühen Daten. Keinen. Die Daten beziehen sich nur auf einen Besuch, der noch andauert. Niemand liest sie live (und wenn doch, wäre das wirklich gruselig). Sie können im Speicher bleiben und gesendet werden, wenn der Besuch endet, was nichts kostet und keinen Verlust bedeutet. Es während des Ladevorgangs zu senden, hat nur Nachteile. Es kann die Seite nur verlangsamen und bringt Ihnen nichts. Das ist dumm. Also holen Sie sich die Kontrolle zurück: Erfassen Sie jedes Ereignis, senden Sie keines davon, bis der Besuch beendet ist.

In Ordnung, genug gemeckert. Zeit für die Lösung. So bringen Sie Coralogix dazu, sich richtig zu verhalten!

Puffern Sie alles, senden Sie nichts

Coralogix bietet Ihnen einen beforeSend-Hook. Wenn Sie das Ereignis zurückgeben, wird es gesendet. Wenn Sie null zurückgeben, wird es verworfen. Schieben Sie also das Ereignis zuerst in ein Array und geben Sie dann null zurück. Jedes Ereignis wird erfasst, nichts geht über die Leitung.

import { CoralogixRum } from '@coralogix/browser';

const PUBLIC_KEY = '<YOUR_PUBLIC_KEY>';
const APPLICATION = 'my-app';

// Capture every event, send none of them live.
const buffer = [];

CoralogixRum.init({
  public_key: PUBLIC_KEY,
  application: APPLICATION,
  version: '1.0.0',
  coralogixDomain: 'EU1',
  beforeSend: (event) => {
    buffer.push({ event, t: Date.now() }); // stamp now, flush later
    return null;                           // suppress the SDK's own beacon
  },
});

Ich habe überprüft, dass dies alles Wichtige abfängt, denn beforeSend liest sich in der Dokumentation wie ein reiner Fehlerfilter. Das ist es nicht. Es wird für jeden Ereignistyp ausgelöst: den Init-Snapshot, Resource Timing, jeden Web Vital, Benutzerinteraktionen und Fehler. Das SDK macht weiterhin seinen eigentlichen Job und misst die gesamte Seite. Es bleibt nur im Netzwerk ruhig, bis Sie ihm sagen, dass es leeren soll.

Leeren Sie es beim Verlassen

Senden Sie nun den Puffer, wenn die Seite ausgeblendet wird. Hier scheitert die naive Version. Sie greifen nach navigator.sendBeacon, weil das der lehrbuchmäßige Weg ist, beim Entladen zu senden. Hier funktioniert es nicht. Der Ingress authentifiziert sich mit einem Authorization: Bearer-Header, und sendBeacon kann keine Request-Header setzen. Es gibt true zurück und quittiert stillschweigend mit 403s. Verwenden Sie stattdessen fetch mit keepalive. Es übersteht das Entladen auf die gleiche Weise, und Sie können den Header setzen.

Noch etwas, das der Beacon vor Ihnen verborgen hat: Der Ingress nimmt keine rohen Ereignisse an. Das SDK packt jedes in einen Span und postet { logs: [...] }. Bauen Sie diese Form also wieder auf, bevor Sie senden.

const INGRESS = 'https://ingress.eu1.rum-ingress-coralogix.com/browser/v1beta/logs';
// swap eu1 for your region (us1, us2, eu2, ap1...) to match coralogixDomain

// The ingress wants the SDK's span shape, not raw events. Rebuild it.
function toCxSpan({ event, t }) {
  const hasStack = !!(event.error_context
    && event.error_context.original_stacktrace
    && event.error_context.original_stacktrace.length);

  return {
    version_metadata: event.version_metadata,
    applicationName: APPLICATION,
    subsystemName: 'cx_rum',
    severity: (event.event_context && event.event_context.severity) || 3,
    isErrorWithStacktrace: hasStack,
    timestamp: t,
    text: { cx_rum: Object.assign({}, event, { timestamp: t }) },
  };
}

function flush() {
  if (!buffer.length) return;
  const logs = buffer.splice(0).map(toCxSpan); // drain: a second call sends nothing

  fetch(INGRESS, {
    method: 'POST',
    keepalive: true, // survives unload, and unlike sendBeacon it can set headers
    headers: {
      'Authorization': 'Bearer ' + PUBLIC_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ logs, skip_enrichment_with_ip: false }),
  }).catch(function () {});
}

document.addEventListener('visibilitychange', function () {
  if (document.visibilityState === 'hidden') flush();
});
window.addEventListener('pagehide', flush);

splice leert den Puffer, sodass ein zweites Ausblend-Ereignis nichts sendet. visibilitychange auf hidden ist das zuverlässige Signal, selbst auf Mobilgeräten, wo unload nie ausgelöst wird. pagehide ist die Absicherung. Ein Vorbehalt: keepalive teilt sich ein Budget von 64 KB über alle laufenden Anfragen, daher kann eine lange Sitzung, die Tausende von Ressourceneinträgen puffert, es zum Überlaufen bringen. Wenn Sie stark sammeln, stückeln Sie das logs-Array in einige kleinere Posts.

Was es kostet

Sie bauen jetzt das Format von Coralogix von Hand nach, seien Sie vorsichtig! Der session_context ist etwas dünner als der eigene des SDKs. Coralogix füllt die Session-ID, den User Agent und das Gerät aus, nachdem beforeSend ausgeführt wurde, sodass Ihre handgefertigten Spans weniger dieser Details enthalten als ein normaler Beacon. Für die Erfassung von Core Web Vitals spielt das keine Rolle. Für tiefgreifende Sitzungsanalysen vielleicht schon. Und bestätigen Sie eine 200 in Ihrem Netzwerk-Tab beim ersten Deployment, denn ein falscher Schlüssel oder eine strengere CORS-Regel schlägt auf die gleiche stille Weise fehl wie der Beacon.

Wenn es sich nach einer schlechten Zeit anhört, ein Wire-Format aufrechtzuerhalten, das Ihnen nicht gehört, besteht die stumpfe Alternative darin, CoralogixRum.init() auf nach der Hydratation zu verschieben und das SDK von dort aus normal senden zu lassen. Sie verlieren die Lade-Metriken vor der Initialisierung, behalten aber Ihren Verstand. Wählen Sie Ihren Kompromiss.