Progressive Web App (PWA) untuk Situs Berita dan Media: Cara Kerja, Manfaat, dan Cara Memasangnya di WordPress

Progressive Web App (PWA) adalah cara membuat situs berita atau media di WordPress terasa seperti aplikasi: pembaca bisa memasangnya di layar utama ponsel, membukanya tanpa koneksi internet untuk artikel yang sudah pernah dibaca, dan menerima notifikasi push untuk berita terbaru — semuanya tanpa mengunduh apa pun dari toko aplikasi dan tanpa membangun aplikasi native. Bagi publisher kecil, ini adalah jalan tengah yang murah antara situs web biasa dan aplikasi mobile. Artikel ini menjelaskan cara kerja PWA, syarat agar situs bisa diinstal, strategi caching yang aman untuk situs berita, serta langkah memasangnya di WordPress dengan plugin, termasuk hal-hal yang perlu dijaga supaya iklan AdSense dan kecepatan situs tidak terganggu.

Poin Kunci

• PWA dibangun dari tiga fondasi: HTTPS, web app manifest, dan service worker. Manifest membuat situs bisa diinstal; service worker membuat situs bisa bekerja offline dan menerima push.
• Di Chrome saat ini, service worker tidak lagi menjadi syarat mutlak untuk instalasi — manifest yang valid, HTTPS, dan interaksi pengguna sudah cukup — tetapi tanpa service worker tidak ada dukungan offline dan notifikasi push yang sesungguhnya.
• Untuk situs berita, manfaat terbesar PWA adalah kunjungan ulang yang lebih mudah (ikon di layar utama), pembacaan offline untuk artikel yang sudah dimuat, dan notifikasi push untuk berita penting.
• Di WordPress, PWA paling mudah dipasang lewat plugin seperti PWA (plugin fitur WordPress.org), PWA for WP, atau Swift PWA — tetapi hanya satu service worker yang boleh aktif dalam satu waktu, jadi jangan memasang dua plugin PWA sekaligus.
• Service worker yang salah konfigurasi bisa menyajikan artikel basi, merusak iklan, atau mengunci pengunjung di halaman error. Artikel dinamis, halaman admin, dan skrip iklan tidak boleh di-cache sembarangan.
• PWA bukan pengganti aplikasi native untuk semua kebutuhan, bukan jalan pintas SEO, dan bukan penyebab langsung ranking naik. Nilainya ada pada retensi pembaca dan pengalaman pengguna, bukan pada trik peringkat.

Daftar Isi

1. Apa Itu Progressive Web App (PWA)?
2. Tiga Fondasi PWA: HTTPS, Manifest, dan Service Worker
3. Mengapa PWA Relevan untuk Situs Berita dan Media
4. Syarat Agar Situs Bisa Diinstal di Layar Utama
5. Perilaku PWA di iPhone dan Safari: yang Berbeda dari Android
6. Service Worker dan Strategi Caching untuk Situs Berita
7. Cara Memasang PWA di WordPress: Tiga Pilihan Plugin
8. Cara Menguji PWA: DevTools, Bukan Sekadar Lighthouse
9. PWA dan Iklan AdSense: yang Perlu Dijaga
10. Kesalahan Umum dan Risiko yang Sering Terjadi
11. Apakah Situs Anda Perlu PWA? Cara Menilai dengan Jujur
12. FAQ
13. Kesimpulan
14. Sumber resmi yang dirujuk

Apa Itu Progressive Web App (PWA)?

Progressive Web App adalah situs web yang memakai teknologi web modern untuk memberikan pengalaman menyerupai aplikasi. Istilah ini dipopulerkan Google melalui dokumentasi developer-nya: sebuah PWA tetaplah situs web biasa yang dibuka lewat browser, tetapi ditambah kemampuan instalasi, bekerja offline, dan notifikasi push. Kata "progressive" merujuk pada sifatnya yang bertahap — situs tetap berfungsi di browser lama yang tidak mendukung fitur-fitur tersebut, lalu "meningkat" di browser modern.

Bagi pembaca situs berita, perbedaannya terasa konkret. Situs biasa mengharuskan pembaca membuka browser, mengetik alamat atau mencari di Google, lalu menunggu halaman dimuat. Situs yang sudah menjadi PWA bisa dipasang sebagai ikon di layar utama ponsel, dibuka dengan satu ketukan seperti aplikasi, tampil tanpa bilah alamat browser (mode standalone), dan tetap menampilkan artikel yang sudah pernah dibuka meski koneksi sedang putus. Semua itu terjadi tanpa proses persetujuan toko aplikasi, tanpa biaya pendaftaran developer, dan tanpa memaksa pembaca mengunduh file puluhan megabyte.

Penting untuk meluruskan satu hal sejak awal: PWA bukan aplikasi native. Ia tidak diinstal dari Google Play atau App Store, tidak ditulis dalam bahasa pemrograman native seperti Kotlin atau Swift, dan kemampuannya tetap dibatasi oleh apa yang diizinkan browser. Di sisi lain, justru di situlah kelebihannya bagi publisher kecil: satu basis kode web yang sama melayani pembaca desktop, Android, dan iPhone, tanpa tim pengembang aplikasi terpisah dan tanpa biaya pemeliharaan dua platform.

Untuk media kecil di Indonesia, konteks ini relevan. Banyak pembaca mengakses berita dari ponsel Android kelas menengah dengan penyimpanan yang terbatas dan koneksi yang tidak selalu stabil. Meminta mereka menginstal aplikasi native berukuran besar sering kali gagal — ponsel penuh, kuota habis, atau sekadar enggan. PWA yang ringan, yang hanya "memasang" pintasan beserta cache, menurunkan hambatan itu secara drastis. Pembaca tidak perlu membuat keputusan besar; mereka cukup mengetuk "Tambah ke Layar Utama" dan situs Anda sudah tinggal selangkah dari jari mereka setiap hari.

Namun PWA juga bukan solusi ajaib. Ia tidak membuat konten yang buruk menjadi bagus, tidak menggantikan kebutuhan akan kecepatan dasar situs, dan tidak otomatis menaikkan ranking Google. Publisher yang memasang PWA dengan harapan traffic melonjak semalam akan kecewa. Publisher yang memasangnya untuk membuat pembaca setia lebih mudah kembali — dan mengukur hasilnya dari kunjungan ulang, bukan dari sekadar jumlah instalasi — akan mendapatkan manfaat yang nyata.

Tiga Fondasi PWA: HTTPS, Manifest, dan Service Worker

Sebuah PWA berdiri di atas tiga teknologi yang saling melengkapi. Memahami ketiganya membantu Anda mendiagnosis masalah saat PWA tidak berfungsi, alih-alih sekadar mencoba-coba pengaturan plugin.

1. HTTPS: syarat yang tidak bisa ditawar

Service worker dan sebagian besar API PWA hanya berjalan dalam konteks aman (secure context). Artinya situs harus disajikan melalui HTTPS. Alasannya bersifat keamanan: service worker bisa mencegat dan mengubah permintaan jaringan, sehingga browser hanya mengizinkannya pada koneksi terenkripsi. Pengecualian hanya berlaku untuk pengembangan lokal — alamat localhost dianggap aman untuk pengujian.

Kabar baiknya, sebagian besar situs WordPress saat ini sudah memakai HTTPS berkat sertifikat gratis seperti Let's Encrypt yang disediakan banyak hosting, termasuk Hostinger. Jika situs Anda masih memakai HTTP, perbaiki dulu hal ini sebelum memikirkan PWA — dan sebenarnya sebelum memikirkan SEO secara umum, karena Chrome menandai HTTP sebagai "Tidak Aman" dan banyak fitur web modern tidak akan berfungsi.

2. Web app manifest: kartu identitas aplikasi

Web app manifest adalah file JSON kecil — biasanya bernama manifest.json atau manifest.webmanifest — yang memberi tahu browser bagaimana situs Anda harus tampil saat diinstal. Isinya antara lain nama aplikasi (name dan short_name), ikon dalam berbagai ukuran, warna tema (theme_color), warna latar saat aplikasi dibuka (background_color), URL awal saat ikon diketuk (start_url), dan mode tampilan (display).

Mode tampilan inilah yang membuat PWA terasa seperti aplikasi. Nilai standalone menghilangkan bilah alamat dan antarmuka browser sehingga situs tampil memenuhi layar seperti aplikasi biasa. Nilai fullscreen menyembunyikan bahkan bilah status sistem. Nilai minimal-ui mempertahankan sebagian kecil kontrol browser, dan window-controls-overlay dipakai untuk aplikasi desktop yang ingin memakai area bilah judul. Untuk situs berita, standalone adalah pilihan yang paling umum dan paling aman.

Manifest harus ditautkan dari setiap halaman melalui tag <link rel="manifest" href="..."> di dalam <head>. Di WordPress, plugin PWA akan menambahkan tautan ini secara otomatis — Anda tidak perlu mengedit tema secara manual. Satu hal yang sering terlupa: ikon. Chrome mensyaratkan ikon berukuran minimal 192 piksel dan 512 piksel agar situs bisa diinstal. Siapkan ikon persegi berkualitas baik dengan latar yang tidak transparan, karena ikon berlatar transparan bisa tampil aneh di layar utama sebagian ponsel.

3. Service worker: pekerja di balik layar

Service worker adalah skrip JavaScript yang berjalan di thread terpisah dari halaman web, di latar belakang browser. Ia bisa mencegat permintaan jaringan (fetch), menjawabnya dari cache, menerima pesan push dari server, dan menjalankan sinkronisasi latar belakang. Tanpa service worker, situs Anda bisa diinstal (di Chrome saat ini) tetapi tidak bisa bekerja offline dan tidak bisa menerima push.

Siklus hidup service worker terdiri dari tiga tahap: install, activate, dan fetch. Saat pertama kali didaftarkan, service worker masuk tahap install dan biasanya mengunduh aset-aset penting ke cache (misalnya logo, stylesheet, dan halaman offline). Setelah aktif, ia mencegat setiap permintaan dalam cakupannya (scope) dan memutuskan: jawab dari cache, ambil dari jaringan, atau gabungan keduanya. Keputusan inilah yang disebut strategi caching, dan akan dibahas tersendiri karena dampaknya besar untuk situs berita.

Satu aturan penting yang sering menimbulkan kebingungan: hanya satu service worker yang boleh aktif dalam satu waktu untuk satu cakupan (scope). Jika dua plugin sama-sama mencoba mendaftarkan service worker di root situs, hanya satu yang menang, dan yang kalah bisa menimbulkan error atau perilaku aneh. Inilah alasan teknis mengapa Anda tidak boleh memasang dua plugin PWA sekaligus.

Mengapa PWA Relevan untuk Situs Berita dan Media

Alasan sebuah situs berita mempertimbangkan PWA berbeda dengan alasan toko online atau aplikasi produktivitas. Berita adalah produk kunjungan ulang: nilainya terletak pada pembaca yang kembali setiap hari, bukan pada satu kunjungan dari pencarian. PWA menyasar tepat pada kebiasaan itu.

Ikon di layar utama menurunkan hambatan kembali

Setiap langkah tambahan antara niat membaca dan halaman berita adalah peluang pembaca batal. Membuka browser, mengetik alamat, menunggu hasil pencarian — semuanya adalah gesekan. Ikon di layar utama memangkas gesekan itu menjadi satu ketukan. Bagi media kecil yang belum dikenal luas, ini adalah cara murah untuk "menetap" di ponsel pembaca tanpa bersaing memperebutkan ruang di toko aplikasi.

Pembacaan offline untuk artikel yang sudah dimuat

Service worker dapat menyimpan artikel yang sudah dibaca ke cache. Ketika pembaca kehilangan sinyal — di perjalanan, di daerah dengan sinyal lemah, atau saat kuota habis — artikel tersebut tetap bisa dibuka. Untuk media, ini bukan sekadar fitur teknis; ini soal keandalan. Pembaca yang tahu situs Anda tetap bisa dibuka saat sinyal buruk akan lebih percaya untuk kembali.

Perlu dicatat batasannya: yang bisa dibaca offline hanyalah konten yang sudah pernah dimuat dan sengaja di-cache. PWA tidak bisa mengunduh seluruh arsip situs Anda secara otomatis, dan tidak seharusnya mencoba — cache yang terlalu besar justru memperlambat dan memakan penyimpanan ponsel pembaca. Strategi yang wajar adalah meng-cache halaman yang baru dikunjungi dan aset statis, bukan seluruh situs.

Notifikasi push untuk berita penting

Web push memungkinkan situs mengirim notifikasi ke pembaca yang sudah memberi izin, bahkan saat browser tidak sedang dibuka. Untuk media, ini adalah saluran distribusi yang berharga: berita besar, hasil pertandingan, atau artikel terbaru bisa langsung sampai ke layar kunci pembaca. Namun push adalah pedang bermata dua. Notifikasi yang terlalu sering atau tidak relevan akan membuat pembaca mencabut izin — dan izin yang dicabut jauh lebih sulit didapatkan kembali daripada izin yang belum pernah diminta. Aturan praktisnya: minta izin hanya setelah pembaca menunjukkan ketertarikan (misalnya setelah membaca beberapa artikel), dan kirim push hanya untuk hal yang benar-benar layak mengganggu.

Biaya jauh lebih rendah daripada aplikasi native

Membangun aplikasi native berarti dua basis kode (Android dan iOS), proses review toko aplikasi, biaya akun developer tahunan, dan pemeliharaan terpisah setiap kali ada perubahan. PWA memakai basis kode web yang sudah Anda miliki: artikel, tema, dan plugin WordPress yang sama. Untuk publisher kecil dengan tim satu atau dua orang, perbedaan biaya ini sering kali menjadi penentu apakah ide "aplikasi" bisa diwujudkan atau tidak.

Batasan yang perlu diakui

PWA bukan tanpa kelemahan. Di iPhone, dukungan fitur PWA secara historis lebih terbatas dibanding Android — misalnya web push untuk aplikasi web di layar utama baru tersedia sejak iOS 16.4, dan beberapa kemampuan masih berbeda perilakunya. PWA juga tidak bisa mengakses semua fitur perangkat seperti aplikasi native (misalnya akses mendalam ke Bluetooth atau sensor tertentu). Dan yang terpenting bagi publisher: PWA tidak menggantikan distribusi. Ikon di layar utama hanya berguna jika pembaca sudah menemukan situs Anda; PWA tidak membuat situs yang tidak dikenal tiba-tiba ditemukan orang.

Syarat Agar Situs Bisa Diinstal di Layar Utama

Agar Chrome menawarkan instalasi, situs harus memenuhi kriteria yang didokumentasikan Google di web.dev. Kriteria ini berubah dari waktu ke waktu, jadi patokan di bawah ini mengikuti kondisi terbaru yang terdokumentasi — bukan tutorial lama yang masih menyebut service worker sebagai syarat mutlak.

Kriteria instalasi Chrome saat ini

Chrome menampilkan perintah instalasi (dan memicu event beforeinstallprompt yang bisa dipakai untuk menampilkan tombol instalasi sendiri) bila semua kondisi berikut terpenuhi:

• Situs belum diinstal oleh pengguna tersebut.
• Pengguna sudah berinteraksi dengan halaman — misalnya mengetuk atau mengklik setidaknya sekali — dan sudah menghabiskan sejumlah waktu di halaman (patokan yang didokumentasikan adalah interaksi plus waktu tampilan, umumnya sekitar 30 detik dalam riwayat interaksi).
• Halaman disajikan melalui HTTPS.
• Manifest memiliki name atau short_name, ikon 192 piksel dan 512 piksel, start_url, dan display yang bernilai fullscreen, standalone, minimal-ui, atau window-controls-overlay.
• prefer_related_applications tidak ada atau bernilai false — artinya Anda tidak sedang mengarahkan pengguna ke aplikasi native di toko aplikasi sebagai preferensi.
• Untuk perintah instalasi otomatis dari Chrome, masih ada pemeriksaan service worker dengan fetch handler. Namun instalasi melalui menu browser tetap dimungkinkan tanpa service worker sejak Chrome 108 di Android dan Chrome 112 di desktop; dalam kasus itu Chrome menampilkan halaman offline bawaannya sendiri bila pengguna membuka aplikasi tanpa koneksi.

Perubahan ini penting karena banyak tutorial lama masih menulis bahwa service worker adalah syarat instalasi. Pernyataan itu sudah tidak akurat untuk Chrome modern. Yang tetap akurat: tanpa service worker, PWA Anda tidak memiliki kemampuan offline dan push — dua fitur yang menjadi alasan utama membangun PWA. Jadi secara praktis, anggaplah service worker tetap wajib, meski secara teknis bukan syarat instalasi.

Menyiapkan manifest yang benar

Kesalahan manifest adalah penyebab paling umum mengapa Chrome tidak menawarkan instalasi. Periksa hal-hal berikut:

• Nama: isi name (nama lengkap, misalnya "Bangeko Media") dan short_name (nama pendek untuk layar utama, misalnya "Bangeko"). Nama pendek yang terlalu panjang akan terpotong di layar utama ponsel.
• Ikon: sediakan ikon 192×192 dan 512×512 dalam format PNG. Ikon 512 piksel juga dipakai sebagai ikon maskable — ikon yang bisa dipotong mengikuti bentuk yang ditentukan sistem (lingkaran, squircle) — jadi pastikan elemen penting logo tidak menempel di tepi.
• start_url: arahkan ke halaman yang masuk akal sebagai titik awal, biasanya beranda (/). Tambahkan parameter penanda seperti ?utm_source=pwa hanya bila Anda memang ingin membedakan traffic dari PWA di analitik — dan pastikan parameter itu tidak merusak cache atau membuat URL beranda terduplikasi di mata mesin pencari.
• display: gunakan standalone untuk situs berita.
• theme_color dan background_color: samakan dengan warna utama tema Anda agar transisi saat aplikasi dibuka terlihat mulus, bukan berkedip dari warna putih ke warna tema.

Kapan perintah instalasi muncul

Chrome tidak menampilkan perintah instalasi pada kunjungan pertama yang singkat. Ada unsur engagement: pengguna harus sudah berinteraksi dan menghabiskan waktu di situs. Ini disengaja — Google tidak ingin setiap situs yang dikunjungi sekali langsung meminta diinstal. Bagi publisher, implikasinya adalah: jangan berharap tombol instal muncul untuk pembaca yang baru datang dari Google dan langsung pergi. Perintah itu muncul untuk pembaca yang sudah mulai betah. Anda juga bisa menyediakan tombol "Instal Aplikasi" sendiri di situs yang memicu event beforeinstallprompt yang tersimpan — tetapi tombol itu hanya berfungsi bila kriteria sudah terpenuhi, dan menampilkannya terlalu dini hanya akan membuat tombol yang tidak berfungsi.

Perilaku PWA di iPhone dan Safari: yang Berbeda dari Android

Jika sebagian besar pembaca Anda memakai iPhone, ada beberapa perbedaan yang wajib diketahui sebelum menjanjikan pengalaman PWA yang sama seperti di Android.

Di iOS, tidak ada perintah instalasi otomatis seperti di Chrome Android. Pengguna iPhone memasang PWA secara manual melalui menu Bagikan (Share) lalu "Tambah ke Layar Utama" (Add to Home Screen). Sejak iOS/iPadOS 26, situs apa pun yang ditambahkan ke layar utama akan terbuka sebagai aplikasi web secara default, dengan atau tanpa manifest — tetapi manifest tetap menentukan nama, ikon, dan mode tampilan yang dipakai.

Web push untuk aplikasi web di layar utama iPhone baru tersedia sejak iOS 16.4, dan pengguna harus sudah menambahkan situs ke layar utama terlebih dahulu sebelum bisa memberi izin notifikasi. Safari 18.4 menambahkan Declarative Web Push, yang memungkinkan notifikasi ditampilkan tanpa service worker untuk kasus tertentu. Meski begitu, dukungan push di iOS tetap lebih terbatas dibanding Android, dan publisher sebaiknya tidak menjadikan push iOS sebagai andalan utama strategi distribusi.

Satu perbedaan praktis lain: penyimpanan cache dan data PWA di iOS lebih agresif dibersihkan oleh sistem dibanding Android. Artinya artikel yang di-cache untuk dibaca offline bisa hilang lebih cepat bila pengguna lama tidak membuka aplikasi web tersebut. Ini bukan alasan untuk tidak memakai PWA, tetapi alasan untuk tidak menjanjikan "baca offline selamanya" kepada pembaca iPhone.

Kesimpulan praktisnya: uji PWA Anda di perangkat Android dan iPhone secara terpisah. Pengalaman yang mulus di Chrome Android belum tentu sama di Safari iPhone, dan sebaliknya.

Service Worker dan Strategi Caching untuk Situs Berita

Service worker memutuskan apa yang terjadi saat pembaca meminta sebuah halaman. Keputusan itu disebut strategi caching, dan memilih strategi yang salah adalah sumber sebagian besar masalah PWA di situs berita.

Empat strategi caching yang umum

Google Workbox — pustaka yang dipakai banyak plugin PWA WordPress — menyediakan strategi-strategi baku berikut:

• Cache First (cache dulu, jaringan sebagai cadangan): cocok untuk aset yang jarang berubah — logo, font, stylesheet, dan skrip. Pembaca mendapatkan aset dari cache secara instan; jaringan hanya dipakai bila aset belum ada di cache. Jangan memakai strategi ini untuk artikel, karena pembaca bisa mendapatkan artikel basi.
• Network First (jaringan dulu, cache sebagai cadangan): cocok untuk artikel dan halaman dinamis. Service worker mencoba jaringan terlebih dahulu; bila gagal (offline), ia menjawab dari cache. Ini adalah strategi default yang paling aman untuk konten berita.
• Stale While Revalidate (cache dulu, perbarui di latar belakang): menjawab dari cache secara instan, lalu memperbarui cache dari jaringan di latar belakang untuk kunjungan berikutnya. Cocok untuk aset yang boleh sedikit basi, misalnya gambar artikel atau data yang tidak kritis.
• Network Only (hanya jaringan): tidak ada caching sama sekali. Wajib untuk halaman yang tidak boleh di-cache: halaman admin WordPress (/wp-admin/), halaman login, endpoint AJAX, dan — yang paling penting bagi publisher — skrip dan permintaan iklan.

Aturan caching khusus situs berita

Situs berita berbeda dari situs statis karena kontennya berubah setiap jam dan sebagian halamannya tidak boleh basi. Pegang aturan berikut:

1. Artikel memakai Network First. Pembaca harus mendapatkan versi terbaru artikel, termasuk koreksi dan pembaruan. Cache hanya sebagai cadangan saat offline, bukan sebagai sumber utama.
2. Aset statis memakai Cache First. Logo, CSS, dan font jarang berubah; menyajikannya dari cache mempercepat kunjungan ulang secara nyata.
3. Jangan cache halaman admin, login, dan keranjang/checkout. Untuk situs WordPress, pastikan service worker mengecualikan /wp-admin/, /wp-login.php, dan endpoint REST API yang dipakai editor. Plugin PWA yang baik sudah menangani pengecualian ini secara bawaan, tetapi verifikasi sendiri setelah instalasi.
4. Batasi ukuran dan umur cache. Tetapkan batas jumlah entri dan masa berlaku cache artikel (misalnya 30 hari) agar penyimpanan ponsel pembaca tidak membengkak. Workbox mendukung pembatasan ini lewat plugin expiration.
5. Sediakan halaman offline. Buat satu halaman offline sederhana — "Anda sedang offline. Artikel yang sudah Anda buka sebelumnya tetap bisa dibaca." — yang ditampilkan saat service worker tidak menemukan konten di cache maupun jaringan. Halaman ini jauh lebih baik daripada halaman error bawaan browser.

Satu contoh yang menggambarkan risikonya

Bayangkan service worker Anda memakai Cache First untuk semua halaman. Anda menerbitkan koreksi penting pada sebuah artikel — misalnya angka yang salah dalam berita keuangan. Pembaca yang sudah pernah membuka artikel itu akan terus melihat versi lama dari cache, tanpa tahu ada koreksi. Mereka membagikan angka yang salah, dan Anda tidak punya cara mudah untuk menarik kembali cache di perangkat mereka. Inilah mengapa strategi caching bukan detail teknis semata, melainkan keputusan editorial. Network First untuk artikel adalah pilihan yang membosankan tetapi benar.

Cara Memasang PWA di WordPress: Tiga Pilihan Plugin

Ada tiga jalur yang umum dipakai publisher WordPress. Semuanya tersedia di repositori WordPress.org. Pilih satu — jangan memasang dua sekaligus, karena hanya satu service worker yang boleh aktif.

Opsi 1: Plugin "PWA" (plugin fitur WordPress.org)

Plugin bernama PWA di WordPress.org dikembangkan sebagai feature plugin — tempat mengimplementasikan dukungan PWA di WordPress dengan tujuan suatu saat digabungkan ke inti WordPress, sedikit demi sedikit. Plugin ini menyediakan blok bangunan: service worker, web app manifest, dan dukungan HTTPS. Pendekatannya lebih modular: plugin ini dimaksudkan sebagai fondasi agar tema dan plugin lain tidak perlu membuat service worker sendiri-sendiri dan saling bertabrakan.

Plugin ini cocok untuk publisher yang ingin fondasi yang bersih dan tidak keberatan bahwa sebagian fitur lanjutan (misalnya push notification) perlu ditambahkan lewat plugin lain. Perilaku bawaannya: menyajikan template offline saat koneksi terputus atau server mengembalikan error 500. Kekurangannya, dokumentasi dan pengaturannya lebih teknis dibanding plugin PWA yang berorientasi pengguna akhir.

Opsi 2: PWA for WP (Magazine3)

PWA for WP adalah plugin PWA WordPress yang paling banyak dipakai, dengan fokus pada kemudahan: service worker terpasang otomatis di latar belakang, mendukung AMP, dan terintegrasi dengan OneSignal untuk push notification. Versi terbarunya (1.7.86, Mei 2026) membawa perbaikan seputar service worker dan kompatibilitas. Plugin ini menyediakan panel pengaturan untuk nama aplikasi, ikon, warna, splash screen, dan halaman offline tanpa perlu menulis kode.

PWA for WP cocok untuk publisher yang ingin hasil cepat: instal, isi pengaturan dasar, dan situs sudah bisa diinstal. Versi gratisnya sudah mencakup kebutuhan dasar; fitur seperti Call to Action, analitik instalasi, dan konversi PWA ke APK tersedia di ekstensi berbayar. Perlu dicatat: karena plugin ini memakai service worker buatannya sendiri, jangan menggabungkannya dengan plugin PWA lain.

Opsi 3: Swift PWA

Swift PWA adalah plugin yang lebih baru dan memakai Workbox 7.0.0 dari Google untuk service worker dan strategi cachingnya. Fitur yang ditonjolkan antara lain service worker lanjutan dengan manajemen cache dan keamanan tingkat enterprise. Plugin ini juga mengingatkan bila situs belum memakai HTTPS.

Swift PWA cocok bila Anda menginginkan kontrol caching yang lebih halus berbasis Workbox dan tidak keberatan memakai plugin yang komunitasnya lebih kecil dibanding PWA for WP. Seperti biasa, uji di staging sebelum memasang di situs live, dan pastikan hanya satu plugin PWA yang aktif.

Langkah pemasangan (contoh dengan PWA for WP)

1. Cadangkan situs terlebih dahulu. Ini aturan umum sebelum memasang plugin apa pun yang menyentuh service worker dan caching. Backup memastikan Anda bisa kembali bila terjadi sesuatu.
2. Pasang dan aktifkan satu plugin PWA saja. Lewat menu Plugin → Tambah Baru, cari nama plugin, instal, dan aktifkan.
3. Isi identitas aplikasi. Nama aplikasi, nama pendek, deskripsi, ikon 192×192 dan 512×512, warna tema, warna latar, dan mode tampilan (standalone).
4. Atur halaman offline. Buat atau pilih halaman yang ditampilkan saat pengguna offline. Isi dengan pesan yang membantu dan tautan ke halaman utama.
5. Periksa pengecualian caching. Pastikan /wp-admin/, /wp-login.php, dan endpoint yang dipakai editor tidak di-cache. Bila plugin menyediakan pengaturan pengecualian, isi dengan jalur-jalur tersebut.
6. Simpan dan bersihkan cache. Setelah menyimpan pengaturan, bersihkan cache plugin caching Anda (bila ada) agar service worker baru segera terdaftar.
7. Uji di perangkat nyata. Buka situs di Chrome Android dan Safari iPhone, periksa apakah perintah instalasi muncul, dan uji mode offline dengan mengaktifkan mode pesawat setelah membuka beberapa artikel.
8. Pantau selama seminggu. Perhatikan laporan error di Search Console dan keluhan pembaca. Service worker yang bermasalah biasanya menunjukkan gejala dalam beberapa hari pertama: halaman tidak terbarui, gambar tidak muncul, atau login admin bermasalah.

Cara Menguji PWA: DevTools, Bukan Sekadar Lighthouse

Banyak tutorial lama menyuruh menjalankan audit PWA di Lighthouse. Informasi ini sudah kedaluwarsa: Lighthouse 12 menghapus kategori PWA pada 2024, mengikuti perubahan kriteria instalasi Chrome. Cara yang benar saat ini adalah memakai panel Application di Chrome DevTools.

Buka situs Anda di Chrome, tekan F12, lalu masuk ke tab Application. Di sana Anda bisa melihat manifest yang terurai (parsed manifest) beserta masalah instalabilitasnya, service worker yang terdaftar dan statusnya, serta isi setiap cache yang dibuat service worker. Bila ada masalah pada manifest — misalnya ikon 512 piksel hilang — DevTools akan menunjukkannya secara eksplisit.

Selain DevTools, lakukan pengujian manual berikut:

• Uji instalasi. Di Chrome Android, buka menu dan cari opsi "Instal aplikasi" atau "Tambah ke Layar Utama". Pastikan ikon terpasang dengan nama dan ikon yang benar.
• Uji offline. Buka tiga artikel, lalu aktifkan mode pesawat dan buka kembali ketiganya. Artikel yang sudah dimuat harus tetap bisa dibaca; artikel yang belum pernah dibuka harus menampilkan halaman offline Anda, bukan error browser.
• Uji pembaruan. Ubah satu kalimat dalam artikel yang sudah di-cache, terbitkan, lalu buka kembali artikel itu di perangkat yang sama. Perubahan harus terlihat — bila tidak, strategi caching Anda kemungkinan memakai Cache First untuk artikel.
• Uji di iPhone. Tambahkan situs ke layar utama dari Safari, buka sebagai aplikasi web, dan periksa tampilan serta perilaku offlinenya.
• Periksa Search Console. Setelah PWA aktif, pantau laporan error perayapan. Service worker tidak memengaruhi perayapan Google secara langsung — Googlebot tidak menginstal PWA — tetapi kesalahan konfigurasi yang membuat halaman tidak termuat tetap akan terlihat di laporan.

PWA dan Iklan AdSense: yang Perlu Dijaga

Bagi publisher yang pendapatannya berasal dari AdSense, ada beberapa hal yang harus dijaga agar PWA tidak merusak pendapatan iklan.

Pertama, jangan cache skrip dan permintaan iklan. Iklan AdSense dimuat dari server Google dan bersifat dinamis: iklan yang tampil bergantung pada lelang real-time, penargetan, dan frekuensi. Menyimpan respons iklan di cache akan menampilkan iklan basi, merusak pelaporan, dan berpotensi melanggar kebijakan. Pastikan service worker Anda mengecualikan domain dan jalur iklan (misalnya googlesyndication.com, googleads.g.doubleclick.net, dan skrip adsbygoogle.js) dari semua strategi caching. Plugin PWA yang baik sudah mengecualikan permintaan lintas domain tertentu secara bawaan, tetapi verifikasi sendiri melalui DevTools: muat halaman, periksa cache, dan pastikan tidak ada respons iklan yang tersimpan.

Kedua, perhatikan tampilan iklan dalam mode standalone. Saat situs dibuka sebagai aplikasi terinstal, ruang layar dan perilaku scroll sedikit berbeda dari browser. Periksa apakah unit iklan — terutama anchor ads dan vignette — tetap tampil dengan benar dan tidak menutupi konten. Uji di perangkat nyata, bukan hanya emulator.

Ketiga, jangan menganggap PWA menaikkan CPC atau RPM secara otomatis. Ada klaim yang beredar bahwa PWA meningkatkan pendapatan iklan karena pembaca lebih sering kembali. Kunjungan ulang memang bisa meningkatkan tayangan iklan, tetapi tidak ada jaminan angka. Peningkatan yang terjadi berasal dari perilaku pembaca, bukan dari PWA itu sendiri. Jangan menulis klaim pendapatan dalam laporan atau promosi tanpa data Anda sendiri.

Keempat, waspadai interaksi dengan plugin caching dan optimasi. Publisher WordPress sering memakai plugin caching (misalnya WP Rocket atau LiteSpeed Cache) bersamaan dengan PWA. Kedua lapisan cache ini bisa saling bertabrakan: plugin caching menyimpan halaman HTML di server, service worker menyimpan halaman di perangkat. Bila keduanya tidak selaras, pembaca bisa menerima halaman yang sudah kedaluwarsa dari dua arah. Setelah memasang PWA, bersihkan semua lapisan cache dan uji kembali halaman utama serta satu artikel.

Kelima, perhatikan kebijakan AdSense tentang konten. PWA tidak mengubah kebijakan konten AdSense sedikit pun. Situs yang melanggar kebijakan — konten hasil salinan massal, konten menyesatkan, atau konten yang dibuat semata-mata untuk mesin pencari — tetap berisiko, dengan atau tanpa PWA. PWA adalah lapisan pengalaman pengguna, bukan tameng kebijakan.

Kesalahan Umum dan Risiko yang Sering Terjadi

Memasang dua plugin PWA sekaligus

Ini kesalahan paling umum dan paling merusak. Dua service worker berebut satu scope; hasilnya bisa berupa service worker yang tidak pernah aktif, cache yang saling menimpa, atau halaman yang tidak bisa dimuat. Solusinya sederhana: pilih satu plugin, nonaktifkan dan hapus yang lain, lalu hapus pendaftaran service worker lama melalui DevTools (Application → Service Workers → Unregister) dan bersihkan cache sebelum menguji ulang.

Meng-cache semua halaman dengan Cache First

Seperti dijelaskan di atas, Cache First untuk artikel membuat koreksi tidak pernah sampai ke pembaca. Gunakan Network First untuk artikel dan halaman dinamis.

Lupa memperbarui service worker setelah mengubah situs

Service worker memiliki siklus hidup dan tidak selalu memperbarui dirinya sendiri secepat yang Anda kira. Setelah mengubah konfigurasi PWA atau mengganti plugin, paksa pembaruan dengan menaikkan versi service worker (plugin biasanya melakukannya otomatis) dan minta pengunjung memuat ulang halaman. Selama pengujian, gunakan opsi "Update on reload" di DevTools agar setiap muat ulang memakai service worker terbaru.

Meminta izin push terlalu dini

Meminta izin notifikasi pada detik pertama kunjungan adalah cara tercepat membuat pembaca menekan "Blokir". Tunggu sampai pembaca menunjukkan ketertarikan — misalnya setelah membaca dua atau tiga artikel — lalu jelaskan manfaatnya ("Dapatkan berita terbaru langsung di ponsel Anda") sebelum menampilkan permintaan izin browser.

Mengabaikan iPhone

Menguji PWA hanya di Android lalu menganggap selesai adalah kesalahan. Sebagian besar pembaca di Indonesia memang memakai Android, tetapi pembaca iPhone tetap signifikan, dan perilaku PWA di Safari berbeda. Alokasikan waktu pengujian untuk keduanya.

Menganggap PWA sebagai pengganti kecepatan dasar

PWA tidak memperbaiki situs yang lambat. Service worker memang mempercepat kunjungan ulang dengan menyajikan aset dari cache, tetapi kunjungan pertama — yang justru paling menentukan, karena sebagian besar pembaca datang dari pencarian — tetap bergantung pada kecepatan server, ukuran halaman, dan optimasi gambar. Perbaiki Core Web Vitals terlebih dahulu, lalu tambahkan PWA sebagai lapisan berikutnya. Artikel Core Web Vitals di situs ini membahas LCP, INP, dan CLS secara terpisah.

Apakah Situs Anda Perlu PWA? Cara Menilai dengan Jujur

Tidak semua situs berita membutuhkan PWA, dan memasangnya tanpa alasan yang jelas hanya menambah satu hal yang harus dirawat. Gunakan pertanyaan berikut untuk menilai:

• Apakah pembaca Anda kembali secara berkala? Bila sebagian besar traffic berasal dari pencarian sekali datang, PWA kurang berdampak. Bila Anda punya pembaca setia yang kembali setiap hari, PWA membantu mereka kembali dengan lebih mudah.
• Apakah Anda menerbitkan berita yang layak di-push? Push notification hanya berguna bila Anda punya konten yang memang layak mengganggu pembaca. Media yang menerbitkan satu artikel seminggu tidak membutuhkan push.
• Apakah koneksi pembaca Anda sering tidak stabil? Bila pembaca berada di daerah dengan sinyal lemah, kemampuan offline PWA bernilai nyata. Bila pembaca mayoritas memakai Wi-Fi stabil, nilainya lebih kecil.
• Apakah Anda siap merawatnya? Service worker adalah komponen yang harus dipantau: setelah update WordPress, setelah ganti tema, setelah ganti plugin caching. Bila tidak ada yang memantau, risiko halaman basi lebih besar daripada manfaatnya.
• Apakah Anda sudah menyelesaikan dasar-dasarnya? HTTPS aktif, kecepatan memadai, konten orisinal, dan navigasi rapi adalah prasyarat. PWA adalah peningkatan di atas fondasi yang sudah beres, bukan pengganti fondasi.

Bila jawaban sebagian besar pertanyaan di atas adalah "ya", PWA layak dicoba. Bila sebagian besar "tidak", tunda dulu dan fokus pada konten serta kecepatan. PWA akan tetap ada saat Anda sudah siap.

FAQ

Apakah PWA membuat situs saya muncul di Google Play atau App Store?

Tidak secara otomatis. PWA diinstal langsung dari browser, bukan dari toko aplikasi. Ada cara membungkus PWA menjadi file APK untuk Google Play (misalnya lewat Bubblewrap atau fitur PWA-to-APK pada beberapa plugin), tetapi itu langkah tambahan yang terpisah dari PWA itu sendiri, dan App Store Apple tidak menerima PWA yang dibungkus dengan cara yang sama.

Apakah PWA menaikkan ranking Google?

Tidak ada bukti bahwa PWA secara langsung menjadi faktor ranking. Google menilai konten, kecepatan, dan pengalaman halaman. PWA bisa memperbaiki pengalaman pengguna — terutama kecepatan kunjungan ulang — dan pengalaman yang lebih baik bisa berdampak tidak langsung pada metrik seperti kunjungan ulang. Tetapi memasang PWA tanpa memperbaiki konten dan kecepatan tidak akan menaikkan ranking.

Apakah saya perlu aplikasi native bila sudah punya PWA?

Tergantung kebutuhan. Bila Anda membutuhkan akses perangkat yang dalam (misalnya Bluetooth, NFC, atau sensor khusus) atau distribusi lewat toko aplikasi, aplikasi native masih diperlukan. Bila kebutuhan Anda adalah distribusi berita, pembacaan offline, dan push notification dasar, PWA sering kali sudah cukup.

Berapa biaya membuat PWA untuk situs WordPress?

Dengan plugin gratis, biaya langsungnya nol — selain waktu pemasangan dan pengujian. Biaya tidak langsungnya adalah waktu pemeliharaan dan kemungkinan ekstensi berbayar untuk fitur seperti push notification lanjutan atau analitik instalasi. Dibanding membangun aplikasi native, biayanya jauh lebih kecil.

Apakah PWA aman untuk iklan AdSense?

Ya, selama service worker tidak meng-cache skrip dan permintaan iklan. Pastikan domain iklan Google dikecualikan dari caching, dan uji tampilan iklan dalam mode standalone di perangkat nyata. PWA tidak mengubah kebijakan konten AdSense.

Mengapa Chrome tidak menampilkan perintah instalasi di situs saya?

Periksa tiga hal secara berurutan: apakah situs sudah HTTPS, apakah manifest valid dan lengkap (nama, ikon 192px dan 512px, start_url, display), dan apakah Anda sudah berinteraksi cukup lama dengan halaman. Gunakan panel Application di Chrome DevTools untuk melihat pesan kesalahan instalabilitas secara spesifik — DevTools akan menunjukkan dengan tepat syarat mana yang belum terpenuhi.

Kesimpulan

Progressive Web App adalah peningkatan yang masuk akal bagi situs berita dan media WordPress yang sudah memiliki pembaca setia: instalasi ringan tanpa toko aplikasi, pembacaan offline untuk artikel yang sudah dimuat, dan notifikasi push untuk berita yang layak mengganggu. Fondasinya hanya tiga — HTTPS, web app manifest, dan service worker — tetapi detail pelaksanaannya menentukan berhasil atau tidaknya: strategi caching yang benar untuk artikel dinamis, pengecualian untuk halaman admin dan iklan, serta pengujian di Android dan iPhone secara terpisah.

Mulailah dari yang sederhana: pasang satu plugin PWA, isi manifest dengan benar, sediakan halaman offline, dan uji instalasi serta mode offline di perangkat nyata. Pantau selama seminggu sebelum menilai hasilnya, dan ukur dari kunjungan ulang serta keluhan pembaca — bukan dari sekadar jumlah instalasi. Bila fondasi situs Anda sudah beres — konten orisinal, kecepatan memadai, HTTPS aktif — PWA adalah lapisan berikutnya yang layak dipertimbangkan. Bila fondasi itu belum beres, selesaikan dulu fondasinya; PWA akan tetap menunggu.

Sumber resmi yang dirujuk

1. Google web.dev — Learn PWA: pengantar Progressive Web Apps, service worker, dan manifest. https://web.dev/learn/pwa
2. Google web.dev — What does it take to be installable? (kriteria instalasi Chrome). https://web.dev/articles/install-criteria
3. Google web.dev — Service workers (siklus hidup install, activate, fetch). https://web.dev/learn/pwa/service-workers
4. MDN Web Docs — Progressive Web Apps. https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps
5. Google Developers — Progressive Web Apps. https://developers.google.com/web/progressive-web-apps/
6. Google Developers — Workbox (pustaka service worker dan strategi caching). https://developers.google.com/web/tools/workbox
7. WordPress.org — Plugin PWA (feature plugin: service worker, manifest, HTTPS). https://wordpress.org/plugins/pwa/
8. WordPress.org — Plugin PWA for WP (Magazine3). https://wordpress.org/plugins/pwa-for-wp/