{"id":1949,"date":"2026-10-20T10:00:57","date_gmt":"2026-10-20T03:00:57","guid":{"rendered":"https:\/\/achmadfarid.com\/?p=1949"},"modified":"2026-10-18T20:17:13","modified_gmt":"2026-10-18T13:17:13","slug":"optimasi-gambar-untuk-seo","status":"publish","type":"post","link":"https:\/\/achmadfarid.com\/en\/optimasi-gambar-untuk-seo\/","title":{"rendered":"Optimasi Gambar untuk SEO: Panduan Praktisi dari Kompresi sampai Pencarian AI"},"content":{"rendered":"

Ada satu pola yang hampir selalu saya temukan saat mengaudit website klien baru. Skor PageSpeed-nya merah, halaman artikel butuh lebih dari enam detik untuk benar-benar terasa siap dipakai, dan setelah ditelusuri sumbernya cuma satu: satu gambar header berukuran 3,8 MB yang diunggah apa adanya langsung dari kamera. Bukan plugin berat, bukan hosting murah, bukan tema yang berantakan. Cuma gambar.<\/span><\/p>\n

Yang bikin masalah ini awet adalah posisinya. Optimasi gambar untuk SEO jarang masuk laporan bulanan, jarang dibahas di rapat strategi, dan biasanya dianggap pekerjaan admin yang bisa dikerjakan siapa saja. Padahal di banyak website yang saya pegang, inilah satu-satunya perbaikan teknis yang hasilnya bisa dilihat dalam hitungan hari, bukan bulan.<\/span><\/p>\n

Di tulisan ini saya tidak akan mengulang daftar tips yang sudah ada di mana-mana. Saya akan masuk ke bagian yang biasanya dilewati: kenapa mengecilkan file saja sering tidak mengubah apa pun, urutan kerja yang saya pakai untuk menangani ratusan gambar sekaligus, dan apa yang berubah sekarang ketika yang membaca gambar Anda bukan cuma Googlebot, tapi juga mesin jawaban berbasis AI.<\/span><\/p>\n

Gambar Anda Mungkin Penyebab Website Lambat, dan Itu Tidak Muncul di Laporan SEO<\/strong><\/h2>\n

Coba lakukan satu hal sebelum lanjut membaca. Buka halaman artikel terbaik di website Anda, klik kanan, pilih inspect, masuk ke tab Network, lalu urutkan berdasarkan ukuran file. Kalau yang muncul di baris paling atas adalah file berakhiran .jpg atau .png dengan ukuran di atas 500 KB, Anda baru saja menemukan pekerjaan rumah terbesar bulan ini.<\/span><\/p>\n

Saya menyebut ini masalah yang tidak bersuara. Tidak ada error di Search Console. Tidak ada peringatan merah di dashboard. Artikelnya tetap terindeks, tetap bisa dibuka, dan kalau Anda membukanya dari laptop kantor dengan koneksi fiber, terasa baik-baik saja.<\/span><\/p>\n

Masalahnya baru kelihatan dari sisi pengunjung. Mayoritas pembaca blog bisnis di Indonesia datang dari ponsel, sering dengan sinyal yang naik turun. Gambar 3 MB yang di kantor Anda termuat dalam 0,4 detik bisa butuh belasan detik di jaringan mereka. Dan orang tidak menunggu belasan detik untuk membaca artikel gratis.<\/span><\/p>\n

Yang jarang disadari: Google melihat angka itu. Data pengalaman pengguna nyata yang dikumpulkan dari pengguna Chrome adalah data lapangan, bukan simulasi. Jadi ketika saya bilang gambar memengaruhi peringkat, maksudnya bukan karena ada “faktor ranking gambar” yang berdiri sendiri. Melainkan karena gambar yang berat merusak metrik pengalaman halaman yang memang dihitung, terutama waktu muat elemen konten terbesar, yang di sebagian besar halaman artikel elemen terbesarnya justru gambar header itu sendiri.<\/span><\/p>\n

Di artikel saya soal <\/span>metrik Core Web Vitals dan ambang batas LCP, INP, serta CLS<\/span><\/a>, saya jelaskan kenapa batas 2,5 detik itu bukan angka yang dikarang Google tanpa dasar. Yang mau saya tambahkan di sini: dari semua penyebab LCP buruk yang pernah saya tangani, gambar menempati posisi pertama dengan selisih yang jauh.<\/span><\/p>\n

Optimasi Gambar untuk SEO: 7 Hal yang Harus Beres Sebelum Upload<\/strong><\/h2>\n

Kalau Anda butuh versi singkatnya dulu sebelum masuk ke penjelasan panjang, ini daftar yang saya pakai sebagai standar minimum. Tujuh poin, berurutan, dan urutannya memang sengaja.<\/span><\/p>\n

    \n
  1. Ubah ukuran dimensi lebih dulu, bukan kompresi lebih dulu.<\/b> Potong lebar gambar ke ukuran maksimal yang benar-benar ditampilkan di layar, biasanya 1200 sampai 1600 piksel untuk gambar header artikel.<\/span><\/li>\n
  2. Konversi ke format modern.<\/b> WebP untuk hampir semua kasus, AVIF kalau hosting dan audiens Anda mendukungnya, SVG untuk ikon dan logo.<\/span><\/li>\n
  3. Kompres sampai target ukuran file, bukan sampai persentase tertentu.<\/b> Patokan saya: di bawah 150 KB untuk gambar header, di bawah 80 KB untuk gambar pendukung.<\/span><\/li>\n
  4. Beri nama file yang deskriptif sebelum diunggah.<\/b> optimasi-gambar-webp-sebelum-sesudah.webp<\/span>, bukan <\/span>IMG_20261018_004.jpg<\/span>.<\/span><\/li>\n
  5. Tulis alt text yang menjelaskan isi gambar<\/b>, bukan mengulang keyword. Satu kalimat, di bawah 125 karakter.<\/span><\/li>\n
  6. Pasang atribut lebar dan tinggi di tag gambar<\/b> supaya layout tidak bergeser saat gambar selesai dimuat.<\/span><\/li>\n
  7. Jangan lazy load gambar pertama yang terlihat di layar.<\/b> Ini kesalahan paling sering dan paling mahal, saya bahas tersendiri di bawah.<\/span><\/li>\n<\/ol>\n

    Tujuh langkah ini bisa dikerjakan dalam lima menit per gambar kalau manual, atau sekali setup untuk seluruh website kalau Anda mengotomatiskannya. Sisa artikel ini menjelaskan alasan di balik tiap poin, dan apa yang terjadi kalau urutannya dibalik.<\/span><\/p>\n

    Tiga Pekerjaan yang Sebenarnya Dilakukan Gambar di Mata Google<\/strong><\/h2>\n

    Sebelum bicara teknik, saya mau meluruskan cara pandangnya dulu. Banyak orang memperlakukan gambar sebagai satu objek dengan satu tugas, yaitu mempercantik halaman. Dari sisi mesin pencari, satu gambar sebenarnya mengerjakan tiga hal berbeda sekaligus, dan tiap pekerjaan dinilai dengan cara yang berbeda pula. Memisahkan ketiganya membuat keputusan optimasi jadi jauh lebih mudah, karena Anda tahu teknik mana melayani tujuan mana.<\/span><\/p>\n

    Pekerjaan pertama: menjadi beban yang harus diangkut browser<\/strong><\/h3>\n

    Ini sisi performa. Setiap kilobyte gambar adalah kilobyte yang harus diunduh pengunjung sebelum halaman terasa selesai. Di sisi ini yang berlaku cuma matematika: lebih kecil selalu lebih baik, selama kualitas visualnya masih layak.<\/span><\/p>\n

    Yang sering terlewat, bebannya tidak cuma soal ukuran file. Jumlah gambar juga dihitung. Artikel dengan 18 ilustrasi masing-masing 60 KB tetap mengangkut lebih dari satu megabyte, dan tiap gambar butuh permintaan jaringannya sendiri. Saya pernah memangkas artikel klien dari 22 gambar jadi 9, tanpa mengubah satu kata pun teksnya, dan waktu muatnya turun lebih dari separuh. Gambar yang dihapus memang tidak menjelaskan apa-apa, cuma pengisi ruang.<\/span><\/p>\n

    Pekerjaan kedua: menjadi informasi yang bisa dibaca mesin<\/strong><\/h3>\n

    Mesin pencari sekarang jauh lebih baik dalam mengenali isi gambar secara visual dibanding lima tahun lalu. Tapi pengenalan visual itu menjawab pertanyaan “ini gambar apa”, bukan “kenapa gambar ini ada di halaman ini”. Pertanyaan kedua dijawab oleh teks: nama file, alt text, keterangan gambar, dan kalimat di sekitarnya.<\/span><\/p>\n

    Inilah kenapa alt text yang isinya tumpukan keyword justru melemahkan. Anda sedang mengisi slot yang seharusnya menjelaskan konteks dengan sesuatu yang tidak menjelaskan apa pun.<\/span><\/p>\n

    Pekerjaan ketiga: menjadi pintu masuk tersendiri<\/strong><\/h3>\n

    Gambar bisa muncul di pencarian gambar, di kotak hasil visual, dan di hasil Google Lens. Untuk sebagian industri, jalur ini signifikan. Klien furnitur dan klien kuliner yang pernah saya tangani mendapat porsi trafik yang tidak kecil dari orang yang mencari lewat gambar lebih dulu, baru kemudian masuk ke halaman produk.<\/span><\/p>\n

    Tiga pekerjaan, tiga ukuran keberhasilan. Kompresi melayani yang pertama. Penamaan dan alt text melayani yang kedua. Kualitas visual dan relevansi melayani yang ketiga. Kalau Anda pernah bingung kenapa saran optimasi gambar terdengar saling bertentangan (perkecil sekecil mungkin, tapi jaga kualitas), ini sebabnya. Sarannya memang melayani tujuan yang berbeda.<\/span><\/p>\n

    Kenapa Mengecilkan File Saja Tidak Pernah Cukup<\/strong><\/h2>\n

    Ini bagian yang paling sering bikin orang kecewa. Mereka sudah pasang plugin kompresi, sudah menjalankan optimasi massal ke seluruh media library, angka penghematannya kelihatan besar di dashboard plugin, lalu skor PageSpeed-nya tetap saja merah.<\/span><\/p>\n

    Saya pernah mengalaminya persis. Tahun 2023 saya menangani website katalog dengan sekitar 400 gambar produk. Saya jalankan kompresi massal, hasilnya total media library turun dari 1,2 GB jadi 380 MB. Puas sekali waktu itu. Lalu saya cek lagi halaman produknya, dan LCP-nya nyaris tidak bergerak.<\/span><\/p>\n

    Penyebabnya baru saya sadari setelah memeriksa satu per satu. Gambar produknya memang sudah terkompresi, tapi dimensinya masih 4000 piksel, sementara di layar cuma ditampilkan selebar 600 piksel. Browser tetap mengunduh file besar itu utuh, lalu mengecilkannya sendiri saat merender. Kompresi mengurangi berat per piksel. Ia tidak mengurangi jumlah pikselnya.<\/span><\/p>\n

    Ini urutan yang menurut saya salah kaprah paling mahal di seluruh topik optimasi gambar. Kompresi dipasang sebagai langkah pertama, padahal tempatnya langkah kedua. Resize dulu, baru kompres. Dibalik, Anda cuma mengompres sampah dengan rapi.<\/span><\/p>\n

    Ada satu lagi yang sejenis. Banyak yang mengaktifkan lazy loading untuk semua gambar sekaligus karena terdengar seperti pengaturan yang selalu benar. Padahal gambar pertama yang langsung terlihat di layar justru harus dimuat secepat mungkin, karena biasanya dialah elemen yang diukur sebagai LCP. Menunda pemuatannya sama saja dengan sengaja memperlambat metrik yang sedang Anda kejar. Saya pernah melihat skor halaman naik belasan poin cuma dengan mengeluarkan satu gambar header dari daftar lazy load.<\/span><\/p>\n

    Menurut saya, ini juga alasan kenapa saran “pasang plugin optimasi gambar, selesai” itu menyesatkan. Plugin mengerjakan bagian yang mekanis. Keputusan soal dimensi mana yang benar, gambar mana yang layak dipertahankan, dan mana yang tidak boleh ditunda pemuatannya, tetap keputusan manusia.<\/span><\/p>\n

    Alur 5 Langkah yang Saya Pakai Setiap Kali Menangani Gambar Klien<\/strong><\/h2>\n

    Setelah mengulang pekerjaan ini di banyak website, saya berhenti mengerjakannya secara acak dan menyusunnya jadi satu urutan tetap. Urutannya penting karena tiap langkah mengurangi beban kerja langkah berikutnya. Kalau dibalik, Anda akan mengerjakan ulang hal yang sama dua kali. Lima langkah ini berlaku sama untuk website baru maupun website lama yang sudah terlanjur punya ratusan gambar.<\/span><\/p>\n

    Langkah 1: Inventarisasi, cari sepuluh terberat<\/strong><\/h3>\n

    Jangan mulai dari semuanya. Mulai dari yang paling merusak. Jalankan pemeriksaan kecepatan pada lima halaman dengan trafik tertinggi, catat gambar terbesar di tiap halaman, dan urutkan. Biasanya sepuluh gambar teratas menyumbang sebagian besar masalahnya.<\/span><\/p>\n

    Saya hampir selalu menemukan hal yang sama di tahap ini: satu atau dua gambar raksasa yang tidak sengaja terunggah, sering kali oleh orang yang sudah tidak lagi bekerja di tim itu.<\/span><\/p>\n

    Langkah 2: Tentukan dimensi maksimal per jenis gambar<\/strong><\/h3>\n

    Buat aturan sederhana dan tulis di dokumen yang bisa dibaca semua orang yang menulis di website Anda. Misalnya: gambar header maksimal 1600 piksel lebar, gambar dalam artikel maksimal 1000 piksel, thumbnail 400 piksel, ikon pakai SVG.<\/span><\/p>\n

    Aturan ini yang mencegah masalahnya kembali tiga bulan lagi. Tanpa aturan tertulis, optimasi gambar jadi pekerjaan yang diulang terus menerus tanpa pernah selesai.<\/span><\/p>\n

    Langkah 3: Konversi format, lalu kompres ke target ukuran<\/strong><\/h3>\n

    Baru di sini kompresi masuk. Konversi ke WebP dulu, karena penghematannya sudah besar bahkan sebelum dikompres lebih lanjut. Lalu kompres sampai menyentuh target ukuran file yang Anda tetapkan, bukan sampai persentase tertentu.<\/span><\/p>\n

    Bedanya terasa saat Anda bekerja dengan gambar yang karakternya berbeda. Foto produk dengan latar polos bisa turun sangat jauh tanpa terlihat rusak. Foto dengan tekstur rumit butuh kualitas lebih tinggi. Kalau patokannya persentase, keduanya diperlakukan sama dan salah satunya pasti jadi korban.<\/span><\/p>\n

    Langkah 4: Isi lapisan teksnya<\/strong><\/h3>\n

    Nama file, alt text, dan keterangan gambar diisi di tahap ini, saat Anda masih ingat gambar itu menjelaskan apa. Mengisinya belakangan selalu berakhir buruk, karena Anda akan menulis alt text untuk gambar yang sudah tidak Anda ingat konteksnya.<\/span><\/p>\n

    Patokan alt text saya sederhana: tulis seolah Anda sedang menjelaskan gambar itu lewat telepon ke orang yang tidak bisa melihatnya. Kalau kalimatnya terdengar aneh saat diucapkan, berarti Anda sedang menjejalkan keyword.<\/span><\/p>\n

    Langkah 5: Kunci di level sistem<\/strong><\/h3>\n

    Langkah terakhir yang paling sering dilewati. Atur supaya website otomatis mengonversi dan mengubah ukuran gambar yang diunggah ke depannya, pasang atribut dimensi secara otomatis, dan kecualikan gambar header dari lazy loading di level template.<\/span><\/p>\n

    Tanpa langkah kelima, empat langkah sebelumnya cuma membereskan masa lalu. Kalau bagian ini terasa terlalu teknis untuk dikerjakan sendiri, ini memang salah satu titik di mana bantuan orang yang terbiasa menangani <\/span>sisi teknis dan pengembangan website<\/span><\/a> jauh lebih hemat waktu daripada mencoba sendiri lewat trial and error di server produksi.<\/span><\/p>\n

    Satu catatan soal urutan ini: kecepatan halaman tidak pernah ditentukan gambar sendirian. Setelah gambar beres, penghambat berikutnya biasanya pindah ke skrip, caching, atau hosting, dan itu saya urai terpisah di <\/span>panduan sepuluh teknik mempercepat website untuk SEO<\/span><\/a>.<\/span><\/p>\n

    Lima Kesalahan Optimasi Gambar yang Masih Saya Temukan di Hampir Semua Audit<\/strong><\/h2>\n

    Bagian ini saya susun dari catatan audit, bukan dari teori. Kelimanya muncul berulang di website yang pemiliknya sudah merasa “gambarnya sudah dioptimasi”. Kalau Anda menemukan satu saja dari daftar ini di website Anda, kabar baiknya perbaikannya cepat.<\/span><\/p>\n

    Pertama, alt text diisi dengan nama keyword utama di semua gambar.<\/b> Lima gambar dalam satu artikel dengan alt text identik berisi keyword yang sama bukan optimasi, itu sinyal yang membingungkan. Isi dengan deskripsi berbeda sesuai isi tiap gambar.<\/span><\/p>\n

    Kedua, gambar dekoratif juga diberi alt text.<\/b> Garis pemisah, pola latar, ikon hiasan. Elemen seperti ini sebaiknya alt text-nya dikosongkan supaya pembaca layar melewatinya. Memberi deskripsi pada hiasan justru mengganggu pengguna yang bergantung pada pembaca layar.<\/span><\/p>\n

    Ketiga, screenshot diunggah dalam format PNG.<\/b> Ini kebiasaan yang bertahan dari kebiasaan lama. Untuk screenshot antarmuka yang berisi banyak warna datar, PNG sering menghasilkan file berkali lipat lebih besar dibanding WebP dengan tampilan yang praktis sama.<\/span><\/p>\n

    Keempat, tidak ada atribut lebar dan tinggi pada tag gambar.<\/b> Tanpa itu, browser tidak tahu harus menyediakan ruang berapa besar, jadi layout bergeser saat gambar akhirnya selesai dimuat. Pembaca yang sedang membaca tiba tiba kehilangan posisi barisnya, dan metrik pergeseran layout Anda ikut jelek.<\/span><\/p>\n

    Kelima, gambar yang sama dipakai di banyak ukuran berbeda tanpa versi responsif.<\/b> Satu file 1600 piksel dipakai untuk header desktop sekaligus thumbnail 300 piksel di sidebar. Pengguna ponsel mengunduh file besar itu untuk menampilkan gambar sebesar perangko.<\/span><\/p>\n

    Kalau Anda sedang merapikan sisi on-page secara menyeluruh, gambar sebaiknya tidak dikerjakan terpisah dari elemen lain seperti struktur heading, title tag, dan internal link. Semuanya saling menopang, dan saya sudah menguraikan urutan pengerjaannya di <\/span>panduan 13 teknik optimasi on-page SEO<\/span><\/a>.<\/span><\/p>\n

    Optimasi Gambar di Era Pencarian AI dan Google Lens<\/strong><\/h2>\n

    Sekarang bagian yang menurut saya paling jarang dibahas, padahal dampaknya mulai terasa. Yang membaca halaman Anda sekarang bukan cuma perayap mesin pencari klasik. Ada mesin jawaban berbasis AI yang merangkum halaman, dan ada pencarian visual yang berangkat dari gambar, bukan dari kata kunci.<\/span><\/p>\n

    Perbedaan cara kerjanya penting. Mesin jawaban tidak menampilkan halaman Anda, ia menjelaskan isinya. Supaya gambar Anda ikut terbaca sebagai bagian dari penjelasan itu, gambar perlu punya konteks tekstual yang berdiri sendiri. Gambar grafik perbandingan yang tidak dijelaskan di kalimat sekitarnya praktis tidak terbaca. Gambar yang sama, dengan satu paragraf yang menyebut apa yang ditunjukkan grafik itu dan angka kuncinya, jadi bahan yang bisa dikutip.<\/span><\/p>\n

    Ini mengubah prioritas sedikit. Dulu keterangan gambar sering saya anggap opsional. Sekarang saya memperlakukannya sebagai tempat meletakkan satu kalimat yang merangkum isi gambar dalam bentuk yang bisa dibaca mesin dan berguna buat pembaca sekaligus.<\/span><\/p>\n

    Untuk pencarian visual, yang berlaku agak berbeda lagi. Di sini kualitas gambar justru tidak boleh dikorbankan habis habisan. Gambar produk yang terlalu dikompres sampai tekstur dan detailnya hilang lebih sulit dikenali. Saya biasanya memberi pengecualian kompresi untuk gambar produk utama: boleh lebih besar dari standar, asal dimensinya tepat dan formatnya modern.<\/span><\/p>\n

    Satu hal lagi yang mulai saya terapkan untuk klien dengan katalog besar: menambahkan data terstruktur yang menyebut gambar secara eksplisit, lengkap dengan keterangan dan lisensinya. Ini tidak langsung menaikkan peringkat, tapi membuat gambar Anda jadi objek yang punya identitas, bukan sekadar file yang kebetulan menempel di halaman.<\/span><\/p>\n

    Jujur, bagian ini masih bergerak dan saya belum mau mengklaim ada formula pasti. Yang saya yakini: arah perubahannya menguntungkan orang yang menjelaskan gambarnya dengan baik, dan merugikan yang memperlakukan gambar sebagai hiasan.<\/span><\/p>\n

    Mulai dari Satu Halaman, Bukan Seluruh Website<\/strong><\/h2>\n

    Kalau setelah membaca ini Anda merasa pekerjaannya terlalu banyak, saya setuju. Mengoptimasi seluruh media library sekaligus adalah cara tercepat untuk menunda pekerjaan ini selamanya.<\/span><\/p>\n

    Jadi begini saja. Ambil satu halaman. Yang trafiknya paling tinggi, atau yang paling menghasilkan. Cari gambar terberat di halaman itu, resize ke dimensi yang benar, konversi ke WebP, pastikan dia tidak kena lazy load, lalu ukur lagi dua hari kemudian.<\/span><\/p>\n

    Angka yang Anda lihat dari satu halaman itu yang akan menentukan seberapa serius Anda menggarap sisanya. Dalam pengalaman saya, hasil dari satu halaman biasanya cukup meyakinkan untuk membuat orang mengerjakan sepuluh halaman berikutnya tanpa perlu disuruh.<\/span><\/p>\n

    Dan kalau ternyata setelah gambar beres performanya tetap tidak bergerak, berarti penyebabnya memang di tempat lain, dan itu justru informasi yang berharga. Anda baru saja mencoret satu kemungkinan dari daftar.<\/span><\/p>\n

    Kalau Anda ingin pemeriksaannya dikerjakan menyeluruh sekaligus dipetakan mana yang berdampak paling besar lebih dulu, saya membuka layanan jasa SEO yang memang mulai dari audit teknis semacam ini. Detailnya ada di <\/span>halaman jasa SEO saya<\/span><\/a>.<\/span><\/p>\n

    Pertanyaan yang Sering Diajukan<\/strong><\/h2>\n

    Berapa ukuran file gambar yang ideal untuk website?<\/b> Patokan praktis saya: di bawah 150 KB untuk gambar header dan di bawah 80 KB untuk gambar pendukung di dalam artikel. Angka ini bukan aturan baku, tapi cukup ketat untuk menjaga kecepatan dan cukup longgar untuk menjaga kualitas visual.<\/span><\/p>\n

    Lebih baik pakai WebP atau AVIF?<\/b> WebP untuk hampir semua kasus, karena dukungannya sudah merata di semua browser utama. AVIF memberi ukuran lebih kecil lagi, tapi dukungannya belum selengkap WebP dan proses konversinya lebih berat. Kalau ragu, pilih WebP.<\/span><\/p>\n

    Apakah alt text harus selalu mengandung keyword?<\/b> Tidak. Alt text yang baik menjelaskan isi gambar dengan akurat. Kalau keyword memang muncul secara alami dalam deskripsi itu, bagus. Kalau dipaksakan, justru menurunkan kualitas sinyalnya.<\/span><\/p>\n

    Apakah lazy loading selalu baik untuk SEO?<\/b> Tidak selalu. Lazy loading bagus untuk gambar yang posisinya di bawah, tapi gambar pertama yang langsung terlihat saat halaman dibuka justru harus dimuat secepat mungkin. Kecualikan gambar itu dari lazy loading.<\/span><\/p>\n

    Apakah mengganti nama file gambar yang sudah terlanjur diunggah masih berguna?<\/b> Berguna, tapi hati hati. Mengganti nama file mengubah URL gambar, jadi gambar yang sudah punya peringkat di pencarian gambar bisa hilang sementara. Untuk gambar lama yang sudah mendatangkan trafik, biarkan saja. Terapkan aturan penamaan untuk gambar baru.<\/span><\/p>\n

    Berapa lama sampai hasil optimasi gambar terlihat?<\/b> Perbaikan kecepatan terasa langsung begitu perubahan tayang. Perubahan di data pengalaman pengguna nyata butuh waktu lebih lama karena dihitung dari rata rata beberapa minggu terakhir, jadi beri waktu sekitar satu bulan sebelum menilai.<\/span><\/p>","protected":false},"excerpt":{"rendered":"

    Ada satu pola yang hampir selalu saya temukan saat mengaudit website klien baru. Skor PageSpeed-nya merah, halaman artikel butuh lebih dari enam detik untuk benar-benar terasa siap dipakai, dan setelah ditelusuri sumbernya cuma satu: satu gambar header berukuran 3,8 MB yang diunggah apa adanya langsung dari kamera. Bukan plugin berat, bukan hosting murah, bukan tema […]<\/p>\n","protected":false},"author":1,"featured_media":1950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[564,163,567,562,566,336,565,49,561,563],"class_list":["post-1949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-on-page","tag-alt-text-gambar","tag-core-web-vitals","tag-google-lens","tag-image-seo","tag-kecepatan-website","tag-kompresi-gambar","tag-lazy-loading","tag-on-page-seo","tag-optimasi-gambar-untuk-seo","tag-webp"],"_links":{"self":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/comments?post=1949"}],"version-history":[{"count":1,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1949\/revisions"}],"predecessor-version":[{"id":1951,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/posts\/1949\/revisions\/1951"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/media\/1950"}],"wp:attachment":[{"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/media?parent=1949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/categories?post=1949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/achmadfarid.com\/en\/wp-json\/wp\/v2\/tags?post=1949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}