Kenapa website lambat,
padahal hosting bagus
dan gambar sudah dikompres?

Semua Sudah Dilakukan, Kok Masih Lambat

Pesannya biasanya masuk kira-kira begini.

"Mas, hosting saya sudah saya naikkan ke paket bisnis. Gambarnya juga sudah saya kecilin satu-satu pakai TinyPNG. Plugin cache sudah dipasang. Tapi kok bukanya masih berat ya?"

Yang bikin frustrasi dari kondisi seperti ini bukan cuma websitenya. Uang sudah keluar, waktu sudah habis, dan hasilnya tidak kelihatan. Wajar kalau orangnya mulai curiga jangan-jangan yang salah dirinya sendiri.

Padahal tiga tindakan tadi sebenarnya benar semua. Cuma tiga-tiganya memperbaiki tiga hal yang berbeda, dan tidak ada jaminan salah satunya kebetulan menyentuh bagian yang bikin lambat.

Nah, di sinilah masalahnya. Waktu yang dirasakan pengunjung itu jumlah dari banyak potongan kecil, dan tiap potongan punya pemilik yang berbeda.

Sebagian potongan itu ada di server Anda. Sebagian lagi ada di browser pengunjung, dan sisanya ada di server perusahaan lain yang Anda undang masuk ke halaman tanpa sadar.

Kalau Anda memperbaiki potongan yang cuma memakan 0,2 detik, hasilnya ya 0,2 detik. Tidak peduli seberapa keras usahanya.

Jadi urutan kerjanya harus dibalik. Ukur dulu di mana detiknya habis, baru perbaiki. Seluruh isi artikel ini disusun mengikuti urutan itu, dan pemeriksaan intinya bisa Anda selesaikan dalam sepuluh menit tanpa memasang apa pun.

Tapi sebelum mengukur, ada satu kata yang perlu diluruskan dulu.

Kata "Lambat" Itu Menampung Tiga Masalah Berbeda

Waktu klien bilang websitenya lambat, yang dia maksud bisa salah satu dari tiga hal ini, dan ketiganya punya penyebab yang sama sekali tidak berhubungan.

• Lama muncul. Layar putih dulu beberapa detik, baru isinya kelihatan. Ukurannya LCP, waktu sampai elemen terbesar di layar selesai digambar.
• Berat waktu disentuh. Halaman sudah kelihatan, tapi tombolnya diklik dan tidak ada reaksi selama satu dua detik. Ukurannya INP, jeda antara pengunjung mengklik dan layar berubah.
• Loncat-loncat. Anda sedang membaca, lalu tulisannya tiba-tiba melompat ke bawah karena ada gambar atau iklan yang baru datang. Ukurannya CLS.

Ketiganya masuk kelompok Core Web Vitals, ukuran pengalaman halaman yang dipakai Google. INP sendiri baru jadi anggota tetapnya pada 2024, menggantikan FID yang sebelumnya dipakai.

Ada satu ukuran lagi yang sering ikut disebut, yaitu TTFB. Angka ini menghitung berapa lama server Anda butuh sebelum mulai menjawab.

TTFB bukan bagian dari Core Web Vitals, jadi jangan dikejar mati-matian. Tapi buat mencari sumber masalah, angka inilah yang paling berguna, dan sebentar lagi kita pakai.

Ini angka ambangnya.

Dua hal yang perlu Anda catat dari tabel itu.

Pertama, penilaiannya diambil di persentil ke-75. Artinya tiga dari empat pengunjung Anda harus mendapat angka di bawah ambang, bukan rata-ratanya.

Kedua, mobile dan desktop dinilai terpisah. Website yang hijau di desktop bisa merah di mobile, dan yang dilihat Google untuk sebagian besar bisnis lokal ya yang mobile.

Halaman yang lambat juga tidak langsung membuat peringkat Anda anjlok. Pengaruhnya nyata tapi kecil dibanding relevansi konten, jadi jangan berharap urusan SEO beres cuma dengan mengejar angka hijau. Yang lebih langsung terasa justru pengunjung yang keburu menutup tab.

Skor PageSpeed Bukan Kecepatan Website Anda

Sebelum lanjut, ada satu salah paham yang perlu dibereskan, karena salah paham ini yang bikin banyak orang mengoptimasi hal yang tidak rusak.

Buka PageSpeed Insights, masukkan alamat website Anda, dan Anda akan dapat satu angka besar antara 0 sampai 100. Angka itu bukan kecepatan website Anda.

Halaman hasilnya sebetulnya punya dua bagian yang isinya berbeda jauh.

Bagian atas berisi data lapangan. Isinya pengukuran dari pengguna Chrome sungguhan yang membuka website Anda selama 28 hari terakhir, dikumpulkan lewat Chrome UX Report. Inilah yang dipakai Google untuk menilai halaman Anda.

Kalau pengunjung website Anda masih sedikit, bagian itu sering kosong dan tulisannya bilang datanya tidak cukup.

Bagian bawah berisi data lab. Isinya hasil Lighthouse, yang menjalankan halaman Anda satu kali di mesin virtual dengan jaringan yang sengaja diperlambat secara seragam. Skor 0 sampai 100 yang bikin deg-degan itu datang dari sini.

Dua bagian itu sering tidak sama, dan wajar kok. Data lab menyimulasikan satu perangkat kelas menengah dengan koneksi yang dibuat jelek. Pengunjung Anda yang sesungguhnya pakai HP dan jaringan yang bermacam-macam.

Konsekuensinya begini. Kalau bagian atas hijau tapi skor labnya kuning, sebenarnya tidak ada yang perlu Anda kerjakan.

Sebaliknya, kalau skor labnya 95 tapi bagian atas merah, itu tanda ada sesuatu di dunia nyata yang tidak tertangkap simulasi. Biasanya server yang responsnya naik turun di jam ramai.

Dua hal kecil yang juga sering bikin bingung. Pastikan Anda melihat tab yang benar, karena skor mobile dan desktop bisa selisih 40 poin.

Dan pastikan halaman yang Anda ukur memang halaman yang dikeluhkan. Skor homepage yang isinya sedikit tidak mewakili halaman produk yang isinya berat.

Soal mengejar 100, sudah, tidak usah. Selisih 92 ke 100 hampir tidak ada artinya buat pengunjung, sementara pekerjaan untuk mengejarnya bisa memakan berhari-hari.

Pemeriksaan Pertama: Server atau Browser?

Sekarang bagian yang paling berguna. Satu pemeriksaan ini akan memotong daftar tersangka jadi separuh.

Kalau Anda punya akses terminal, jalankan perintah ini dan ganti alamatnya dengan alamat website Anda.

curl -o /dev/null -s -w "dns:      %{time_namelookup}\nkoneksi:  %{time_connect}\ntls:      %{time_appconnect}\nttfb:     %{time_starttransfer}\ntotal:    %{time_total}\n" https://namadomain.com/

Kalau tidak terbiasa dengan terminal, hasil yang sama bisa Anda lihat lewat browser.

Buka website Anda di Chrome, tekan F12, pilih tab Network, lalu muat ulang halamannya. Klik baris paling atas yang namanya sama dengan alamat halaman Anda, pilih tab Timing, dan cari angka di baris Waiting for server response.

Angka itulah TTFB Anda. Begini cara membacanya.

• Di bawah 0,4 detik. Server Anda tidak bersalah. Berhenti memikirkan hosting, dan lompat ke bagian browser.
• 0,4 sampai 0,8 detik. Masih wajar untuk hosting kelas menengah di Indonesia. Bisa diperbaiki, tapi bukan prioritas.
• 0,8 sampai 1,8 detik. Server mulai jadi bagian dari masalah, walaupun jarang jadi satu-satunya.
• Di atas 1,8 detik. Nah, ini penyebab utamanya. Perbaiki bagian server dulu sebelum menyentuh yang lain.

Jalankan perintahnya tiga sampai empat kali, dan sekali lagi di jam sibuk. Kalau angkanya stabil di percobaan pertama tapi melonjak di jam ramai, itu petunjuk yang berbeda lagi. Nanti kita bahas di bagian server.

Gambar di bawah ini menunjukkan ke mana detik-detiknya pergi, dan di sebelah mana garis pemisahnya.

Perhatikan proporsinya. Di contoh itu, seluruh urusan hosting cuma memegang 0,9 detik dari total 3 detik. Menaikkan paket hosting dua kali lipat, kalau memang berhasil memangkas separuh, cuma menghemat 0,45 detik. Sisanya yang 1,7 detik tetap di tempatnya.

Tabel Gejala, Tersangka, dan Cara Memastikannya

Sebelum masuk ke perbaikan, cocokkan dulu keluhan yang Anda dengar dengan tabel ini. Kolom paling kanan yang penting, karena di situ Anda memastikan tebakannya benar sebelum mengeluarkan uang.

Kalau Angkanya Menunjuk ke Server

TTFB Anda tinggi. Sekarang pertanyaannya kenapa, dan jawabannya jarang "hostingnya kurang mahal".

1. Kena batas CPU, bukan kehabisan disk

Paket hosting yang menulis unlimited di brosurnya biasanya sedang bicara soal disk dan bandwidth. Yang tidak pernah unlimited itu CPU dan jumlah proses yang boleh jalan bersamaan.

Kalau website Anda melewati batas itu, request yang datang berikutnya diantre. Pengunjung tidak melihat pesan error apa pun, dia cuma menunggu lebih lama.

Cara memeriksanya ada di cPanel, menu Resource Usage. Lihat grafiknya di jam ramai dan cari kolom faults. Kalau angkanya sering bukan nol, ya itu jawabannya, dan menambah RAM di paket yang sama belum tentu menolong.

2. Tetangga satu server

Di shared hosting, satu mesin dipakai bersama puluhan sampai ratusan website. Kalau ada satu website tetangga yang lagi diserbu pengunjung atau kena serangan, mesinnya sibuk, dan website Anda ikut kena imbasnya.

Tandanya khas. TTFB Anda bagus waktu dites malam hari, lalu jelek di jam sepuluh pagi, padahal tidak ada yang Anda ubah.

3. Query database yang berat

Ini penyebab paling sering di website WordPress yang umurnya sudah beberapa tahun. Tabel wp_options yang penuh data autoload, tabel wp_postmeta yang menumpuk sisa plugin lama, atau satu plugin yang menjalankan puluhan query di tiap halaman.

Cara memeriksanya pasang plugin Query Monitor sebentar di halaman yang lambat. Plugin itu menunjukkan berapa query yang jalan, berapa lama, dan plugin mana yang memanggilnya. Setelah ketemu, copot lagi Query Monitor-nya.

4. Server Anda jauh dari pengunjung Anda

Kalau pelanggan Anda orang Malang dan servernya ada di Amerika, tiap perjalanan bolak-balik data memakan sekitar 200 sampai 300 milidetik. Satu halaman butuh beberapa perjalanan seperti itu sebelum isinya lengkap.

Hosting murah dari luar negeri sering terlihat menarik di harga. Yang tidak tertulis di halaman penjualannya adalah jarak itu.

Untuk pengunjung Indonesia, server di Jakarta atau Singapura selisihnya terasa. Cek lokasi server Anda dengan melihat angka koneksi di hasil curl tadi. Kalau di atas 150 milidetik padahal Anda tes dari Indonesia, servernya kemungkinan besar memang jauh.

5. DNS yang lambat menjawab

Sebelum browser bisa menghubungi server Anda, dia harus menerjemahkan nama domain jadi alamat IP. Proses itu dikerjakan DNS, dan hasilnya kelihatan di angka dns pada perintah curl tadi.

Angka yang wajar ada di bawah 100 milidetik untuk kunjungan pertama. Kalau konsisten jauh di atas itu, pindahkan pengelolaan DNS ke layanan yang lebih cepat seperti Cloudflare, yang untuk keperluan ini gratis. Perbaikannya kecil, tapi berlaku untuk tiap pengunjung baru.

6. Redirect yang bertumpuk

Ketik domainanda.com di browser, dan yang sering terjadi di baliknya begini. Alamat itu diarahkan ke versi https, lalu diarahkan lagi ke versi dengan www, baru sampai ke halamannya. Tiap lompatan itu perjalanan bolak-balik sendiri.

Periksa dengan perintah ini.

curl -sIL -o /dev/null -w "lompatan: %{num_redirects}\ntotal:    %{time_total}\n" http://domainanda.com/

Satu lompatan itu wajar. Tiga ke atas berarti aturan redirect Anda saling bertumpuk dan sebaiknya dirapikan jadi satu langkah langsung ke alamat final.

Kalau Angkanya Menunjuk ke Browser

TTFB Anda sudah bagus, tapi halaman tetap terasa lama. Berarti waktunya habis setelah HTML sampai, dan tidak ada paket hosting yang bisa memperbaikinya.

1. Dikompres bukan berarti diperkecil

Ini yang paling sering. Dua pekerjaan yang berbeda sering dianggap satu.

Kompres menurunkan kualitas supaya ukuran filenya turun. Dimensinya tidak berubah. Resize mengurangi jumlah pikselnya.

Foto 4000 x 3000 piksel yang dikompres sampai tinggal 400 KB tetap punya lebar 4000 piksel.

Filenya memang jadi ringan diunduh, tapi browser tetap harus membongkar 12 juta piksel itu di memori, padahal gambarnya cuma tampil selebar 800 piksel di layar. Di HP kelas menengah, pekerjaan membongkar itu terasa.

Urutan yang benar begini. Resize dulu ke ukuran tampil, paling banter dua kali lipatnya untuk layar beresolusi tinggi. Baru dikompres. Lalu disimpan sebagai WebP atau AVIF, yang untuk kualitas setara biasanya 25 sampai 50 persen lebih kecil dari JPEG.

Cara memastikannya cepat kok. Buka DevTools, masuk tab Elements, arahkan kursor ke gambarnya, dan browser menampilkan tooltip berisi dua angka. Kalau Intrinsic size jauh lebih besar dari Rendered size, gambar itu memang kelebihan piksel.

2. Gambar paling atas justru kena lazy loading

Lazy loading itu bagus untuk gambar yang ada jauh di bawah, karena gambarnya baru diunduh saat pengunjung menggulir ke sana. Tapi kalau atribut loading="lazy" ikut terpasang di gambar paling atas, browser justru menunda gambar yang paling dibutuhkan.

Repotnya, sebagian plugin optimasi memasang lazy loading ke semua gambar sekaligus, termasuk yang di atas. Gambar paling atas seharusnya kebalikannya, yaitu loading="eager" ditambah fetchpriority="high" supaya browser mendahulukannya.

3. Font yang diambil dari server orang lain

Baris <link> ke fonts.googleapis.com kelihatan sepele, padahal browser harus membuka koneksi ke dua domain baru, mengunduh file CSS, membaca isinya, baru mengunduh file fontnya. Selama rangkaian itu berjalan, teks Anda belum bisa digambar.

Solusinya unduh file fontnya, taruh di server Anda sendiri, panggil lewat @font-face, dan tambahkan font-display:swap supaya teks tetap tampil dengan font cadangan selama font aslinya masih dalam perjalanan.

4. JavaScript yang menghalangi halaman digambar

Tag <script> tanpa defer di dalam <head> memaksa browser berhenti membaca HTML, mengunduh file itu, menjalankannya, baru melanjutkan. Padahal isinya sering cuma animasi yang tidak ada urusannya dengan tampilan pertama.

Tambahkan defer pada script yang tidak wajib jalan duluan, dan pindahkan yang benar-benar berat ke bawah.

5. Halaman yang bergeser karena gambar tanpa ukuran

Kalau <img> ditulis tanpa atribut width dan height, browser tidak tahu harus menyediakan ruang berapa. Begitu gambarnya datang, isi halaman terdorong ke bawah, dan itulah yang tercatat sebagai CLS.

Perbaikannya menulis dimensi asli gambar di atributnya. Ukuran tampil tetap diatur CSS, jadi tidak ada yang berubah secara tampilan, cuma browser sekarang tahu harus memesan ruang berapa.

Tamu yang Anda Undang Sendiri ke Halaman

Bagian ini pantas berdiri sendiri, karena inilah jawaban paling sering untuk pertanyaan di judul artikel ini.

Coba hitung berapa hal berikut yang terpasang di website Anda.

• Widget chat seperti Tawk.to atau Crisp, atau plugin tombol WhatsApp melayang
• Google Tag Manager, dan di dalamnya GA4
• Meta Pixel, ditambah TikTok Pixel kalau Anda beriklan di sana
• Video YouTube yang ditanam langsung, yang menarik ratusan KB sebelum pengunjung mengklik apa pun
• Peta Google Maps di halaman kontak
• Feed Instagram di footer
• Font dari Google Fonts
• Plugin ulasan yang mengambil data bintang dari luar

Tidak satu pun dari daftar itu tinggal di hosting Anda. Semuanya diunduh dari server perusahaan lain, saat halaman Anda sedang dibuka.

Artinya begini. Server Anda boleh secepat apa pun, tapi kalau server Tawk.to sedang lambat siang itu, halaman Anda ikut menunggu. Anda membayar hosting, sementara sebagian kecepatan halaman Anda dipegang orang lain.

Cara memeriksanya gampang. Buka DevTools, tab Network, muat ulang halamannya. Klik kanan di baris judul kolom, aktifkan kolom Domain, lalu klik kolom itu untuk mengurutkan. Semua baris yang domainnya bukan domain Anda itu tamu.

Setelah daftarnya kelihatan, ajukan satu pertanyaan untuk tiap tamu. Ini menghasilkan apa? Kalau pixel iklan yang kampanyenya sudah berhenti setahun lalu masih terpasang, ya copot. Kalau ada dua tools analytics yang mengukur hal yang sama, sisakan satu.

Untuk video YouTube dan peta, ada jalan tengahnya. Tampilkan gambar sampulnya dulu, dan baru muat video atau petanya waktu pengunjung mengklik. Cara ini biasa disebut facade, dan bedanya bisa ratusan KB per halaman.

Padahal Cache Sudah Nyala

Cache nyala dan cache kena itu dua hal yang berbeda, dan hampir tidak ada yang memeriksa yang kedua.

Cara memastikannya begini. Buka DevTools, tab Network, klik baris paling atas yang berisi dokumen halaman Anda, lalu lihat bagian Response Headers. Cari baris yang mirip salah satu ini.

x-litespeed-cache: hit
cf-cache-status: HIT
x-cache: HIT

Kalau yang muncul MISS atau BYPASS terus-menerus, plugin cache Anda memang menyala, cuma halaman yang dilihat pengunjung tidak pernah diambil dari sana.

Ini alasan-alasan yang paling sering bikin meleset.

• Anda sedang login sebagai admin. Hampir semua sistem cache melewatkan pengunjung yang login, supaya Anda selalu melihat versi terbaru. Akibatnya, selama ini Anda mengukur versi paling lambat dari website Anda sendiri. Ukur ulang lewat jendela incognito.
• Alamat halaman membawa query string. Klik dari Google Ads menempelkan ?gclid=... di belakang alamat, dan klik dari Facebook menempelkan ?fbclid=.... Banyak konfigurasi cache menganggap tiap alamat unik itu halaman baru. Jadi justru pengunjung berbayar Anda, yang kliknya Anda bayar satu per satu, yang kebagian halaman paling lambat.
• Halamannya memang dikecualikan. Keranjang, checkout, halaman akun, dan hasil pencarian biasanya dikecualikan sejak awal. Itu memang benar dan jangan dipaksa, tapi berarti halaman itu perlu diperbaiki dengan cara lain.
• Ada plugin yang membuang cache terus-menerus. Plugin statistik atau anti-spam yang menulis ke database tiap kunjungan bisa memicu pembersihan cache berulang kali, sehingga cache-nya hampir tidak pernah sempat dipakai.
• Masa simpannya kependekan. Cache yang dibuang tiap sepuluh menit di website yang isinya jarang berubah itu mubazir. Naikkan masa simpannya, dan biarkan cache dibersihkan hanya waktu Anda benar-benar mengubah isi halaman.

Padahal Sudah Pakai CDN

CDN sering dijual sebagai obat serba bisa. Kenyataannya CDN memperbaiki satu hal spesifik, dan hal itu belum tentu masalah Anda. Penjelasan lengkapnya, termasuk biaya dan kapan CDN tidak berguna, ada di apa itu CDN.

Tiga hal yang perlu Anda tahu sebelum berharap banyak.

Pertama, HTML Anda kemungkinan besar tidak ikut disimpan. Konfigurasi bawaan kebanyakan CDN cuma menyimpan file statis seperti gambar, CSS, dan JavaScript. Halaman HTML-nya tetap diambil dari server asal tiap ada pengunjung.

Jadi kalau yang bikin lambat itu waktu server menyusun halaman, TTFB Anda tidak bergerak sedikit pun setelah CDN dipasang.

Supaya TTFB ikut turun, HTML-nya harus ikut disimpan di edge. Di Cloudflare pengaturannya ada di Cache Rules, dan untuk WordPress ada layanan APO yang mengurusnya sekalian.

Kedua, jaraknya mungkin memang sudah dekat. CDN paling terasa kalau pengunjung Anda tersebar jauh dari server. Kalau pelanggan Anda orang Indonesia semua dan server Anda sudah di Jakarta, selisih yang bisa diberikan CDN tinggal beberapa puluh milidetik.

Ketiga, CDN yang salah setel bisa memperlambat. Mode SSL yang tidak cocok, aturan cache yang saling bertabrakan, atau proxy yang menyala untuk subdomain yang seharusnya langsung, semuanya menambah lompatan yang tidak perlu.

Cara memastikan CDN Anda benar-benar bekerja sama seperti tadi. Lihat header cf-cache-status pada gambar dan pada dokumen HTML secara terpisah. Kalau gambarnya HIT tapi dokumennya selalu DYNAMIC, berarti CDN Anda memang belum menyentuh halamannya.

Jangan-jangan Lambatnya Cuma di Tempat Anda

Sebelum mengeluarkan uang, satu pemeriksaan lagi yang sering terlewat. Bisa jadi yang lambat bukan websitenya, tapi cara Anda mengaksesnya.

• Buka lewat jendela incognito. Extension browser, terutama yang berhubungan dengan SEO atau pemblokir iklan, ikut memperlambat halaman. Di incognito extension biasanya mati dan Anda juga tidak login, jadi versi yang Anda lihat lebih mirip versi pengunjung.
• Coba dari HP pakai kuota, bukan wifi kantor. Kalau di kuota justru cepat, masalahnya ada di jaringan kantor Anda.
• Ganti DNS perangkat Anda sebentar ke 1.1.1.1 atau 8.8.8.8, lalu bandingkan. DNS bawaan ISP di Indonesia kadang lambat menjawab, dan itu terasa di tiap website, bukan cuma website Anda.
• Cek apakah IP Anda kena batasi sendiri. Plugin keamanan sering memperlambat atau menantang IP yang terlalu sering memuat ulang halaman, dan orang yang sedang mengetes websitenya sendiri persis melakukan itu.
• Minta dua tiga orang membuka dari kota lain. Kalau semua bilang cepat, berhenti mengoptimasi.

Poin terakhir itu serius. Banyak waktu habis untuk memperbaiki sesuatu yang sebenarnya tidak rusak, cuma karena satu orang mengukurnya dari satu tempat yang kebetulan bermasalah.

Yang Kami Temukan Waktu Membenahi Website Ini Sendiri

Juli 2026 kami mengukur halaman layanan kami sendiri. Skor performa mobile-nya 86, sudah lumayan, dan hosting bukan masalahnya. Tapi datanya menunjukkan teksnya baru muncul jauh setelah HTML-nya sampai.

Ada empat temuan, dan tidak ada satu pun yang berhubungan dengan spesifikasi server.

• Font diambil dari Google Fonts. Rangkaian koneksi dan unduhannya menyumbang sekitar 2,5 detik render delay pada teks yang jadi elemen LCP. Teksnya sudah ada di HTML sejak awal, cuma belum boleh digambar karena fontnya belum datang.
• Kompresi teks di server tidak aktif. Semua file HTML, CSS, dan JavaScript dikirim utuh tanpa gzip.
• Tidak ada cache header sama sekali. Pengunjung yang kembali besoknya mengunduh ulang semuanya dari nol.
• Judul halaman disembunyikan oleh CSS kami sendiri. Ini yang paling bikin geleng-geleng. Ada aturan animasi opacity:0 yang menutupi <h1> sampai file JavaScript selesai jalan, dan file itu baru selesai sekitar detik 2,9.

Temuan keempat itu yang paling jelas menunjukkan kenapa upgrade hosting sering tidak menolong. Teksnya sudah ada di HTML, sudah terkirim di paket data pertama, sudah sampai di browser pengunjung. Lalu website kami sendiri yang menyuruh browser jangan menampilkannya dulu.

Yang kami kerjakan setelah itu begini.

• Dua font kami unduh dan taruh di server sendiri. Kebetulan dua-duanya variable font, jadi cukup satu file woff2 untuk tiap font, dipanggil lewat @font-face dengan font-display:swap.
• gzip dinyalakan di nginx, dan cache header dipasang. Gambar dan font disimpan 30 hari, CSS dan JavaScript satu hari.
• Aturan CSS yang menyembunyikan judul diubah supaya judulnya langsung digambar, animasinya tetap ada tapi cuma menggeser posisi, tidak lagi menahan tampilan.
• Gambar utama dikasih fetchpriority="high" dan dimensinya dibetulkan ke ukuran aslinya.
• Efek kursor dan hover yang jalan terus-menerus dimatikan di perangkat sentuh, karena di HP efek itu tidak kelihatan tapi tetap memakan CPU.

Hasilnya skor performanya masuk hijau, dan yang lebih penting, teks utamanya sekarang muncul bersamaan dengan gambar pertama, bukan menunggu JavaScript. Sisa yang belum ideal tinggal TTFB di kisaran 580 milidetik, dan itu memang bagian server.

Jadi dari empat temuan, tiga ada di kode dan satu di konfigurasi server. Nol di spesifikasi hosting.

Kapan Menambal Sudah Tidak Masuk Akal

Ada titik di mana mengoptimasi terus itu jadi pemborosan, dan sebaiknya Anda tahu tandanya sebelum uangnya terlanjur keluar.

• Anda sudah mencopot plugin sampai ada fungsi yang hilang, dan skornya cuma naik beberapa poin.
• Temanya dirakit berlapis-lapis. Satu bagian halaman dibungkus lima sampai enam lapis div, dan file CSS-nya sendiri ratusan KB karena harus menampung semua kemungkinan tampilan yang tidak Anda pakai.
• Tiap perbaikan merusak yang lain. Minify dinyalakan, tampilan berantakan. Lazy loading dinyalakan, slider mati.
• Biaya optimasi tahunan sudah mendekati biaya membangun ulang. Coba jumlahkan pengeluaran dua tahun terakhir untuk plugin premium, jasa optimasi, dan upgrade hosting yang tidak mengubah apa-apa.

Kalau tiga dari empat tanda itu Anda kenali, membangun ulang biasanya lebih murah daripada meneruskan tambalan. Pertimbangannya sudah kami tulis terpisah di perbedaan website custom dan WordPress, termasuk hitungan biayanya selama tiga tahun.

Tapi ada satu hal yang perlu dikatakan jujur di sini. Membangun ulang tidak otomatis menghasilkan website yang cepat. Website baru yang ditumpuk animasi, video latar, dan lima tools pengukur juga akan berat, dan Anda kembali ke titik awal cuma dengan kode yang lebih baru.

Yang membuat sebuah website cepat itu keputusan-keputusan kecil sepanjang pengerjaan, bukan teknologinya.

Jadi kalau Anda sedang menimbang membangun ulang, tanyakan ke calon pembuatnya berapa angka LCP yang mereka targetkan. Minta juga mereka menunjukkan hasil pengukuran website yang pernah mereka kerjakan.

Itu yang kami lakukan di tiap proyek jasa pembuatan website malang, dan angka di bagian sebelumnya adalah angka website kami sendiri.

Satu catatan penutup. Kalau alasan Anda mengejar kecepatan adalah peringkat Google, kecepatan cuma sebagian kecil dari ceritanya.

Kondisi yang lebih sering terjadi justru halamannya belum terbaca Google sejak awal, dan itu urusan yang berbeda. Kami bahas terpisah di website tidak muncul di Google.

Pertanyaan Umum