mod_pagespeed Adalah: Cara Kerja, Status & Cara Mematikan

Setiap kali browser meminta sebuah halaman, web server pada dasarnya hanya membaca berkas dari disk lalu mengirimkannya apa adanya. HTML yang sampai ke pengunjung adalah HTML yang persis sama dengan yang ditulis developer. Di situlah letak persoalannya. Berkas itu biasanya memuat CSS yang belum diringkas, gambar yang belum dikompresi ulang, dan skrip yang dimuat terlalu awal.

Perbaikan atas hal-hal itu umumnya menuntut perubahan pada kode atau alur kerja pengembangan. Google pernah menawarkan jalan lain, dan dari situlah mod_pagespeed lahir. Singkatnya, mod pagespeed adalah modul web server yang mengambil alih pekerjaan optimasi tersebut di sisi server, tanpa satu baris pun kode website disentuh.

mod_pagespeed Adalah Modul Penulis Ulang Halaman Web

Jadi apa itu mod_pagespeed secara tepat? mod_pagespeed adalah modul web server open source (kode sumbernya terbuka dan bebas dipakai) buatan Google. Ia mencegat HTML sebelum dikirim ke browser, lalu menulis ulangnya menurut sekumpulan aturan optimasi. Aturan itu disebut filter, dan masing-masing menangani satu jenis perbaikan.

Nama resmi proyeknya adalah Google PageSpeed Module, dan sebagian penyedia hosting menyebutnya modul PageSpeed. Nama itu jarang dipakai di percakapan sehari-hari, dan orang lebih mengenalnya lewat nama modulnya langsung.

Satu hal perlu diperjelas sejak awal karena sering disalahpahami. Modul ini tidak mengubah berkas apa pun di disk. Berkas CSS, JavaScript, dan gambar Anda tetap seperti semula; yang berubah hanya keluaran yang dikirim ke browser. Mematikan modulnya langsung mengembalikan halaman ke bentuk aslinya.

Modul ini punya dua wujud yang berbagi mesin optimasi yang sama:

1. mod_pagespeed: versi untuk Apache, dirilis Google pada 2010. Ini yang paling banyak dipakai karena Apache mendominasi hosting berbasis panel.
2. ngx_pagespeed: versi untuk Nginx, menyusul pada 2013. Berbeda dengan versi Apache, modul ini harus dikompilasi bersama Nginx dan tidak bisa ditambahkan belakangan.

Keduanya bekerja pada lapisan yang sama, yaitu di dalam web server itu sendiri. Karena itu optimasinya berlaku untuk seluruh website di server tersebut, apa pun CMS atau bahasa pemrogramannya.

Bedanya dengan PageSpeed Insights yang Sering Tertukar

Dua hal ini bernama mirip dan sering dikira sama, padahal fungsinya berlawanan.

PageSpeed Insights adalah alat ukur. Ia membuka halaman Anda dari luar, mencatat waktu muat dan perilaku rendering, lalu memberi skor beserta daftar saran. Ia tidak mengubah apa pun di server Anda.

mod_pagespeed adalah alat kerja. Ia mengubah halaman dari dalam server, tetapi tidak mengukur apa pun dan tidak pernah memberi skor.

Perbedaan ini menjelaskan kejadian yang kerap membingungkan: modul sudah aktif, tetapi skor PageSpeed Insights tidak bergerak. Penilaian modern bertumpu pada pengalaman visual di sisi browser, misalnya pergeseran tata letak dan waktu elemen terbesar tampil. Modul ini bekerja di lapisan berkas dan cache, sehingga banyak perbaikannya tidak tercermin pada angka tersebut.

Nama resmi proyeknya memang PageSpeed Module, dan Google memakai merek "PageSpeed" untuk keduanya. Kesamaan nama ini bukan kesalahan Anda.

Cara Kerja mod_pagespeed dari HTML Mentah ke Versi Ringan

Alurnya lebih sederhana daripada yang dibayangkan. Di Apache, modul dipasang sebagai output filter (penyaring keluaran) lewat satu baris konfigurasi:

AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER text/html

Baris itu memerintahkan Apache menyerahkan setiap keluaran bertipe HTML kepada modul sebelum dikirim. Sejak titik itu prosesnya berjalan empat tahap. Modul mengurai HTML, menerapkan filter yang aktif, menyimpan hasilnya ke cache berkas, lalu menyajikan versi yang sudah diringkas.

Sumber daya hasil olahan diberi nama baru bertanda .pagespeed., misalnya style.css.pagespeed.cf.7Jd2x1kLmQ.css. Potongan acak di dalamnya adalah sidik jari isi berkas. Begitu isinya berubah, namanya ikut berubah, sehingga browser mengambil versi baru tanpa menunggu masa cache habis.

Sejak versi 1.9.32.1, modul juga mengaktifkan In-Place Resource Optimization atau IPRO (optimasi di tempat) secara bawaan. Dengan IPRO, sumber daya yang diminta memakai URL aslinya tetap dioptimasi. Ini penting untuk gambar yang dimuat lewat JavaScript, karena URL semacam itu tidak pernah muncul di HTML.

Hasil olahan disimpan dalam cache di disk. Karena itu permintaan pertama setelah modul dipasang akan terasa lebih lambat, bukan lebih cepat. Manfaatnya baru muncul setelah cache terisi.

Filter mod_pagespeed: 29 Menyala dari 92 yang Tersedia

Perilaku modul sepenuhnya ditentukan oleh filter mana yang aktif. Di dalam kode sumbernya terdaftar 92 filter, tetapi tidak semuanya menyala bersamaan. Yang menentukan adalah rewrite level (tingkat penulisan ulang), dan nilai bawaannya adalah CoreFilters yang berisi 29 filter.

Berikut empat nilai yang paling relevan untuk dipakai:

1. PassThrough: tidak ada filter yang aktif. Berguna sebagai titik awal ketika Anda ingin menyalakan filter satu per satu.
2. OptimizeForBandwidth: 14 filter yang seluruhnya tidak mengubah URL sama sekali. Isinya kompresi ulang gambar, konversi format, dan minifikasi CSS serta JavaScript. Ini pilihan paling aman.
3. CoreFilters: 29 filter, nilai bawaan. Selain pekerjaan di atas, tingkat ini juga menggabungkan berkas CSS, menggabungkan JavaScript, menyisipkan sumber daya kecil ke dalam HTML, dan memperpanjang masa cache.
4. TestingCoreFilters dan AllFilters: untuk pengujian, bukan untuk server produksi.

Beberapa filter yang paling terasa dampaknya sudah ada di tingkat bawaan. recompress_jpeg dan recompress_png mengompresi ulang gambar, sementara convert_jpeg_to_webp mengubahnya ke format yang lebih ringan. Untuk berkas teks, rewrite_css dan rewrite_javascript meringkas isinya, dan extend_cache memperpanjang masa simpannya di browser.

Menyalakan atau mematikan filter tertentu dilakukan lewat dua direktif:

ModPagespeedRewriteLevel OptimizeForBandwidth
ModPagespeedEnableFilters collapse_whitespace
ModPagespeedEnableFilters remove_comments
ModPagespeedDisableFilters rewrite_images

Perlu diperhatikan, beberapa filter yang sering disebut sebagai keunggulan modul ini justru tidak aktif secara bawaan. lazyload_images, defer_javascript, prioritize_critical_css, dan insert_image_dimensions semuanya berada di luar CoreFilters dan harus dinyalakan sendiri. Filter terakhir menarik untuk diketahui karena menambahkan atribut lebar dan tinggi pada gambar, yang berkaitan langsung dengan CLS atau pergeseran tata letak.

Status Proyek mod_pagespeed: Pensiun 2023, Diarsipkan 2025

Urutan berikut menentukan apakah modul ini masih pantas Anda pasang hari ini, dan seluruhnya bisa Anda periksa di catatan resmi Apache serta repositori GitHub-nya.

Halaman status resmi Apache menuliskannya tanpa basa-basi: "The PageSpeed podling retired on 2023-03-17." Di dalam repositorinya kini terdapat berkas RETIRED.txt, dan seluruh kode sudah tidak menerima perubahan sejak April 2023.

Meski begitu, modul ini belum hilang dari peredaran. Data BuiltWith per Mei 2026 mencatat sekitar 231 ribu situs masih menjalankannya, karena modul yang sudah terpasang akan terus bekerja selama servernya tidak dibangun ulang.

Siapa yang Melanjutkan Setelah Google Melepas

Penghentian di sisi Apache bukan akhir cerita. Perusahaan Belanda bernama We-Amp B.V., yang sejak era Google sudah menjadi kontributor utama ngx_pagespeed, melanjutkan pengembangannya di repositori sendiri. Repositori tersebut berlisensi Apache-2.0, masih menerima commit pada Juli 2026, dan belum diarsipkan.

Perlu disampaikan terus terang: ini pihak ketiga komersial, bukan Google dan bukan Apache Software Foundation. Mereka menyalurkan paket siap pasang lewat repositori sendiri, termasuk paket untuk EasyApache 4.

Ada satu penanda menarik yang bisa Anda uji dalam hitungan detik. Alamat dokumentasi lama Google kini mengalihkan pengunjung ke situs pihak ketiga tersebut:

H=developers.google.com
P=/speed/pagespeed/module/configuration
curl -sI "https://$H$P" | grep -i location

Perintah itu mengembalikan location: https://modpagespeed.com/doc/configuration. Dengan kata lain, dokumentasi resminya sendiri sudah tidak lagi berada di tangan Google.

Satu hal lagi yang sering luput. Daftar modul Apache resmi di EasyApache 4 tidak memuat mod_pagespeed sama sekali. Kalau modul ini ada di server cPanel Anda, ia pasti datang dari repositori di luar cPanel. Ini penting diketahui sebelum melakukan pembaruan besar sistem operasi, karena paket dari luar kerap menahan proses tersebut.

Memastikan mod_pagespeed Aktif Lewat Header dan URL

Ada tiga cara memeriksa, berurutan dari yang paling cepat.

Pertama, lihat header responsnya. Apache menyuntikkan header X-Mod-Pagespeed, sedangkan Nginx menyuntikkan X-Page-Speed. Isinya nomor versi modul dengan format [Major].[Minor].[Branch].[Point]-[Commit].

curl -sI https://contoh.co.id | grep -i speed

Kalau modul aktif, keluarannya menyerupai X-Mod-Pagespeed: 1.13.35.2-0. Nomor versi ini sekaligus memberi tahu Anda seberapa lama modul tersebut tidak diperbarui.

Kedua, periksa URL sumber daya. Cari penanda .pagespeed. pada alamat berkas CSS, JavaScript, atau gambar di kode sumber halaman.

Ketiga, perhatikan tab Network di peramban. Permintaan ke mod_pagespeed_beacon (atau ngx_pagespeed_beacon di Nginx) menandakan modul sedang mengumpulkan data pengukuran dari browser. Endpoint ini dipanggil JavaScript suntikan modul, dan kemunculannya di konsol bukan pertanda error.

Header X-Mod-Pagespeed tidak bisa dihilangkan. Modul memakainya untuk mengenali halaman yang sudah pernah ia olah, sehingga satu instans tidak menulis ulang keluaran instans lain. Direktif ModPagespeedXHeaderValue hanya mengganti isinya, bukan menghapus headernya.

Cara Menonaktifkan mod_pagespeed dan Tiga Keadaannya

Di sinilah letak kesalahpahaman yang paling banyak memakan waktu. Saran yang paling sering beredar untuk mematikan modul adalah menaruh baris ini di .htaccess:

<IfModule pagespeed_module>
    ModPagespeed off
</IfModule>

Baris tersebut tidak mematikan modul. Nilai off menempatkannya pada mode siaga. Dalam keadaan itu modul masih menyajikan sumber daya ber-URL .pagespeed. dan masih melayani parameter PageSpeed. Perilaku ini disengaja, supaya tautan lama tidak mendadak gagal dimuat.

Modul sebenarnya memiliki tiga keadaan:

Nama standby baru diperkenalkan pada versi 1.13.35.1 sebagai penegasan atas perilaku off yang sudah ada sebelumnya. Keduanya berarti hal yang sama.

Untuk mematikan modul sepenuhnya, Anda membutuhkan unplugged, dan nilai itu hanya boleh ditulis di konfigurasi utama Apache atau di dalam blok VirtualHost:

<VirtualHost *:443>
    ServerName contoh.co.id
    ModPagespeed unplugged
</VirtualHost>

Inilah sebabnya upaya menonaktifkan mod_pagespeed di cPanel lewat .htaccess sering terasa tidak berhasil. Karena unplugged tidak bisa ditulis di sana, pengguna hosting bersama pada praktiknya hanya bisa mencapai mode siaga. Mematikan sepenuhnya menuntut akses ke konfigurasi server, yang berarti akses root di VPS Indonesia atau bantuan tim dukungan penyedia hosting Anda.

Satu jebakan lagi perlu diketahui. ModPagespeed on di dalam sebuah VirtualHost akan membatalkan ModPagespeed unplugged yang ditulis di tingkat teratas. Jika modul masih hidup padahal Anda merasa sudah mematikannya, periksa berkas konfigurasi tiap domain satu per satu.

Untuk pengujian cepat tanpa mengubah konfigurasi apa pun, tambahkan parameter berikut pada alamat halaman:

https://contoh.co.id/halaman.html?PageSpeed=off

Parameter itu menonaktifkan modul hanya untuk satu permintaan tersebut. Cara ini berguna untuk memastikan apakah suatu tampilan yang rusak memang disebabkan oleh modul atau bukan. Awalan lama ?ModPagespeed=off masih dikenali, tetapi statusnya sudah usang.

Membersihkan Cache mod_pagespeed yang Tertinggal Versi Lama

Gejalanya khas. Anda sudah memperbarui berkas CSS, tetapi pengunjung masih menerima tampilan lama, dan membersihkan cache browser tidak menolong. Yang tertinggal adalah cache di sisi server.

Cara bawaan membersihkannya adalah menyentuh sebuah berkas penanda di dalam direktori cache:

sudo touch /var/cache/mod_pagespeed/cache.flush

Modul memeriksa berkas tersebut secara berkala, sehingga perintah di atas berlaku dalam waktu hingga lima detik. Lokasi direktorinya mengikuti nilai ModPagespeedFileCachePath di konfigurasi Anda.

Tersedia juga cara yang lebih halus, yaitu membuang satu URL saja. Cara ini tidak aktif secara bawaan dan perlu dinyalakan lebih dulu:

ModPagespeedEnableCachePurge on
ModPagespeedPurgeMethod PURGE

Setelah itu satu alamat dapat dibuang dari cache tanpa mengosongkan seluruhnya, dan efeknya berlaku seketika:

curl -X PURGE https://contoh.co.id/style.css

Tiga catatan berikut menghemat banyak waktu penelusuran:

1. Pembersihan tidak menghapus berkas: modul hanya menandai isi cache agar diabaikan. Berkas lamanya baru hilang saat pembersihan rutin berjalan, yang secara bawaan dilakukan tiap satu jam.
2. Pada banyak server, perintahnya harus dijalankan di setiap mesin: penanda pembersihan disimpan secara lokal, bahkan ketika cache utamanya berada di memcached.
3. HTML memang tidak di-cache: secara bawaan seluruh HTML disajikan dengan Cache-Control: no-cache, max-age=0, karena hasil penulisan ulang belum tentu aman disimpan lama.

Kelemahan dan Hal yang Perlu Anda Pertimbangkan

Modul ini punya sisi lain yang perlu ditimbang sebelum dipasang atau dipertahankan.

1. Biaya sumber daya tidak kecil. Cache berkas bawaannya 100 MB untuk tiap direktori cache. Modul juga membatasi diri pada delapan penulisan ulang gambar sekaligus, justru untuk mencegah CPU habis. Pada server dengan RAM terbatas, beban ini bersaing langsung dengan PHP dan basis data.
2. Tampilan bisa rusak. Filter yang menggabungkan berkas JavaScript dan menunda pemuatannya adalah penyebab paling umum. Skrip yang menganggap dirinya dimuat lebih awal akan gagal berjalan. Inilah alasan ?PageSpeed=off menjadi alat diagnosa pertama.
3. Tidak boleh berdampingan dengan cache halaman penuh. Dokumentasinya sendiri menyatakan modul ini tidak dirancang untuk bekerja di belakang cache halaman utuh. Jika Anda sudah memakai Varnish Cache atau plugin cache yang menyimpan HTML jadi, menambahkan modul ini justru memperumit keadaan.
4. LiteSpeed memberi peringatan keras. Dokumentasi resminya menyebut modul ini berpotensi membuat server berhenti mendadak. Mereka meminta pengguna menyalakannya dengan risiko sendiri, dan menolak menerima laporan masalah yang berkaitan dengannya.
5. Pustaka bawaannya sudah lama tidak diperbarui. Ini poin yang paling perlu Anda periksa sendiri. Modul memaket pustaka pengolah gambar dan memakunya pada Juli 2020, di antaranya libwebp versi 1.1.0. NVD mencatat CVE-2023-4863 dengan skor 8.8 sebagai heap buffer overflow (kerusakan memori) pada libwebp di bawah versi 1.3.2. Sementara itu modul ini mendekode berkas gambar dari sumber luar setiap kali melakukan penulisan ulang, dan hulunya sudah tidak menerima perbaikan sejak April 2023.

Satu pertimbangan teknis lagi. Filter combine_css dan combine_javascript dirancang pada masa ketika setiap berkas berarti satu koneksi baru yang mahal. Pada HTTP/2, banyak berkas dapat dikirim bersamaan lewat satu koneksi. Penggabungan berkas kehilangan sebagian besar alasannya, dan bahkan bisa merugikan karena satu perubahan kecil membatalkan cache seluruh gabungan.

Alternatif mod_pagespeed yang Masih Dirawat pada 2026

Pilihan penggantinya bergantung pada web server yang Anda pakai. Berikut pemetaannya beserta syarat masing-masing.

Untuk pengguna WordPress, LiteSpeed Cache memberi hasil paling menyeluruh bila servernya memang LiteSpeed. Kalau bukan, pendekatan lewat CDN biasanya lebih hemat tenaga daripada memasang modul di server. Pengguna layanan web hosting umumnya tidak perlu memikirkan modul sisi server sama sekali, karena penyedia yang menentukan konfigurasinya.

Lalu kapan mempertahankan modul yang sudah terpasang masih masuk akal? Tiga syarat berikut sebaiknya terpenuhi bersamaan:

1. Modulnya sudah berjalan stabil selama minimal enam bulan tanpa laporan tampilan rusak.
2. Server tidak memuat gambar dari sumber luar yang tidak Anda kendalikan, sehingga masukan ke pustaka pengolah gambar terbatas pada berkas Anda sendiri.
3. Tidak ada rencana pembaruan besar pada sistem operasi dalam waktu dekat.

Kalau salah satu saja tidak terpenuhi, pindahkan pekerjaan optimasi ke lapisan lain secara bertahap. Turunkan ModPagespeedRewriteLevel ke OptimizeForBandwidth, amati dua minggu, lalu pindah ke unplugged setelah pengganti siap.

Pertanyaan yang Sering Muncul Seputar mod_pagespeed

Apakah mod_pagespeed masih aman dipakai pada 2026?

Modulnya tetap berjalan, tetapi tidak lagi menerima perbaikan sejak April 2023. Untuk server yang hanya mengolah gambar milik sendiri dan sudah stabil bertahun-tahun, risikonya terbatas. Untuk server yang menerima unggahan gambar dari pengguna, sebaiknya cari pengganti.

Kenapa mod_pagespeed tidak ada di daftar modul EasyApache 4?

Karena cPanel memang tidak pernah memaketkannya. Daftar modul Apache resmi mereka memuat mod_brotli, mod_http2, mod_security2, dan beberapa lainnya, tanpa mod_pagespeed. Paket apa pun yang terpasang di server Anda berasal dari repositori pihak ketiga.

Apakah ngx_pagespeed sama dengan mod_pagespeed?

Mesin optimasinya sama, begitu pula daftar filternya. Perbedaannya pada cara pemasangan dan penamaan. ngx_pagespeed harus dikompilasi bersama Nginx, dan header yang disuntikkannya bernama X-Page-Speed, bukan X-Mod-Pagespeed.

Apa arti URL yang mengandung .pagespeed. di website saya?

Itu sumber daya hasil olahan modul. Bagian acak di dalam namanya adalah sidik jari isi berkas, yang membuat browser otomatis mengambil versi baru setiap kali isinya berubah. Kehadirannya menandakan modul sedang aktif.

Bagaimana mematikan mod_pagespeed hanya untuk satu domain?

Tambahkan ModPagespeed unplugged di dalam blok VirtualHost domain tersebut, lalu muat ulang Apache. Jika Anda tidak memiliki akses ke berkas konfigurasi, ModPagespeed off di .htaccess adalah batas terjauh yang bisa dicapai, dan hasilnya mode siaga.

Apakah mod_pagespeed cocok dipakai di WordPress?

Bisa, karena modul bekerja di bawah aplikasi apa pun. Namun kombinasi mod_pagespeed WordPress dengan plugin cache yang juga meringkas CSS dan JavaScript sering berbenturan dan membuat tampilan rusak. Pilih salah satu lapisan saja, dan untuk WordPress lapisan plugin biasanya lebih mudah dikendalikan.

Apakah menonaktifkan modul merusak halaman yang sudah tersimpan di cache?

Tidak, selama Anda memakai off atau standby. Justru itulah gunanya mode siaga. Dengan unplugged, tautan lama ke sumber daya .pagespeed. akan gagal dimuat, sehingga sebaiknya bersihkan cache halaman dan CDN setelahnya.

Kesimpulan

mod_pagespeed adalah modul yang menulis ulang halaman di dalam Apache atau Nginx. Selama lebih dari satu dekade ia menawarkan optimasi otomatis tanpa menyentuh kode website. Proyeknya pensiun pada Maret 2023 dan repositorinya diarsipkan pada April 2025, meski ratusan ribu situs masih menjalankannya.

Bila modul ini sudah terpasang dan berjalan stabil, tidak ada alasan mematikannya malam ini juga. Namun untuk pemasangan baru, pekerjaan optimasi lebih baik diletakkan pada lapisan yang masih dirawat. Dan bila Anda memang ingin mematikannya, ingat bahwa off hanya membuatnya siaga, sedangkan yang benar-benar mematikan adalah unplugged di konfigurasi server.

Semoga artikel ini membantu.