Kenapa Gambar WordPress Terlihat Pecah Setelah Upload (dan Cara Memperbaikinya)

Sembilan dari sepuluh kasus, gambar Anda sebenarnya tidak pecah — WordPress menurunkan resolusinya saat upload dan sekarang menyajikan salinan yang sudah dibatasi. Sejak WordPress 5.3, gambar apa pun yang lebarnya atau tingginya melebihi 2560px diam-diam diganti dengan versi -scaled yang dibatasi maksimal 2560px pada sisi terpanjangnya, dan file yang lebih kecil itulah yang diregangkan oleh tema Anda untuk mengisi hero, blok full-width, atau layar retina. Solusinya adalah membuktikan bahwa itulah yang terjadi, lalu menaikkan threshold atau berhenti meng-upload gambar yang perlu lebih besar dari kotak tempat gambar itu ditampilkan.

Kenapa ini terjadi

Saat Anda meng-upload foto, WordPress menjalankan wp_create_image_subsizes() (di wp-admin/includes/image.php). Jika sisi terpanjangnya melebihi big_image_size_threshold — 2560px secara default — WordPress memanggil _wp_image_meta_replace_original(), membuat your-photo-scaled.jpg, dan menulis ulang metadata attachment sehingga ukuran full sekarang mengarah ke salinan yang sudah di-scale. File asli Anda yang sebenarnya tetap tersimpan di disk sebagai your-photo.jpg dan direferensikan oleh wp_get_original_image_path(), tapi tidak ada satu pun di sisi front end yang menyajikannya. Setiap ukuran perantara dan setiap kandidat srcset dibuat dari file scaled 2560px, bukan dari yang Anda upload.

Jadi di sinilah pecahnya. Anda meng-upload gambar tajam 4000px untuk header full-bleed. WordPress membatasinya menjadi 2560px. Di layar standar dengan container selebar 1600px, itu tidak masalah. Di layar retina 2x, browser butuh sekitar 3200 piksel nyata untuk mengisi container itu dengan tajam, tapi hanya punya 2560, dan selisihnya di-upscale. Tepi jadi lembek, teks-di-dalam-gambar jadi buyar — persis gejala “gambar pecah setelah upload” itu.

Setengah lainnya dari masalah yang sama adalah srcset yang memilih ukuran terlalu kecil. Jika tema Anda melaporkan content width yang tidak sesuai dengan kotak render yang sebenarnya, WordPress memberi browser ukuran perantara -1024x683 atau -1536x1024 dan itu diregangkan ke atas. Penyebabnya sama — kotak tampilan lebih besar dari piksel yang tersedia — pemicunya beda.

Cek apa yang sebenarnya disajikan WordPress

Jangan menebak. Klik kanan gambar yang pecah, buka di tab baru, dan lihat nama file di URL-nya. Jika berakhiran -scaled.jpg atau ada suffix dimensi seperti -1024x683.jpg, itu sudah pasti: browser me-render turunan yang sudah diperkecil, bukan hasil upload Anda. Anda juga bisa inspect element dan membaca currentSrc untuk melihat persis kandidat mana yang dipilih browser.

Untuk melihat gambaran lengkapnya sebelum Anda upload ulang apa pun, masukkan gambar itu ke WordPress image sizes tool — tool ini menampilkan setiap turunan yang akan dibuat WordPress dari file persis itu, termasuk apakah salinan -scaled akan dibuat dan pada dimensi berapa, sehingga Anda tahu sejak awal apakah sumber Anda cukup besar untuk tempat Anda menempatkannya.

Di server, Anda bisa menampilkan daftar semua file yang dibatasi:

find wp-content/uploads -name '*-scaled.*'

Cara memperbaikinya, secara berurutan

1. Jika gambar Anda memang perlu lebih besar dari 2560px (hero besar, retina, galeri kualitas cetak), naikkan threshold-nya:

// functions.php or a small mu-plugin
add_filter( 'big_image_size_threshold', function () {
    return 3840; // longest edge, in pixels
} );

Atau matikan batasnya sepenuhnya:

add_filter( 'big_image_size_threshold', '__return_false' );

2. Upload ulang gambar yang terpengaruh. Ini langkah yang sering dilewati orang. Mengubah threshold hanya berpengaruh pada upload baru. Gambar yang sudah ada di library Anda tetap memakai metadata lamanya, dan regenerate thumbnails membangun ulang ukuran perantara dari file -scaled yang sudah dibatasi — ini tidak mengembalikan resolusi yang sudah dibuang. Cara yang andal adalah: ubah filter-nya, hapus attachment-nya, lalu upload lagi.

3. Jika sumber Anda sudah ≤2560px tapi tetap pecah, threshold bukan masalahnya — kotak tampilannya yang lebih besar dari gambar. Upload sumber yang lebih besar, atau perkecil container-nya. Untuk ketajaman retina, sumber Anda harus kira-kira dua kali lebar piksel CSS dari kotak yang diisinya.

4. Baru setelah langkah di atas, regenerate thumbnails agar ukuran perantara konsisten — tapi pahami ini pembersihan, bukan obat.

Yang tidak boleh dilakukan

Jangan naikkan kualitas JPEG ke 100. WordPress mengompres ke kualitas default 82 lewat wp_editor_set_quality, dan separuh saran di internet menyuruh Anda menimpanya:

add_filter( 'wp_editor_set_quality', function () { return 90; } );

Itu boleh saja untuk mengurangi artefak kompresi, tapi gambar yang diregangkan dan di-upscale adalah masalah resolusi, bukan kompresi. Naik dari 82 ke 100 hanya membengkakkan ukuran file Anda dan hampir tidak berpengaruh pada kelembekan yang Anda lihat.

Jangan matikan -scaled secara refleks. Mematikan batas (ada tool-nya untuk itu) adalah langkah yang tepat jika Anda menyajikan gambar di atas 2560px — tapi jika masalah sebenarnya adalah ukuran perantara yang terlalu kecil ikut diregangkan, mematikannya tidak mengubah apa pun dan Anda kehilangan penghematan bandwidth tanpa alasan. Diagnosis dulu.

Jangan langsung menyalahkan cache atau regenerate thumbnails. Regenerasi membaca dari sumber yang sama-sama sudah dibatasi, jadi tidak bisa mengembalikan detail. Membersihkan CDN atau page cache tidak akan menyentuh file yang memang sudah kecil di disk sejak awal.

Jangan mengandalkan CSS tema atau object-fit. Styling sebanyak apa pun tidak menambah piksel. Jika file yang disajikan berakhiran -scaled atau suffix dimensi, file-nya yang jadi masalah, bukan layout-nya.

Masih buntu?

Jika Anda sudah memastikan file yang disajikan adalah hasil upload resolusi penuh Anda — tanpa -scaled, tanpa suffix dimensi — tapi tetap lembek, cek apakah ada plugin (optimizer, image-resizer CDN, atau library lazy-load) yang menulis ulang src Anda ke proxy yang terkompresi. Jalankan gambar itu lewat image sizes tool untuk memastikan apa yang seharusnya dibuat WordPress, lalu bandingkan dengan apa yang sebenarnya dimuat browser. Ketika keduanya tidak cocok, ada sesuatu di antara WordPress dan browser yang jadi biang keladinya.