Saltar al contingut principal
Frontend UI & Mètriques60 FPS / INP < 30ms

Dashboard de Telemetria — Rendiment Web a 60 FPS

Panell analític interactiu per a la monitorització de mètriques de rendiment web, concurrència i Core Web Vitals en temps real.

Client / ContextProjecte Personal d'Enginyeria / Open Source
Any de Desenvolupament2025
Rol d'EnginyeriaFrontend Engineer & Performance Specialist
Mètode de VerificacióAuditoria Chrome DevTools Performance Profiler
https://jautur.github.io/portfolio/#skills
Gràfic de telemetria i rendiment d'altes prestacions
Stack d'Enginyeria:JavaScript ES6+TypeScriptPerformance APICSS ContainmentVirtual DOMCore Web Vitals

1. El Problema i el Context

Els panells analítics corporatius que han de mostrar gràfics en viu, fluxes de trànsit i registres de servidors solen patir una degradació sobtada de rendiment a mesura que el volum de dades creix.

Els problemes recurrents inclouen:

  • Bloqueig del fil d’execució (Main Thread Lockup): Operacions pesades de càlcul o format de dades que congelen el cursor i impedeixen la interacció de l’usuari.
  • Micro-talls visuals (Jank): Caigudes sobtades de 60 FPS a menys de 20 FPS durant l’animació de transicions o desplaçaments.
  • Fuites de memòria en flux continu: Acumulació de nodes DOM i subscripcions desconnectades que saturen la memòria RAM del navegador en sessions prolongades.

Aquest projecte es va conceived per a demostrar com dissenyar un panell de telemetria d’altes prestacions que manté 60 FPS estables sota alta càrrega de dades.


2. El Repte Tècnic

  1. Garantir un pressupost de fotograma de 16,6 ms: Cada cicle d’execució de JavaScript, càlcul d’estil i repintat ha de cabre en menys de 16 mil·lisegons.
  2. Optimització del nou Interaction to Next Paint (INP): Minimitzar la latència des del moment en què l’usuari commuta una pestanya fins que la pantalla es dibuixa a menys de 40 ms.
  3. Aïllament de repintats amb CSS Containment: Evitar que l’actualització d’una targeta de mètriques obligue el navegador a recalcular la geometria del document sencer.

3. Decisions d’Arquitectura

Vam implementar una arquitectura de cicle de vida basada en fragments de treball no bloquejants (yielding) i acceleració per maquinari a la targeta gràfica (GPU).

Diagrama del Cicle de Renderitzat 60 FPS

   [ Flux de Telemetria ]
             │
             ▼
   [ Batching d'Events ] ──▶ [ scheduler.yield() / rAF ]
                                        │
                                        ▼
                           [ CSS contain: layout paint ]
                                        │
                                        ▼
                            [ Composició GPU (60 FPS) ]

Fragment de Codi Clau: Renderitzat en Batches

// utils/telemetria-renderer.ts
export class TelemetriaRenderer {
  private isRendering = false;
  private pendingQueue: TelemetriaData[] = [];

  enqueue(data: TelemetriaData): void {
    this.pendingQueue.push(data);
    if (!this.isRendering) {
      this.isRendering = true;
      requestAnimationFrame(() => this.processQueue());
    }
  }

  private processQueue(): void {
    const chunk = this.pendingQueue.splice(0, 100);
    this.renderNodes(chunk);

    if (this.pendingQueue.length > 0) {
      requestAnimationFrame(() => this.processQueue());
    } else {
      this.isRendering = false;
    }
  }

  private renderNodes(items: TelemetriaData[]): void {
    // Actualització atòmica aïllada
  }
}

4. Comparativa: Abans vs Després

Mètrica Implementació Estàndard (DOM Directe) Arquitectura Telemetria 60 FPS
Taxa de Fotogrames (FPS) 24 - 38 FPS (amb caigudes sota scroll) 60 FPS constants
Interaction to Next Paint (INP) ~180 ms < 28 ms
Temps bloquejat total (TBT) ~320 ms 0 ms
Càlcul d’estils (Recalculate Style) Afectava a 1.200 nodes del DOM Limitat a 8 nodes aïllats amb contain

5. Resultats Verificables i Mètriques d’Auditoria

Apliquem el nostre protocol de verificació d’honestedat tècnica:

  • Fotogrames per segon (FPS):
    • Mètode de verificació: Panell Rendering > Frame Rate Meter de Chrome DevTools durant càrrega contínua.
    • Resultat verificat: 60.0 FPS estables; zero fotogrames perduts (dropped frames).
  • Mètrica Interaction to Next Paint (INP):
    • Mètode de verificació: Google web-vitals JavaScript library i panell Performance de Chrome.
    • Resultat verificat: 24 ms mitjana en interacció de filtratge.
  • Consum de memòria en sessió de 30 minuts:
    • Mètode de verificació: Chrome DevTools Memory Heap Snapshot.
    • Resultat verificat: Marge de creixement inferior a 4 MB amb alliberament immediat en Garbage Collection.

6. Aprenentatges i Conclusions

  1. El DOM és el component més car del navegador: Mantenir el recompte de nodes per sota de 1.000 és la millor optimització de rendiment que pot fer un enginyer frontend.
  2. requestAnimationFrame és obligatori per a animacions: Delegar en el refresc vertical del monitor evita càlculs inútils entre fotogrames.
Protocol d'Honestedat Tècnica & Verificabilitat

Com comprovem aquestes mètriques?

Totes les mètriques d'aquest cas d'estudi han estat validades mitjançant eines estàndard d'enginyeria frontend:

Google LighthousePerfil mòbil amb emulació de xarxa per a auditar LCP, CLS i SEO.
axe-core / DevToolsInspecció del document per a verificar compliment WCAG 2.2 AA.
Chrome PerformanceMesura de fotogrames per segon (FPS Meter) i latència INP.