Belajar Hermes JS Engine - Observability & Performance Monitoring

#Pendahuluan

Episode 19 menutup dengan pipeline CI yang menghasilkan artefak tervalidasi. Tapi build yang baik bukan bukti aplikasi berjalan baik di lapangan — kalian butuh observability: kemampuan melihat apa yang sebenarnya terjadi di perangkat pengguna. Tanpa itu, semua optimasi hanyalah dugaan.

Roadmap episode 20: metrik runtime yang wajib dipantau, cara menangkapnya di aplikasi, integrasi dengan analytics dan performance tools, lalu menetapkan performance budgets yang bisa ditegakkan.

#Metrik Runtime yang Wajib Dipantau

Fokus pada tiga dimensi yang paling sering menjadi sumber keluhan:

• Startup: waktu dari aplikasi dibuka hingga siap berinteraksi. Di Hermes ini sangat dipengaruhi oleh ukuran dan bentuk bytecode.
• Memori: puncak heap, pertumbuhan antar sesi, dan tanda-tanda kebocoran. Di perangkat low-memory, memori adalah batas yang paling nyata.
• Eksekusi JavaScript: jumlah long tasks, panjang frame, dan kontensi pada JS thread.

Sebagai patokan awal, pakai tabel berikut — angka-angkanya disesuaikan dengan profil aplikasi kalian sendiri:

Angka di atas hanya contoh — yang terpenting, metrik diukur di produksi, bukan hanya di emulator developer.

#Menangkap Metrik di Aplikasi

Hermes di React Native menyediakan Performance API modern. PerformanceObserver bisa memantau long tasks tanpa menginstrumentasi setiap fungsi:

Memantau long task dengan PerformanceObserver

import { PerformanceObserver } from "react-native-performance";
 
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType === "longtask" && entry.duration >= 100) {
      reportMetric("long_task", entry.duration);
    }
  }
});
 
observer.observe({ type: "longtask", buffered: true });

Untuk startup, tandai momen penting dengan performance.mark lalu hitung selisihnya dengan performance.measure di akhir:

Mengukur durasi inisialisasi

import { performance } from "react-native-performance";
 
performance.mark("app:initStart");
// inisialisasi modul, restore state, render pertama
performance.mark("app:initEnd");
performance.measure("app:init", "app:initStart", "app:initEnd");

Untuk memori, global.HermesInternal mengekspos info heap yang bisa disnapshot secara berkala:

Snapshot heap Hermes

function sampleHeap() {
  const info = global.HermesInternal.getHeapInfo();
  reportMetric("heap_used", info.hermes_allocatedBytes ?? 0);
  reportMetric("heap_size", info.hermes_heapSize ?? 0);
}
 
setInterval(sampleHeap, 60_000);

#Integrasi dengan Analytics dan Performance Tools

Metrik yang dikumpulkan di perangkat harus dikirim ke pusat analisis. Dua pendekatan yang umum:

• Performance tools lengkap seperti Sentry Performance atau Datadog — otomatis menangkap frame rate, networking, dan error, plus tracing terdistribusi.
• Pipeline kustom — kirim event metrik ke endpoint analytics kalian sendiri, cocok untuk metrik yang sangat spesifik.

Prinsip yang berlaku di keduanya: batch dan kirim secara berkala, jangan kirim per event. Mengirim ratusan request kecil justru mengganggu performa yang sedang kalian ukur:

Batch metrik sebelum dikirim

const queue = [];
 
export function reportMetric(name, value) {
  queue.push({ name, value, ts: Date.now() });
}
 
setInterval(() => {
  if (queue.length === 0) return;
  const batch = queue.splice(0, queue.length);
  fetch("https://analytics.kalian.app/ingest", {
    method: "POST",
    body: JSON.stringify({ app: "belajar-hermes", events: batch }),
  }).catch(() => {});
}, 30_000);

Jangan lupa redaksi data: jangan pernah menyertakan informasi pribadi dalam event metrik — lihat episode 13 tentang runtime privacy.

#Menetapkan Performance Budgets

Budget tanpa penegakan hanyalah harapan. Tulis budget sebagai file yang bisa dibaca oleh CI dan aplikasi sekaligus:

{
  "coldStartMs": 2000,
  "ttidMs": 350,
  "bundleSizeKb": 4200,
  "heapPeakMb": 180,
  "longTaskMs": 100
}

Di CI, ukur ukuran bytecode dan tolak perubahan yang melewati batas bundle:

Menegakkan budget bundle di CI

import fs from "node:fs";
 
const budget = JSON.parse(fs.readFileSync("budget.json", "utf8"));
const sizeKb = fs.statSync("index.android.hbc").size / 1024;
 
if (sizeKb > budget.bundleSizeKb) {
  throw new Error(
    `bundle ${Math.round(sizeKb)}kB melebihi budget ${budget.bundleSizeKb}kB`,
  );
}
 
console.log("budget bundle terpenuhi");

Budget runtime (cold start, long task, heap) baru bisa ditegakkan lewat agregasi data produksi. Tetapkan kuartil ke-95 sebagai standar, dan jadikan regresi lintas versi sebagai alasan untuk menunda rilis.

#Penutup

Observability mengubah optimasi dari kebiasaan menjadi proses: metrik diukur di produksi, dikirim secara teragregasi, dan dibandingkan terhadap budget yang eksplisit. Kalau angka menurun antar rilis, kalian tahu persis kapan harus menyelidiki — bukan menunggu laporan pengguna.

Inti yang harus dibawa pulang:

• Pantau tiga dimensi utama — startup, memori, dan eksekusi JavaScript — di produksi, bukan hanya di emulator.
• Gunakan PerformanceObserver dan HermesInternal untuk menangkap metrik tanpa mengubah banyak kode.
• Integrasikan dengan performance tools atau pipeline kustom, dan batch pengiriman metrik.
• Tulis performance budget sebagai file yang bisa ditegakkan di CI dan aplikasi.
• Gunakan kuartil ke-95 sebagai patokan, dan perlakukan regresi sebagai gerbang rilis.

Di episode 21, kita bahas Scaling Teams & Release Automation: berbagi konvensi build, on-boarding developer baru ke Hermes runtime, dan mendokumentasikan standar performa serta build. Sampai jumpa!