WordPress Görselleri Yükledikten Sonra Neden Bulanık Görünüyor (ve Çözümü)

On seferin dokuzunda görselleriniz aslında bulanık değildir — WordPress bunları yükleme sırasında küçültmüş ve şimdi de o sınırlandırılmış kopyayı sunuyordur. WordPress 5.3’ten bu yana, genişliği veya yüksekliği 2560px’i aşan her görsel, en uzun kenarı 2560px ile sınırlanmış bir -scaled sürümüyle sessizce değiştirilir ve temanızın bir hero alanını, tam genişlikte bir bloğu ya da retina ekranı doldurmak için gerdiği dosya işte o küçük dosyadır. Çözüm, önce durumun gerçekten böyle olduğunu kanıtlamak, ardından ya eşiği yükseltmek ya da oturduğu kutudan daha büyük olması gereken görseller yüklemekten vazgeçmektir.

Neden oluyor

Bir fotoğraf yüklediğinizde WordPress, wp_create_image_subsizes() fonksiyonunu (wp-admin/includes/image.php içinde) çalıştırır. En uzun kenar big_image_size_threshold değerinden — varsayılan olarak 2560px — büyükse, _wp_image_meta_replace_original() çağrılır, your-photo-scaled.jpg üretilir ve ek dosya meta verisi yeniden yazılır; böylece full boyutu artık ölçeklenmiş kopyayı gösterir. Gerçek orijinaliniz your-photo.jpg olarak diskte tutulur ve wp_get_original_image_path() tarafından referans alınır, ancak ön yüzde hiçbir şey onu sunmaz. Her ara boyut ve her srcset adayı, yüklediğiniz dosyadan değil, 2560px’lik ölçeklenmiş dosyadan üretilir.

İşte bulanıklığın kaynağı burada. Tam genişlikte bir başlık için net, 4000px’lik bir görsel yüklüyorsunuz. WordPress bunu 2560px ile sınırlıyor. Standart bir ekranda, 1600px genişliğinde bir kapsayıcıda bu sorun değil. Ancak 2x retina ekranda tarayıcının o kapsayıcıyı net dolduracak yaklaşık 3200 gerçek piksele ihtiyacı var, elinde ise yalnızca 2560 var ve aradaki farkı büyüterek dolduruyor. Yumuşamış kenarlar, ezik görünen görsel içi metinler — tam olarak “yükledikten sonra bulanık” belirtisi.

Aynı sorunun diğer yarısı ise srcset’in fazla küçük bir boyut seçmesidir. Temanız, gerçekte işlenen kutuya uymayan bir içerik genişliği bildirirse, WordPress tarayıcıya -1024x683 veya -1536x1024 gibi bir ara görsel verir ve bu da yukarı doğru gerilir. Aynı neden — görüntüleme kutusu mevcut pikselden büyük — farklı bir tetikleyici.

WordPress’in gerçekte ne sunduğunu kontrol edin

Tahmin yürütmeyin. Bulanık görsele sağ tıklayın, yeni bir sekmede açın ve URL’deki dosya adına bakın. -scaled.jpg ile ya da -1024x683.jpg gibi bir boyut ekiyle bitiyorsa, durumu doğrulamış olursunuz: tarayıcı yüklediğiniz dosyayı değil, küçültülmüş bir türevini işliyordur. Ayrıca öğeyi inceleyip currentSrc değerini okuyarak tarayıcının tam olarak hangi adayı seçtiğini görebilirsiniz.

Herhangi bir şeyi yeniden yüklemeden önce tüm tabloyu görmek için görseli WordPress image sizes aracına bırakın — bu araç, WordPress’in tam olarak o dosyadan üreteceği her türevi gösterir; bir -scaled kopya oluşturulup oluşturulmayacağı ve hangi boyutta oluşturulacağı dahil. Böylece kaynağınızın yerleştirdiğiniz alan için yeterince büyük olup olmadığını en baştan bilirsiniz.

Sunucuda, sınırlandırılmış her dosyayı listeleyebilirsiniz:

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

Nasıl düzeltilir, sırasıyla

1. Görselleriniz gerçekten 2560px’ten büyük olmalıysa (büyük hero’lar, retina, baskı kalitesinde galeriler), eşiği yükseltin:

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

Ya da sınırı tamamen kapatın:

add_filter( 'big_image_size_threshold', '__return_false' );

2. Etkilenen görselleri yeniden yükleyin. İnsanların atladığı adım budur. Eşiği değiştirmek yalnızca yeni yüklemeleri etkiler. Kütüphanenizde zaten bulunan görseller eski meta verilerini korur ve thumbnail’ları yeniden üretmek, ara boyutları sınırlandırılmış -scaled dosyasından yeniden oluşturur — atılan çözünürlüğü geri eklemez. Güvenilir yol şudur: filtreyi değiştirin, ek dosyayı silin, yeniden yükleyin.

3. Kaynağınız zaten ≤2560px ise ve hâlâ bulanıksa, sorun eşik değil — görüntüleme kutusu görselden büyüktür. Daha büyük bir kaynak yükleyin ya da kapsayıcıyı küçültün. Retina netliği için kaynağınızın, doldurduğu kutunun CSS piksel genişliğinin kabaca iki katı olması gerekir.

4. Ancak yukarıdakilerden sonra thumbnail’ları yeniden üretin ki ara boyutlar tutarlı olsun — ama şunu bilin, bu bir tedavi değil, temizliktir.

Yapılmaması gerekenler

JPEG kalitesini 100’e çıkarmayın. WordPress, wp_editor_set_quality aracılığıyla varsayılan 82 kalitesine sıkıştırır ve internetteki tavsiyelerin yarısı bunu geçersiz kılmanızı söyler:

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

Sıkıştırma artefaktlarını azaltmak için bu iyidir, ancak gerilip büyütülmüş bir görsel bir çözünürlük sorunudur, sıkıştırma sorunu değil. 82’den 100’e çıkmak dosyalarınızı şişirir ve gördüğünüz yumuşaklığa neredeyse hiçbir katkı yapmaz.

Refleks olarak -scaled’ı devre dışı bırakmayın. Sınırı kapatmak (bunun için bir araç var) doğru karardır eğer 2560px’in üzerinde görsel sunuyorsanız — ama asıl sorununuz fazla küçük bir ara boyutun gerilmesiyse, bunu devre dışı bırakmak hiçbir şeyi değiştirmez ve bant genişliği tasarrufunu boşuna kaybedersiniz. Önce teşhis edin.

Önce önbelleği suçlamayın ya da thumbnail’ları yeniden üretmeyin. Yeniden üretim aynı sınırlandırılmış kaynaktan okur, dolayısıyla detayı geri getiremez. Bir CDN’yi ya da sayfa önbelleğini temizlemek, diskte en baştan küçük olan bir dosyaya hiçbir etki yapmaz.

Temanın CSS’ine ya da object-fit’e sarılmayın. Hiçbir stil ekleme piksel eklemez. Sunulan dosya -scaled ile ya da bir boyut ekiyle bitiyorsa, sorun dosyadadır, düzende değil.

Hâlâ takıldınız mı?

Sunulan dosyanın tam çözünürlüklü yüklemeniz olduğunu doğruladıysanız — -scaled yok, boyut eki yok — ve hâlâ yumuşaksa, bir eklentinin (bir optimizasyon aracı, bir CDN görsel yeniden boyutlandırıcısı ya da bir lazy-load kütüphanesi) src değerinizi sıkıştırılmış bir proxy’ye yeniden yazıp yazmadığını kontrol edin. Görseli image sizes aracından geçirip WordPress’in ne üretmesi gerektiğini doğrulayın, ardından bunu tarayıcının gerçekte yüklediğiyle karşılaştırın. İkisi birbirini tutmadığında, WordPress ile tarayıcı arasındaki bir şey suçludur.