feat(sdk): couche de capture Web Vitals & timing

[DorianOuvrard]

Contexte

Audit SDK : on capture zéro performance / Web Vitals. C'est le gap #1 (dimension perf : "None").

Pourquoi client-side obligatoire

LCP / CLS / INP / TTFB / FCP viennent du PerformanceObserver du navigateur, absents du flux rrweb. INP est incalculable a posteriori (Event Timing API au moment même). Donc pas de dérive backend possible : il faut capter côté client puis émettre en events.

Scope

• LCP, CLS, INP, TTFB, FCP via la lib web-vitals.
• Long tasks + navigation/resource timing.
• Nouveau module client, lazy-load, émis en events télémétrie.

Références

PostHog (dep web-vitals), Datadog RUM (vitals + resource/long-task timing), Faro (web-vitals attribution), lib GoogleChrome/web-vitals.

Effort : M — Valeur : Haute. Companion bworlds requis (ingest + affichage), voir l'épic.

---

Sources d'analyse. Née d'un audit de conception du SDK @bworlds/launchkit v1.15.0 vs état de l'art (benchmark open-source de la capture d'infos).
Références comparées en source réelle : rrweb (rrweb-io/rrweb), PostHog (PostHog/posthog-js), Sentry (getsentry/sentry-javascript — packages/browser, packages/replay-internal), OpenReplay (openreplay/openreplay), Datadog RUM (DataDog/browser-sdk), Grafana Faro (grafana/faro-web-sdk), lib GoogleChrome/web-vitals. Contrainte transport (plafond 64 KiB partagé sendBeacon/keepalive) : Fetch spec + Sentry #1464.
Note honnêteté : la CSP est vérifiée chez Faro (enableContentSecurityPolicyInstrumentation), pas Sentry ; les défauts PostHog dead-clicks/exceptions sont remote-config-gated (non hardcodés).