GitHub Pages vs Netlify
Perbandingan GitHub Pages dan Netlify untuk situs statis: batas kemampuan, penanganan SPA, form, deploy preview, dan kapan GitHub Pages sudah tidak cukup.
Keduanya gratis, keduanya menyajikan situs statis, keduanya mendukung custom domain dan HTTPS. Jadi orang sering menganggapnya setara dan memilih berdasar kebiasaan.
Padahal perbedaannya cukup tegas, dan bisa diringkas jadi satu kalimat: GitHub Pages hanya menyajikan berkas. Netlify menjalankan platform.
Untuk sebagian orang, "hanya menyajikan berkas" justru yang diinginkan. Untuk yang lain, itu tembok yang akan mereka tabrak dalam sebulan.
Ringkasan keputusan
| Kalau kamu... | Pilih |
|---|---|
| Punya blog Hugo, Jekyll, atau dokumentasi | GitHub Pages |
| Butuh form kontak | Netlify |
| Punya SPA dengan routing sisi klien | Netlify |
| Butuh preview per pull request | Netlify |
| Butuh redirect atau custom header | Netlify |
| Ingin situsnya menempel di repositori | GitHub Pages |
| Repositorimu privat dan akunmu gratis | Netlify |
1. Yang tidak bisa dilakukan GitHub Pages
Daftar ini lebih berguna daripada daftar fitur, karena inilah yang membuat orang akhirnya pindah.
Tidak ada aturan redirect atau rewrite
Ini yang paling sering menggigit. Kalau situsmu SPA dengan React Router atau Vue Router, halaman akan 404 saat di-refresh — dan GitHub Pages tidak punya cara resmi memperbaikinya.
Akalinya dengan menyalin index.html jadi 404.html saat build:
cp dist/index.html dist/404.htmlIni bekerja, tapi ada harganya: server tetap mengembalikan status 404, bukan 200. Mesin pencari melihat semua halaman dalammu sebagai halaman yang tidak ditemukan. Untuk situs publik yang mengandalkan pencarian, itu masalah nyata.
Di Netlify satu baris menyelesaikannya dengan benar:
/* /index.html 200Tidak ada custom header
Kamu tidak bisa mengatur Cache-Control, Content-Security-Policy, atau header keamanan lain. Kalau kamu perlu mengendalikan itu, GitHub Pages bukan tempatnya.
Tidak ada kode sisi server
Tidak ada function, tidak ada API route, tidak ada cara menyembunyikan kunci API. Setiap kali situsmu butuh memanggil API dengan kredensial rahasia, kamu butuh layanan lain.
Tidak ada deploy preview
GitHub Pages hanya punya satu situs per repositori. Tidak ada URL terpisah per pull request. Untuk kerja tim, ini kehilangan yang cukup terasa — Netlify memberi tiap PR alamatnya sendiri secara otomatis.
Repositori privat butuh akun berbayar
Menerbitkan dari repositori privat memerlukan paket berbayar GitHub. Netlify tidak peduli repositorimu publik atau privat.
2. Yang justru lebih baik di GitHub Pages
Bukan berarti GitHub Pages kalah di segalanya.
Tidak ada akun tambahan
Kodemu sudah di GitHub. Tidak ada layanan lain yang perlu didaftar, tidak ada izin OAuth yang perlu diberikan, tidak ada dashboard kedua yang perlu dipantau.
Situs menempel di repositori
Untuk dokumentasi project open source, ini terasa benar. Situsnya hidup bersama kodenya, di tempat yang sama, dengan izin akses yang sama.
Tidak ada batas menit build
Netlify membatasi 300 menit build per bulan di paket gratis. GitHub Actions memberi kuota jauh lebih longgar untuk repositori publik. Kalau kamu sering push, ini terasa.
Tidak akan hilang
Netlify perusahaan yang bagus, tapi tetap perusahaan dengan model bisnis yang bisa berubah. GitHub Pages sudah berjalan lebih dari satu dekade dan terikat pada layanan yang dipakai puluhan juta orang.
3. Perbandingan langsung
| GitHub Pages | Netlify | |
|---|---|---|
| Situs statis | Ya | Ya |
| HTTPS otomatis | Ya | Ya |
| Custom domain | Ya | Ya |
| Build dari Git | Lewat Actions | Bawaan |
| Redirect dan rewrite | Tidak | Ya |
| Custom header | Tidak | Ya |
| Deploy preview | Tidak | Ya |
| Serverless function | Tidak | Ya |
| Form bawaan | Tidak | Ya |
| Rollback sekali klik | Tidak | Ya |
| Repositori privat | Perlu berbayar | Gratis |
| Ukuran situs | 1 GB | Praktis lebih longgar |
| Bandwidth | 100 GB per bulan | 100 GB per bulan |
| Menit build | Longgar (repo publik) | 300 per bulan |
4. Kapan waktunya pindah
Kalau salah satu dari ini terjadi, GitHub Pages sudah tidak cukup:
- Kamu butuh form kontak dan mulai mencari layanan pihak ketiga untuk menanganinya.
- Situsmu SPA dan kamu peduli pada peringkat pencarian.
- Kamu perlu redirect karena struktur URL-mu berubah.
- Kamu mulai butuh menyembunyikan kunci API.
- Timmu ingin meninjau perubahan di browser sebelum merge.
Pindahnya murah untuk situs statis: hubungkan repositori yang sama ke Netlify, isi build command dan publish directory, arahkan DNS. Setengah jam, tanpa mengubah kode.
Jadi, pilih yang mana?
Pakai GitHub Pages kalau situsmu benar-benar statis dan sederhana — blog Hugo atau Jekyll, dokumentasi project, portofolio, landing page satu berkas. Untuk itu semua ia sudah cukup, dan tidak menambah apa pun yang perlu dipikirkan.
Pakai Netlify kalau situsmu punya form, routing sisi klien, kebutuhan redirect, atau dikerjakan lebih dari satu orang. Kelebihannya bukan soal kecepatan — melainkan hal-hal yang tidak bisa kamu akali di GitHub Pages.
Satu saran praktis: jangan pindah sebelum kamu benar-benar menabrak batasnya. Blog Hugo di GitHub Pages tidak akan jadi lebih baik hanya karena dipindah ke Netlify.
Langkah praktisnya
- Deploy Hugo ke GitHub Pages
- Deploy Vite ke GitHub Pages
- Deploy Eleventy ke Netlify
- Upload website HTML/CSS ke Netlify
Untuk gambaran menyeluruh soal pilihan hosting statis, lihat panduan memilih hosting website statis.