Speculation Rules API: Panduan Lengkap Navigasi Web Instan dengan Prefetch dan Prerender

Apa Itu Speculation Rules API?

Pernahkah kamu merasa frustrasi menunggu halaman web yang baru diklik untuk dimuat? Tenang, kamu nggak sendirian. Pengguna juga merasakannya — dan Google sangat peduli soal ini. Nah, di sinilah Speculation Rules API hadir sebagai solusi yang (jujur saja) cukup revolusioner untuk membuat navigasi antar halaman terasa instan.

Jadi, apa sebenarnya Speculation Rules API ini?

Sederhananya, ini adalah fitur browser yang memungkinkan developer memberikan "petunjuk cerdas" kepada browser tentang halaman mana yang kemungkinan besar akan dikunjungi pengguna selanjutnya. Browser kemudian bisa melakukan prefetch (mengunduh) atau bahkan prerender (merender sepenuhnya) halaman-halaman tersebut di latar belakang. Hasilnya? Ketika pengguna benar-benar mengkliknya — boom, halaman langsung muncul tanpa jeda.

Dan ini bukan sekadar teori. Data dari implementasi nyata menunjukkan hasil yang bikin mata melebar:

• Shopify mencatat peningkatan kecepatan hingga 180ms di seluruh metrik loading pada perangkat mobile
• WordPress 6.8 dengan speculative loading meningkatkan passing rate LCP sebesar 1,9% di median — kedengarannya kecil, tapi ingat ini mencakup jutaan situs WordPress
• Studi kasus Navigation AI menunjukkan halaman yang di-prerender mengalami peningkatan LCP sebesar 85% (dari 3,1 detik menjadi 0,4 detik!)

Angka-angka ini bukan main-main. Dan yang terbaik? Implementasinya relatif sederhana — bahkan kalau kamu belum terlalu berpengalaman dengan optimasi performa.

Memahami Dua Strategi Utama: Prefetch vs Prerender

Sebelum kita masuk ke implementasi, penting banget untuk memahami dua strategi yang ditawarkan oleh Speculation Rules API. Keduanya punya tujuan yang sama — mempercepat navigasi — tapi dengan pendekatan dan trade-off yang berbeda.

Prefetch: Pendekatan yang Lebih Hemat

Prefetch mengunduh file-file esensial halaman tujuan (terutama HTML, CSS, dan resource kritis) di latar belakang. Browser belum merender halaman tersebut sepenuhnya, tapi ketika pengguna mengklik link, sebagian besar resource sudah tersedia di cache lokal. Anggap saja seperti menyiapkan bahan masakan sebelum mulai memasak — belum jadi, tapi prosesnya jauh lebih cepat.

Kelebihan prefetch:

• Konsumsi memori dan bandwidth jauh lebih rendah dibanding prerender
• Aman digunakan secara luas tanpa risiko overhead yang berlebihan
• Cocok untuk halaman yang memiliki banyak link keluar
• Mendukung cross-origin (dengan batasan tertentu)

Dalam pengujian, halaman yang di-prefetch menunjukkan peningkatan LCP sekitar 52% — dari 3,1 detik menjadi 1,5 detik. Bukan instan seperti prerender, tapi tetap peningkatan yang sangat signifikan.

Prerender: Navigasi yang Benar-Benar Instan

Prerender? Ini levelnya beda.

Browser tidak hanya mengunduh resource — ia merender halaman secara lengkap di tab tersembunyi, termasuk menjalankan JavaScript, memuat subresource, dan melakukan data fetch. Ketika pengguna akhirnya menavigasi ke halaman tersebut, browser tinggal "menampilkan" halaman yang sudah siap.

Hasilnya? Navigasi yang terasa instan — seolah-olah halaman sudah terbuka sejak awal.

Tapi (selalu ada tapi, kan?), prerender juga datang dengan biaya yang lebih tinggi:

• Menggunakan memori dan CPU yang setara dengan merender sebuah iframe
• Bandwidth jauh lebih besar karena semua resource dimuat sepenuhnya
• Terbatas pada navigasi same-origin (cross-origin memerlukan opt-in dari server tujuan)
• Browser membatasi jumlah halaman yang bisa di-prerender secara bersamaan

Jadi, kapan pakai yang mana? Aturan umumnya cukup sederhana: gunakan prefetch untuk link yang mungkin diklik, dan prerender untuk link yang hampir pasti diklik (misalnya, link CTA utama atau navigasi yang paling populer).

Implementasi Dasar Speculation Rules

Oke, mari kita mulai dari yang paling sederhana. Speculation rules didefinisikan dalam format JSON, di dalam tag <script type="speculationrules"> yang ditempatkan di HTML halaman kamu.

Daftar URL Statis

Cara paling straightforward adalah mendefinisikan URL tertentu yang ingin kamu prefetch atau prerender:

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/produk", "/tentang-kami"]
    }
  ],
  "prefetch": [
    {
      "urls": ["/blog", "/kontak", "/faq"]
    }
  ]
}
</script>

Pada contoh di atas, halaman /produk dan /tentang-kami akan di-prerender (navigasi instan), sementara /blog, /kontak, dan /faq akan di-prefetch (loading lebih cepat tapi tidak instan).

Pendekatan ini cocok untuk situs dengan navigasi yang sudah jelas dan statis. Tapi bagaimana kalau situs kamu punya banyak halaman dinamis?

Di sinilah document rules masuk.

Document Rules: Spekulasi Berbasis Selektor CSS

Document rules memungkinkan kamu mendefinisikan aturan spekulasi berdasarkan selektor CSS, bukan URL spesifik. Ini jauh lebih fleksibel dan scalable — dan menurut saya, ini yang membuat Speculation Rules API benar-benar powerful.

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/logout" } },
          { "not": { "href_matches": "/checkout/*" } },
          { "not": { "selector_matches": ".no-prerender" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}
</script>

Aturan di atas akan men-prerender semua link internal, kecuali halaman logout, halaman checkout, dan link yang memiliki class no-prerender. Parameter eagerness yang diset ke moderate berarti prerender hanya dilakukan ketika pengguna mengarahkan kursor ke link selama 200 milidetik.

Pendekatan ini jauh lebih cerdas dan aman — kamu nggak perlu mendaftar setiap URL secara manual, dan aturan eksklusif memastikan halaman sensitif tidak di-prerender tanpa sengaja.

Menguasai Parameter Eagerness

Parameter eagerness ini, jujur, adalah salah satu fitur paling penting dalam Speculation Rules API. Kenapa? Karena ia mengontrol seberapa agresif browser melakukan spekulasi. Ada empat tingkat yang tersedia:

1. Immediate

Spekulasi dilakukan segera setelah aturan ditemukan oleh browser. Ini paling agresif — cocok untuk link yang hampir pasti akan diklik, seperti tombol CTA utama atau link "halaman berikutnya" dalam pagination.

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["/promo-spesial"],
      "eagerness": "immediate"
    }
  ]
}
</script>

2. Eager

Saat ini berperilaku identik dengan immediate, tapi Chrome berencana menempatkan perilakunya di antara immediate dan moderate di update mendatang. Gunakan ini kalau kamu mau agresif tapi siap dengan perubahan perilaku di masa depan.

3. Moderate

Spekulasi dipicu ketika pengguna mengarahkan kursor (hover) ke link selama 200 milidetik. Ini adalah sweet spot yang bagus — cukup cepat untuk memberikan pengalaman yang terasa instan, tapi cukup konservatif untuk tidak membuang resource pada link yang hanya dilewati kursor secara tidak sengaja.

Oh, dan untuk perangkat mobile (mulai Januari 2026), heuristik viewport sederhana memicu spekulasi 50ms setelah anchor masuk ke viewport — karena, ya tentu saja, mobile nggak punya konsep hover.

4. Conservative

Spekulasi hanya dilakukan ketika pengguna benar-benar mengklik atau menyentuh link (pada saat pointerdown). Jendela waktunya sangat singkat — biasanya antara 100-200ms antara pointerdown dan navigasi — tapi tetap bisa memberikan peningkatan yang terukur.

Tip praktis: Untuk sebagian besar situs, kombinasi ini bekerja dengan baik:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": { "href_matches": "/*" },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/api/*" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

Dengan konfigurasi ini, link yang di-hover akan di-prerender (navigasi instan), sementara link yang diklik tanpa hover terlebih dahulu tetap mendapat manfaat dari prefetch. Cukup cerdas, kan?

Batas dan Pembatasan Chrome

Browser bukan sumber daya yang tak terbatas, dan Chrome menerapkan batasan yang cukup bijaksana untuk mencegah penggunaan berlebihan. Berikut detailnya:

Eagerness	Batas Prefetch	Batas Prerender	Perilaku Saat Penuh
immediate / eager	50 halaman	10 halaman	Spekulasi baru diabaikan
moderate / conservative	2 halaman	2 halaman	FIFO (yang lama diganti)

Selain itu, ada beberapa kondisi di mana prerender nggak akan terjadi:

• Perangkat dengan memori terbatas
• Mode hemat energi (battery saver) aktif
• Pengaturan "Preload pages" dimatikan oleh pengguna
• Halaman dibuka di tab background
• Cross-origin prerender tanpa header Supports-Loading-Mode dari server tujuan

Satu hal penting yang perlu kamu tahu: cache prerender bersifat per-dokumen dan in-memory. Artinya, semua halaman yang sudah di-prerender beserta subresource-nya akan dibuang ketika pengguna menavigasi keluar dari halaman saat ini. Jadi nggak usah khawatir soal akumulasi memori yang nggak terkendali.

Implementasi via HTTP Header

Selain menyisipkan tag script langsung di HTML, kamu juga bisa mendefinisikan speculation rules melalui HTTP response header. Ini sangat berguna ketika kamu ingin mengontrol spekulasi dari sisi server atau CDN tanpa mengubah markup HTML.

Speculation-Rules: "/rules/speculation.json"

File JSON yang direferensikan berisi aturan yang sama persis seperti yang ada di dalam tag script:

// /rules/speculation.json
{
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/admin/*" } },
          { "not": { "href_matches": "/*.pdf" } }
        ]
      },
      "eagerness": "moderate"
    }
  ]
}

Pendekatan ini punya beberapa keuntungan yang menarik:

• Sentralisasi: Satu file JSON mengontrol spekulasi di seluruh situs
• CDN-friendly: Bisa di-inject di level edge tanpa mengubah HTML
• A/B testing: Gampang banget mengganti file aturan untuk eksperimen performa
• Cache-friendly: File JSON bisa di-cache secara terpisah dari HTML

Implementasi Dinamis dengan JavaScript

Nah, di sinilah hal-hal mulai jadi menarik. Untuk skenario yang lebih kompleks, kamu bisa menambahkan speculation rules secara dinamis menggunakan JavaScript. Ini membuka pintu untuk logika spekulasi yang lebih cerdas — berdasarkan perilaku pengguna, kondisi jaringan, atau bahkan data analytics.

Spekulasi Berdasarkan Riwayat Navigasi

// Tambahkan speculation rules secara dinamis
function addSpeculationRules(rules) {
  const script = document.createElement('script');
  script.type = 'speculationrules';
  script.textContent = JSON.stringify(rules);
  document.head.appendChild(script);
}

// Contoh: Prerender halaman berdasarkan riwayat navigasi populer
async function setupSmartSpeculation() {
  // Ambil data navigasi populer dari analytics
  const response = await fetch('/api/popular-navigations');
  const popularPages = await response.json();

  // Prerender top 3 halaman paling sering dikunjungi
  const topPages = popularPages.slice(0, 3).map(p => p.url);

  addSpeculationRules({
    prerender: [
      {
        urls: topPages,
        eagerness: 'moderate'
      }
    ]
  });
}

// Jalankan setelah halaman dimuat
if (document.readyState === 'complete') {
  setupSmartSpeculation();
} else {
  window.addEventListener('load', setupSmartSpeculation);
}

Spekulasi Berdasarkan Kondisi Jaringan

Ini salah satu aspek yang sering dilupakan developer. Tidak semua pengguna punya koneksi internet yang cepat, dan menyesuaikan strategi spekulasi berdasarkan kondisi jaringan itu bukan cuma best practice — itu tanggung jawab kita sebagai developer.

function getSpeculationStrategy() {
  const connection = navigator.connection;

  if (!connection) {
    // Fallback: gunakan prefetch saja
    return { action: 'prefetch', eagerness: 'moderate' };
  }

  // Koneksi cepat (4G/WiFi) — prerender dengan moderate
  if (connection.effectiveType === '4g' && !connection.saveData) {
    return { action: 'prerender', eagerness: 'moderate' };
  }

  // Koneksi sedang (3G) — prefetch saja
  if (connection.effectiveType === '3g') {
    return { action: 'prefetch', eagerness: 'conservative' };
  }

  // Koneksi lambat atau save-data aktif — skip spekulasi
  return null;
}

function applyAdaptiveSpeculation() {
  const strategy = getSpeculationStrategy();

  if (!strategy) {
    console.log('Spekulasi dinonaktifkan: koneksi lambat atau save-data aktif');
    return;
  }

  const rules = {};
  rules[strategy.action] = [
    {
      where: {
        and: [
          { href_matches: '/*' },
          { not: { href_matches: '/api/*' } },
          { not: { selector_matches: '.external-link' } }
        ]
      },
      eagerness: strategy.eagerness
    }
  ];

  addSpeculationRules(rules);
}

applyAdaptiveSpeculation();

Kode di atas memeriksa kualitas koneksi pengguna dan menyesuaikan strategi spekulasi secara otomatis — prerender untuk koneksi cepat, prefetch untuk koneksi sedang, dan tidak ada spekulasi untuk koneksi lambat atau saat mode hemat data aktif. Menurut saya, ini salah satu pola implementasi yang paling elegan karena menghormati bandwidth dan resource pengguna.

Menangani Halaman yang Tidak Boleh Di-Prerender

Oke, ini bagian yang krusial. Tidak semua halaman cocok untuk di-prerender. Beberapa halaman punya side effect yang bisa menyebabkan masalah serius kalau dirender sebelum pengguna benar-benar mengunjunginya.

Halaman dengan Efek Samping (Side Effects)

• Halaman logout: Bisa menghapus sesi pengguna tanpa sengaja — ini mimpi buruk
• Halaman checkout/pembayaran: Bisa memicu pembuatan order atau transaksi
• Halaman dengan tracking analytics: Bisa mendistorsi data pageview
• Halaman dengan countdown timer: Timer mulai berjalan sebelum halaman ditampilkan

Menggunakan document.prerendering API

Untungnya, ada solusi yang elegan. Untuk halaman yang perlu menangani prerendering secara khusus, kamu bisa menggunakan API document.prerendering:

// Cek apakah halaman sedang dalam mode prerender
if (document.prerendering) {
  // Tunda eksekusi analytics hingga halaman benar-benar ditampilkan
  document.addEventListener('prerenderingchange', () => {
    // Halaman sudah diaktifkan — kirim pageview sekarang
    analytics.trackPageView();
    startCountdownTimer();
    initializeChat();
  });
} else {
  // Halaman dimuat secara normal
  analytics.trackPageView();
  startCountdownTimer();
  initializeChat();
}

// Cara yang lebih bersih menggunakan helper function
function afterPrerender(callback) {
  if (document.prerendering) {
    document.addEventListener('prerenderingchange', callback, { once: true });
  } else {
    callback();
  }
}

// Penggunaan
afterPrerender(() => {
  gtag('event', 'page_view');
  fbq('track', 'PageView');
  initLiveChat();
});

Dengan helper function afterPrerender, kamu bisa memastikan kode-kode yang memiliki side effect hanya dijalankan ketika pengguna benar-benar mengunjungi halaman tersebut. Simpel tapi efektif.

Debugging dengan Chrome DevTools

Bagaimana cara memastikan speculation rules berjalan dengan benar? Untungnya, Chrome DevTools menyediakan alat bawaan yang sangat membantu untuk ini.

Tab Speculative Loads

Buka Chrome DevTools, navigasi ke panel Application, lalu cari Background Services > Speculative Loads > Speculations. Di sini kamu bisa melihat:

• Semua URL target yang terdeteksi dari speculation rules
• Aksi yang dilakukan (prefetch atau prerender) untuk setiap URL
• Rule set mana yang memicu spekulasi tersebut
• Status setiap spekulasi (berhasil, gagal, atau pending)
• Alasan kegagalan kalau ada (misalnya, 404 error atau cross-origin restriction)

Catatan penting: Kamu perlu memuat ulang halaman setelah membuka tab Speculative Loads karena panel ini menggunakan Chrome DevTools Protocol untuk memonitor spekulasi secara real-time.

Network Panel

Prefetch yang dipicu oleh speculation rules juga terlihat di Network panel. Resource yang di-prefetch akan ditandai dengan prioritas Lowest karena Chrome (dengan bijak) memprioritaskan resource halaman saat ini.

Untuk prerender, kamu bisa menggunakan dropdown di bagian atas DevTools untuk berpindah konteks ke halaman yang sedang di-prerender. Ini memungkinkan kamu melihat network activity, console log, dan bahkan melakukan debugging pada halaman yang belum ditampilkan. Cukup keren, honestly.

Performance Panel

Network track di Performance panel menampilkan aktivitas jaringan terkait resource yang di-prerender tanpa perlu berpindah konteks DevTools. Sangat berguna untuk menganalisis timing dan waterfall dari resource yang dimuat selama prerender.

Mengukur Dampak dengan Web Vitals

Setelah implementasi selesai, tentu kamu mau tahu apakah ini benar-benar berdampak, kan? Berikut cara memantau efektivitas speculation rules menggunakan library web-vitals:

import { onLCP, onINP, onTTFB } from 'web-vitals';

function reportMetric(metric) {
  const data = {
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    navigationType: performance.getEntriesByType('navigation')[0]?.type,
    // Deteksi apakah halaman ini di-prerender
    wasPrerendered: document.prerendering !== undefined
      && performance.getEntriesByType('navigation')[0]?.activationStart > 0,
    activationStart:
      performance.getEntriesByType('navigation')[0]?.activationStart || 0,
  };

  // Kirim ke analytics
  navigator.sendBeacon('/api/vitals', JSON.stringify(data));

  console.log(`[${metric.name}] ${metric.value}ms (${metric.rating})`,
    data.wasPrerendered ? '- PRERENDERED' : '- Normal navigation');
}

onLCP(reportMetric);
onINP(reportMetric);
onTTFB(reportMetric);

Perhatikan bahwa untuk halaman yang di-prerender, activationStart akan memiliki nilai positif (bukan 0). Library web-vitals secara otomatis menyesuaikan kalkulasi metrik berdasarkan activationStart, sehingga skor yang dilaporkan mencerminkan pengalaman pengguna yang sebenarnya — yaitu, dari saat mereka mengklik link, bukan dari saat prerender dimulai.

Strategi Implementasi untuk Berbagai Jenis Situs

Nggak semua situs itu sama, dan strategi spekulasi yang optimal juga berbeda-beda. Berikut panduan yang bisa kamu ikuti berdasarkan jenis situs:

Blog dan Situs Konten

Situs konten biasanya punya halaman yang relatif ringan dan aman untuk di-prerender. Ini jenis situs yang paling gampang dioptimasi dengan speculation rules. Strategi yang disarankan:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/artikel/*" },
          { "selector_matches": "article a, .post-list a" }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": { "href_matches": "/kategori/*" },
      "eagerness": "conservative"
    }
  ]
}
</script>

E-Commerce

E-commerce memerlukan perhatian ekstra karena banyak halaman yang punya side effect (keranjang belanja, tracking, dan sebagainya). Kamu perlu lebih berhati-hati di sini:

<script type="speculationrules">
{
  "prerender": [
    {
      "where": {
        "and": [
          { "href_matches": "/produk/*" },
          { "not": { "href_matches": "/produk/*/beli" } }
        ]
      },
      "eagerness": "moderate"
    }
  ],
  "prefetch": [
    {
      "where": {
        "and": [
          { "href_matches": "/*" },
          { "not": { "href_matches": "/checkout/*" } },
          { "not": { "href_matches": "/keranjang/*" } },
          { "not": { "href_matches": "/akun/*" } },
          { "not": { "selector_matches": "[data-no-speculate]" } }
        ]
      },
      "eagerness": "conservative"
    }
  ]
}
</script>

Single Page Application (SPA) — Batasan Penting

Nah, di sini ada catatan penting yang sering bikin developer bingung: Speculation Rules API dirancang untuk navigasi antar dokumen (Multi-Page Application/MPA). Untuk SPA yang menggunakan client-side routing (React Router, Vue Router, dan sejenisnya), speculation rules tidak akan bekerja pada navigasi internal karena nggak ada document navigation yang terjadi.

Tapi jangan kecewa dulu. Kalau SPA kamu menggunakan hybrid approach (misalnya, Next.js dengan SSR/SSG atau Nuxt.js), speculation rules tetap bisa diterapkan pada navigasi hard yang menghasilkan full page load. Pastikan kamu paham pola navigasi di aplikasi kamu sebelum mengimplementasikan speculation rules.

Integrasi dengan Framework Populer

WordPress

Kabar baik untuk pengguna WordPress: versi 6.8 sudah menyertakan speculative loading secara bawaan melalui plugin Speculative Loading. Kalau kamu masih pakai WordPress versi sebelumnya, kamu bisa menginstal plugin ini secara manual dari repositori WordPress.org.

Konfigurasi default WordPress menggunakan prefetch dengan eagerness moderate — pilihan yang aman dan efektif untuk mayoritas situs WordPress. Kamu bisa menyesuaikan perilaku ini melalui filter PHP:

// functions.php — Kustomisasi speculation rules di WordPress
add_filter('wp_speculation_rules_configuration', function ($config) {
  return [
    'mode' => 'prerender',
    'eagerness' => 'moderate',
  ];
});

// Exclude halaman tertentu dari spekulasi
add_filter('wp_speculation_rules_href_exclude_paths', function ($exclude) {
  $exclude[] = '/wp-admin/*';
  $exclude[] = '/my-account/*';
  $exclude[] = '/proses-pembayaran/*';
  return $exclude;
});

Next.js

Untuk Next.js (App Router), kamu bisa menambahkan speculation rules di layout root. Relatif straightforward:

// app/layout.tsx
import Script from 'next/script';

export default function RootLayout({ children }) {
  const speculationRules = {
    prerender: [
      {
        where: {
          and: [
            { href_matches: '/*' },
            { not: { href_matches: '/api/*' } },
            { not: { href_matches: '/dashboard/*' } },
          ],
        },
        eagerness: 'moderate',
      },
    ],
  };

  return (
    <html lang="id">
      <body>
        {children}
        <Script
          id="speculation-rules"
          type="speculationrules"
          dangerouslySetInnerHTML={{
            __html: JSON.stringify(speculationRules),
          }}
        />
      </body>
    </html>
  );
}

Nuxt.js / Vue

Nuxt.js punya modul resmi @nuxtjs/speculation-rules yang bikin integrasi jadi mudah banget:

// nuxt.config.ts
export default defineNuxtConfig({
  modules: ['@nuxtjs/speculation-rules'],

  speculationRules: {
    prefetch: {
      eagerness: 'moderate',
      source: 'document',
      where: {
        href_matches: '/**',
        not: {
          href_matches: ['/admin/**', '/api/**'],
        },
      },
    },
  },
});

Dampak terhadap Core Web Vitals

So, mari kita bahas secara spesifik bagaimana Speculation Rules API memengaruhi setiap metrik Core Web Vitals. Ini bagian yang paling seru menurut saya.

LCP (Largest Contentful Paint)

Ini metrik yang paling diuntungkan oleh speculation rules. Dengan prerender, LCP bisa turun hingga mendekati 0ms karena konten terbesar sudah dirender sebelum navigasi. Bahkan dengan prefetch saja, LCP membaik secara signifikan karena HTML dan resource kritis sudah tersedia di cache.

Data dari Shopify menunjukkan penurunan P95 LCP sebesar 500ms dan P75 sebesar 170ms — perbaikan yang sangat berarti untuk pengalaman pengguna dan skor Core Web Vitals.

INP (Interaction to Next Paint)

Prerender juga bisa memperbaiki INP secara tidak langsung. Kenapa? Karena ketika halaman di-prerender, semua JavaScript sudah dieksekusi dan DOM sudah siap. Interaksi pertama pengguna nggak perlu bersaing dengan parsing, kompilasi, atau eksekusi JavaScript yang masih berjalan — yang merupakan penyebab utama INP yang buruk.

TTFB (Time to First Byte)

Untuk halaman yang di-prerender, TTFB efektif menjadi 0ms karena response sudah ada di memori. Untuk prefetch, TTFB berkurang karena request sudah dikirim sebelumnya — browser nggak perlu menunggu DNS resolution, TLS handshake, dan server processing dari awal.

CLS (Cumulative Layout Shift)

Bonus yang sering nggak disadari: prerender bisa membantu CLS karena semua resource (gambar, font, iframe) sudah dimuat sepenuhnya sebelum halaman ditampilkan. Nggak ada layout shift dari resource yang dimuat secara lazy atau late-loading font.

Best Practices dan Rekomendasi

Berdasarkan data dan pengalaman dari implementasi di berbagai skala, berikut rangkuman best practices yang saya rekomendasikan:

1. Mulai dengan prefetch, lalu tingkatkan ke prerender. Prefetch lebih aman dan punya overhead yang jauh lebih rendah. Setelah kamu memahami pola navigasi pengguna, tingkatkan ke prerender untuk halaman yang paling sering dikunjungi.
2. Gunakan eagerness "moderate" sebagai default. Ini memberikan keseimbangan terbaik antara kecepatan dan efisiensi resource. Hanya gunakan "immediate" untuk link yang benar-benar kritikal.
3. Selalu exclude halaman sensitif. Logout, checkout, halaman dengan mutasi data — semua ini harus diexclude dari speculation rules. Ini non-negotiable.
4. Implementasikan document.prerendering check. Untuk analytics, tracking, dan kode dengan side effect, selalu periksa status prerendering dan tunda eksekusi hingga halaman benar-benar aktif.
5. Hormati preferensi pengguna. Periksa navigator.connection.saveData dan kondisi jaringan sebelum melakukan spekulasi agresif. Nggak semua pengguna punya bandwidth yang melimpah.
6. Monitor dan ukur. Gunakan Chrome DevTools untuk debugging, dan implementasikan RUM (Real User Monitoring) untuk mengukur dampak di lingkungan produksi. Bandingkan metrik antara navigasi yang di-prerender dan yang normal.
7. Perhatikan dukungan browser. Per Februari 2026, Speculation Rules API didukung penuh oleh browser berbasis Chromium (Chrome, Edge, Opera). Firefox dan Safari belum mengimplementasikannya. Pastikan situs kamu tetap berjalan dengan baik tanpa speculation rules — ini adalah progressive enhancement, bukan kebutuhan kritis.

Kesimpulan

Jujur, Speculation Rules API adalah salah satu inovasi web performance paling menarik yang saya temui dalam beberapa tahun terakhir. Kemampuannya untuk membuat navigasi terasa instan tanpa memerlukan arsitektur SPA yang kompleks? Itu game changer bagi ekosistem web.

Yang bikin API ini istimewa adalah kesederhanaannya. Kamu bisa mendapatkan peningkatan performa yang drastis hanya dengan menambahkan beberapa baris JSON di HTML. Dan dengan adopsi yang semakin luas dari platform-platform besar seperti WordPress, Shopify, Cloudflare, dan Akamai — ditambah dukungan tooling yang makin matang — 2026 terlihat seperti tahun di mana Speculation Rules API benar-benar menjadi standar dalam toolkit web performance.

Saran saya? Mulailah dengan implementasi sederhana — prefetch dengan eagerness moderate — dan secara bertahap tingkatkan berdasarkan data real dari pengguna kamu. Ingat, tujuannya bukan spekulasi yang paling agresif, melainkan spekulasi yang paling tepat.

Karena di akhir hari, yang terpenting adalah memberikan pengalaman yang cepat dan responsif bagi pengguna — dan Speculation Rules API adalah alat yang sangat powerful untuk mencapainya.