---
title: "Web dengan Keterlibatan Rendah: Pembuatan Statis, Cache HTML"
locale: id
category: knowledge_base
category_name: "Basis Pengetahuan"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/low-involvement-web-static-generation-html-cache
published_at: 2026-11-05T07:45:55+09:00
---

# Web dengan Keterlibatan Rendah: Pembuatan Statis, Cache HTML

> Dalam desain teknis web dengan keterlibatan rendah, konten utama dalam HTML awal dan cache HTML di CDN perlu diperiksa bersama. TTFB 0.8 detik merupakan nilai acuan untuk peningkatan kinerja, sementara cakupan penerapan cache dan pembaruan setelah perubahan juga perlu dirancang.

## Key Points

- Memuat konten utama dalam HTML awal dapat mengurangi ketergantungan pada eksekusi JavaScript.
- Google menjalankan JavaScript, sehingga penggunaan React saja tidak cukup untuk menyimpulkan bahwa perayapan oleh mesin pencari gagal.
- TTFB 0.8 detik atau kurang merupakan nilai acuan untuk peningkatan kinerja, bukan waktu pemuatan seluruh halaman.
- Cloudflare CDN secara default tidak menyimpan HTML dalam cache, sehingga aturan cache untuk halaman publik perlu diperiksa.
- Cache HTML memerlukan pengecualian halaman login serta kebijakan pembaruan setelah konten diubah.

Untuk membantu perayapan situs web dengan keterlibatan rendah, konten utama harus disertakan dalam HTML awal. Untuk konten publik, pembuatan statis dan cache HTML di CDN berguna. Namun, mencapai TTFB 0.8 detik saja tidak menjamin kemunculan di hasil pencarian.

Acuan angka TTFB tersebut adalah dokumen web.dev yang diperbarui pada 18 November 2025.

## Kondisi teknis yang perlu diperiksa terlebih dahulu pada web dengan keterlibatan rendah

Dalam artikel ini, web dengan keterlibatan rendah berarti situs web tempat pengunjung memeriksa informasi yang dibutuhkan secara singkat. Rendering dan kecepatan pengiriman merupakan aspek teknis yang perlu diperiksa pada situs seperti ini. Namun, kedua aspek tersebut saja tidak dapat menjelaskan seluruh perbedaan visibilitas di hasil pencarian.

Perayapan adalah proses robot mengambil halaman. Pengindeksan adalah proses mengolah konten yang diambil agar dapat dicari. Google menjelaskan bahwa tidak semua halaman yang dirayapi akan masuk ke indeks. [Panduan anggaran perayapan Google](https://developers.google.com/crawling/docs/crawl-budget)

| Aspek pemeriksaan | Hal yang perlu diperiksa | Masalah yang ingin diatasi |
| --- | --- | --- |
| HTML awal | Apakah judul dan konten utama disertakan dalam respons | Ketergantungan pada eksekusi tambahan untuk membaca konten utama |
| Rendering | Apakah konten tampil dengan benar setelah JavaScript dijalankan | Konten yang tidak tampil akibat kesalahan eksekusi atau pemblokiran |
| TTFB | Waktu yang diperlukan hingga respons pertama tiba | Keterlambatan koneksi dan respons server |
| Cache HTML | Apakah dokumen publik digunakan kembali melalui CDN | Beban permintaan berulang ke server asal |
| Status indeks | Bagaimana Google memproses URL tersebut | Kekeliruan menyamakan keberhasilan perayapan dengan masuknya halaman ke pencarian |

## Mengapa halaman React terlihat seperti HTML kosong

HTML awal halaman React berbeda-beda menurut cara implementasinya. Cara yang membuat konten utama di browser disebut CSR. Dengan cara ini, respons pertama mungkin hanya berisi kode yang akan dijalankan, tanpa konten utama.

Google menggunakan Chromium untuk menjalankan JavaScript. Halaman mungkin harus menunggu proses rendering setelah dirayapi. Halaman atau file yang diblokir dapat dikecualikan dari proses rendering. Tidak semua robot juga menjalankan JavaScript. [Panduan dasar JavaScript SEO dari Google](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)

Karena itu, jangan menilai status perayapan hanya dari tampilan halaman yang normal. Periksa terlebih dahulu apakah konten utama ada dalam respons awal. Hasil rendering Google dapat diperiksa melalui Inspeksi URL di Search Console.

## Perbandingan pembuatan statis dan rendering server

Metode pembuatan HTML dapat dipilih berdasarkan cara konten utama yang bersifat publik diperbarui. Pembuatan statis menghasilkan HTML sebelum permintaan diterima. Rendering server menghasilkan HTML di server saat permintaan diterima. Metode ini juga dapat digunakan pada React. [Panduan metode rendering web.dev](https://web.dev/articles/rendering-on-the-web)

| Metode | Waktu pembuatan HTML | Situasi yang cocok untuk dipertimbangkan | Hal operasional yang perlu diperiksa |
| --- | --- | --- | --- |
| Rendering klien CSR | Saat JavaScript dijalankan di browser | Tampilan dengan banyak interaksi pengguna | Eksekusi dan permintaan yang diperlukan hingga konten utama tampil |
| Pembuatan statis SSG | Saat build atau pembuatan konten | Dokumen publik yang menampilkan konten sama kepada pengunjung | Pembuatan ulang dan deployment setelah perubahan |
| Rendering server SSR | Saat memproses permintaan halaman | Tampilan yang menyusun konten terbaru untuk setiap permintaan | Waktu pengambilan data dan pembuatan HTML |
| Prarendering | Saat aplikasi dijalankan sebelum deployment untuk menghasilkan HTML | Saat menyediakan konten utama awal dari aplikasi yang sudah ada lebih dahulu | JavaScript yang diperlukan untuk fungsi selanjutnya |

Pembuatan statis dan CDN memiliki peran yang berbeda. Pembuatan statis merupakan pilihan mengenai waktu pembuatan HTML. CDN merupakan arsitektur untuk mengirimkan dan menggunakan kembali konten. HTML yang dibuat di server juga dapat disimpan dalam cache CDN jika memenuhi persyaratan.

## Apa arti TTFB 0.8 detik?

TTFB adalah waktu dari dimulainya navigasi halaman hingga diterimanya byte respons pertama. web.dev menyarankan **paling lama 0.8 detik** sebagai sasaran umum untuk sebagian besar situs. Ini berbeda dari waktu hingga seluruh halaman ditampilkan. TTFB sendiri juga bukan bagian dari Core Web Vitals. [Penjelasan TTFB dari web.dev](https://web.dev/articles/ttfb)

TTFB juga mencakup keterlambatan di luar pemrosesan internal server. Pencarian DNS adalah proses mencari alamat koneksi suatu domain. Koneksi TCP dan TLS juga dapat memerlukan waktu. Pengalihan ke alamat lain turut memengaruhinya.

- Waktu pencarian DNS dan persiapan koneksi
- Waktu pengiriman permintaan dan respons melalui jaringan
- Waktu pengambilan data dan pembuatan HTML di server asal
- Waktu pengalihan yang terjadi sebelum respons pertama

Lokasi server di Seoul saja tidak cukup untuk menyimpulkan bahwa waktunya lebih dari 0.8 detik. Hasilnya berbeda menurut lokasi akses dan apakah koneksi digunakan kembali. Perayap Google terutama menggunakan alamat IP Amerika Serikat. Namun, perayap juga dapat mengakses dari alamat IP negara lain. [Karakteristik teknis perayap Google](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en)

Keterlambatan respons yang berkelanjutan memengaruhi kapasitas perayapan Google. Kesalahan server juga dapat menyebabkan berkurangnya jumlah perayapan. Namun, bukan berarti perayapan akan dihentikan begitu waktu respons sekali saja melebihi 0.8 detik. Kualitas halaman dan frekuensi pembaruan juga memengaruhi permintaan perayapan. [Panduan anggaran perayapan Google](https://developers.google.com/crawling/docs/crawl-budget)

## Mengapa cache HTML di CDN perlu diperiksa

Cloudflare CDN secara default tidak menyimpan HTML dalam cache. Meskipun gambar atau CSS disimpan dalam cache, dokumen konten utama harus diperiksa secara terpisah. Periksa perilaku default CDN lain dalam dokumentasi layanan masing-masing.

> Cloudflare CDN secara default tidak menyimpan HTML atau JSON dalam cache.
>
> Cloudflare, Perilaku cache default

Kalimat ini berarti HTML dan JSON bukan sasaran cache secara default. HTML publik dapat dimasukkan sebagai sasaran cache melalui Cache Rules. Apakah respons benar-benar disimpan juga dipengaruhi oleh kondisi seperti header respons dan cookie. [Perilaku cache default Cloudflare](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)

Cache adalah fitur yang menggunakan kembali respons yang telah disimpan. Menghubungkan situs ke CDN tidak berarti semua dokumen langsung disalin ke seluruh dunia. Cloudflare menyimpan konten dalam cache di pusat data yang menangani permintaan. Permintaan untuk konten yang belum ada dalam cache mungkin memerlukan pengambilan dari server asal. [Panduan memulai cache Cloudflare](https://developers.cloudflare.com/cache/get-started/)

Saat menerapkan aturan cache pada HTML publik, kecualikan halaman yang dipersonalisasi. Cloudflare memperingatkan bahwa cache HTML dinamis dapat menyebabkan informasi orang lain terkirim. Jangan simpan halaman login atau akun dalam cache. [Hal yang perlu diperhatikan pada Cloudflare Cache Everything](https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/)

## Kriteria penerapan cache berdasarkan kondisi halaman

Apakah konten yang sama ditampilkan kepada pengunjung menjadi titik awal penentuan cakupan cache. Teks penjelasan publik cocok digunakan kembali secara bersama. Respons yang isinya berubah menurut status login harus ditangani secara terpisah.

| Kondisi halaman | Konfigurasi yang perlu dipertimbangkan | Hal yang perlu diperiksa bersama |
| --- | --- | --- |
| Menyediakan teks penjelasan yang sama kepada pengunjung | Pembuatan statis dan cache HTML publik | Pembuatan ulang dan pembaruan cache setelah perubahan |
| Konten utama publik memuat angka yang sering berubah | Memisahkan cara pembaruan konten utama dan data yang berubah | Waktu acuan angka dan tampilan saat terjadi kegagalan |
| Memerlukan informasi publik terbaru saat permintaan diterima | Mempertimbangkan rendering server dan cache bersyarat | Keterlambatan informasi yang dapat ditoleransi |
| Tampilan login, akun, dan pembayaran | Mengecualikannya dari cache HTML bersama | Cookie autentikasi dan respons per pengguna |
| Menyediakan dokumen publik dalam berbagai bahasa | URL per bahasa dan cache masing-masing dokumen | Tautan antarversi terjemahan dan pembaruan per bahasa |

Memuat data waktu nyata belakangan memudahkan pemeliharaan konten utama yang statis. Namun, jangan menunda pemuatan seluruh konten inti yang diperlukan untuk pencarian. Hal ini dapat bertentangan dengan tujuan penyediaan HTML awal.

## Kesalahan umum dan kriteria pemeriksaan

Menilai hasil hanya dari nama teknologi atau layar pengaturan dapat membuat kesalahan mudah terlewat. Periksa HTML yang sebenarnya beserta header responsnya. Berikut adalah kondisi yang harus dibedakan satu sama lain.

| Penilaian yang umum | Kriteria yang perlu diperiksa |
| --- | --- |
| Situs React tidak dapat dibaca robot pencarian | HTML awal dan hasil rendering Google |
| TTFB 0.8 detik berarti seluruh halaman juga sudah tampil | Waktu dari respons pertama hingga konten utama tampil |
| HTML pasti tersimpan dalam cache karena sudah terhubung ke CDN | Status cache permintaan HTML |
| File statis selalu berisi konten terbaru | Waktu pembuatan terakhir dan konten yang di-deploy |
| Respons cepat berarti halaman sudah masuk ke pencarian | Status pengindeksan di Search Console |
| Menilai kecepatan global dari satu hasil cache hit | Hasil pengukuran berdasarkan wilayah akses dan apakah permintaan dilayani dari cache |

`CF-Cache-Status` milik Cloudflare adalah header yang menunjukkan status cache. `HIT` berarti respons ditemukan dalam cache. `MISS` berarti respons tidak ada dalam cache saat permintaan diterima sehingga diambil dari server asal. `DYNAMIC` berarti respons tidak diperlakukan sebagai sasaran cache. [Penjelasan respons cache Cloudflare](https://developers.cloudflare.com/cache/concepts/cache-responses/)

## Pembaruan cache setelah perubahan konten

Untuk file statis dan cache CDN, alur penerapan perubahan juga harus dirancang. Meskipun konten di server asal sudah diubah, konten lama tetap akan dikirim jika cache lama masih ada. Jika HTML dan JSON diterbitkan bersama, isi kedua format tersebut juga harus diselaraskan.

Berikut urutan pemeriksaan saat mengelola dokumen dan file data secara bersamaan.

1. Tetapkan perubahan pada data sumber.
2. Buat ulang HTML dan file data menggunakan versi perubahan yang sama.
3. Setelah men-deploy file baru, perbarui cache untuk URL yang berubah.
4. Minta kembali setiap URL untuk memastikan perubahan isinya konsisten.

Cloudflare menyarankan penghapusan cache per URL. Penghapusan cache adalah tindakan menghapus respons yang tersimpan. Pembuatan ulang HTML statis tetap harus dilakukan secara terpisah. Karena itu, hubungkan pembuatan file dan pembaruan cache dalam prosedur deployment yang sama. [Panduan penghapusan cache Cloudflare](https://developers.cloudflare.com/cache/how-to/purge-cache/)

Tentukan interval pembaruan sesuai keterlambatan informasi yang dapat ditoleransi oleh konten. Teks penjelasan dan angka waktu nyata tidak harus menggunakan interval yang sama. Masa berlaku cache yang singkat saja tidak dapat menyelesaikan seluruh masalah pembaruan.

## Kriteria hreflang untuk situs multibahasa

`hreflang` adalah informasi yang menghubungkan alamat konten yang sama untuk berbagai bahasa dan wilayah. Ini bukan fitur pembuat terjemahan. Informasi ini membantu Google menemukan versi bahasa yang sesuai untuk pengunjung.

| Lokasi implementasi | Cara penandaan | Hal yang perlu diperiksa saat memilih |
| --- | --- | --- |
| HTML | Mencantumkan tautan bahasa alternatif di `head` dokumen | Apakah dapat dikelola dalam setiap templat halaman |
| Header HTTP | Mencantumkannya dalam header `Link` pada respons | Apakah header dapat dikelola di server |
| Peta situs | Mencantumkan hubungan URL antarbahasa dalam peta situs | Apakah daftar dokumen dapat dikelola sekaligus |

Google memperlakukan semua metode ini secara setara. Karena itu, penandaan tidak harus dimasukkan hanya di dalam HTML. Dokumen setiap bahasa harus mencantumkan dokumen bahasa alternatif, termasuk dirinya sendiri. Periksa juga hubungan antarhalaman yang saling bersesuaian. [Panduan halaman multibahasa Google](https://developers.google.com/search/docs/specialty/international/localized-versions)

## Urutan pemeriksaan hasil deployment

Setelah deployment, verifikasi pengiriman konten utama dan perilaku cache secara terpisah. Catat juga wilayah pengukuran dan status cache bersama hasil pengukuran kecepatan. Urutan berikut memudahkan identifikasi letak masalah.

1. Periksa respons dokumen HTML melalui alat pengembang browser. Pastikan konten utama disertakan dalam respons.
2. Periksa HTML hasil rendering melalui Inspeksi URL di Search Console. Periksa juga status pengindeksan sebenarnya secara terpisah.
3. Periksa header cache pada respons HTML. Untuk Cloudflare, baca `CF-Cache-Status`.
4. Ukur dokumen yang sama dari wilayah akses utama. Bedakan permintaan untuk konten yang tidak ada dalam cache dan permintaan yang dilayani dari cache.
5. Setelah mengubah konten, periksa hasil pembaruannya. Periksa juga apakah halaman login dikecualikan dari cache.

Cloudflare memperingatkan bahwa penerapan cache HTML dinamis secara berlebihan dapat mengganggu fungsi login. Jangan simpan formulir login dan halaman yang memerlukan autentikasi dalam cache. Setelah perubahan, periksa juga apakah cookie autentikasi tetap tersimpan. [Panduan masalah login Cloudflare](https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/)

## Persyaratan implementasi untuk disampaikan kepada AI saat menulis kode

Saat meminta AI, sertakan hasil yang dapat diverifikasi bersama nama teknologinya. Menentukan isi HTML awal dan cakupan pengecualian cache merupakan cara yang berguna. Teks berikut adalah contoh permintaan untuk membuat halaman pengetahuan publik.

```text
Sertakan konten utama halaman pengetahuan publik dalam HTML awal.
Utamakan pertimbangan pembuatan statis untuk dokumen publik.
Jelaskan secara terpisah cara memperbarui data yang berubah.
Periksa apakah cache HTML diterapkan di CDN.
Kecualikan halaman login, akun, dan pembayaran dari cache bersama.
Hubungkan pembuatan ulang file statis dan pembaruan cache saat konten diubah.
Jika ada halaman multibahasa, atur hubungan hreflang.
Berikan cara memeriksa HTML awal, status cache, dan apakah perubahan sudah diterapkan.
```

## FAQ

### Apakah situs web dengan keterlibatan rendah harus dibuat menggunakan kerangka kerja tertentu?
Tidak ada kerangka kerja tertentu yang wajib digunakan. Pastikan konten utama tercakup dalam HTML awal. Tinjau juga cara konten publik disimpan dalam cache dan diperbarui.

### Apakah Google tidak menjalankan JavaScript?
Google menjalankan JavaScript menggunakan Chromium. Namun, waktu tunggu rendering dan sumber daya yang diblokir dapat memengaruhi pemrosesan. Menyertakan konten utama dalam HTML awal dapat mengurangi ketergantungan pada eksekusi tambahan.

### Apakah situs yang dibuat dengan React juga dapat menggunakan pembuatan statis?
React juga dapat menghasilkan HTML statis. Pembuatan HTML di server juga didukung. Isi HTML awal tidak dapat ditentukan hanya berdasarkan apakah React digunakan atau tidak.

### Jika TTFB paling lama 0.8 detik, apakah seluruh halaman sudah terbuka?
TTFB adalah waktu yang dibutuhkan hingga byte pertama respons tiba. Pengunduhan gambar dan penyusunan tampilan masih dapat berlanjut setelahnya. TTFB harus dibedakan dari waktu pemuatan seluruh halaman.

### Jika TTFB melebihi 0.8 detik, apakah situs akan dikeluarkan dari penelusuran Google?
0.8 detik adalah perkiraan target performa yang diberikan oleh web.dev. Ini bukan aturan bahwa situs akan dikeluarkan dari penelusuran jika melampaui waktu tersebut. Keterlambatan respons yang berkelanjutan dan kesalahan server dapat memengaruhi kapasitas perayapan.

### Apakah penggunaan server di Korea merugikan situs global?
Pengunjung yang berada jauh dari server dapat mengalami latensi jaringan. Namun, waktu respons tertentu tidak dapat dipastikan hanya berdasarkan lokasi. Nilailah berdasarkan hasil pengukuran aktual di wilayah utama pengunjung.

### Jika Cloudflare dihubungkan, apakah HTML juga otomatis disimpan dalam cache?
Secara default, Cloudflare CDN tidak menyimpan HTML dan JSON dalam cache. Periksa Cache Rules yang akan diterapkan pada HTML publik. Setelah aturan diterapkan, periksa status cache yang sebenarnya melalui header respons.

### Apakah permintaan pertama yang belum ada dalam cache CDN juga selalu cepat?
Permintaan yang tidak ada dalam cache mungkin perlu mengambil respons dari server asal. Karena itu, latensinya dapat berbeda dari permintaan yang ditemukan dalam cache. Ukur kedua kondisi tersebut secara terpisah.

### Apakah cache HTML boleh diterapkan juga pada halaman login?
Jangan menyimpan halaman login dan HTML yang memerlukan autentikasi dalam cache. Cloudflare memperingatkan bahwa penggunaan cache yang berlebihan dapat mengganggu fungsi login. Ada juga risiko informasi khusus pengguna tersampaikan kepada pengunjung lain.

### Apa yang harus dilakukan jika konten lama masih terlihat setelah artikel di situs statis diedit?
Pertama, pastikan HTML baru sudah dihasilkan dan diterapkan. Setelah itu, perbarui cache CDN untuk URL yang berubah. Menghapus cache saja tidak akan menghasilkan ulang file statis.

### Apakah hreflang hanya boleh dimasukkan ke dalam HTML?
Google mendukung metode HTML, header HTTP, dan peta situs. Ketiga metode tersebut setara dari sudut pandang Google. Pilih metode yang mudah dikelola dan pertahankan keterkaitan antarversi bahasa secara konsisten.

### Apakah anggaran perayapan perlu dikelola secara intensif meskipun situsnya kecil?
Panduan anggaran perayapan Google terutama ditujukan untuk situs besar yang sering diperbarui. Jika jumlah halaman tidak banyak, mulailah dengan memperbarui peta situs dan memeriksa laporan pengindeksan. Jika ada kesalahan server atau konten utama yang hilang, selesaikan masalah tersebut terlebih dahulu.

## Sources

- [Google Search Central: Memahami dasar-dasar SEO JavaScript](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics)
- [web.dev: Rendering di web](https://web.dev/articles/rendering-on-the-web)
- [web.dev: Time to First Byte (TTFB), diperbarui pada 18 November 2025](https://web.dev/articles/ttfb)
- [Google: Gambaran umum crawler dan fetcher Google](https://developers.google.com/crawling/docs/crawlers-fetchers/overview-google-crawlers?hl=en)
- [Google: Optimalkan anggaran crawl Anda](https://developers.google.com/crawling/docs/crawl-budget)
- [Cloudflare: Perilaku cache default](https://developers.cloudflare.com/cache/concepts/default-cache-behavior/)
- [Cloudflare Cache: Memulai](https://developers.cloudflare.com/cache/get-started/)
- [Cloudflare: Tingkat cache (Cache Everything)](https://developers.cloudflare.com/cache/how-to/cache-rules/examples/cache-everything/)
- [Respons cache Cloudflare](https://developers.cloudflare.com/cache/concepts/cache-responses/)
- [Cloudflare: Hapus cache](https://developers.cloudflare.com/cache/how-to/purge-cache/)
- [Cloudflare: Konten dinamis dan masalah login](https://developers.cloudflare.com/cache/troubleshooting/dynamic-content-and-login-issues/)
- [Google Search Central: Beri tahu Google tentang versi halaman Anda yang dilokalkan](https://developers.google.com/search/docs/specialty/international/localized-versions)

## Images

![Seorang pria memeriksa rak server dengan kabel ungu yang tertata rapi](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzgxNjYsInB1ciI6ImJsb2JfaWQifX0=--3301cc345476b9a82de57f9e5bdbad57a8717225/ai-cace8faa.webp)
![Seorang perempuan membandingkan halaman web di dua tablet di samping diagram pembaruan dokumen.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MzgxNzIsInB1ciI6ImJsb2JfaWQifX0=--6d794cafac94909fa4ac95705b51dc5bde79c2df/ai-9e2e0147.webp)