Büyük Görseller Sayfa Açılışını Yavaşlatıyorsa Hangi Sıra İzlenmeli?

Büyük görseller sayfa açılışını yavaşlatıyorsa önce sorunu doğrulayın

İlk hata, her yavaş açılan sayfada suçu doğrudan görsele yazmaktır. Önce Lighthouse raporunda LCP kaynağını bulun, ardından ağ şelalesinde bu isteğin ne zaman başladığını ve kaç bayt taşıdığını kontrol edin. Eğer en büyük gecikme görsel isteğinin geç keşfedilmesinden geliyorsa sorun format değil önceliklendirme olabilir; eğer dosya çok büyükse sorun çoğu zaman boyutlandırmadır.

Google Search Central’ın lazy loading rehberi, kullanıcının ilk gördüğü içerikte lazy-load kullanımının görünür gecikme yaratabileceğini açıkça söylüyor. Aynı doküman, Google Search’ün kullanıcı gibi kaydırma yapmadığını da hatırlatıyor. Bu yüzden hero görseli ile sayfa altı görselleri tek kuralla yönetmeyin. Ekip içinde ortak dil gerekiyorsa önce LCP terimi ne demek sorusunu netleştirin, sonra ölçüme dönün.

• LCP görseli: İlk ekranda görünen, geç gelirse metriği doğrudan bozan kaynaktır.
• Offscreen görseller: İlk anda görünmez; burada lazy-load genellikle doğrudur.
• CSS background veya JS ile eklenen görseller: Tarayıcı bunları daha geç keşfedebilir, bu yüzden öncelik ayrı ele alınmalıdır.

Teşhis aşamasında yalnızca dosya boyutuna bakmak yetmez. Chrome for Developers dokümanına göre eski “Properly size images” denetimi Lighthouse 13 ile daha yeni image delivery içgörülerine taşındı. Bu da 2026’da eski ekran görüntülerine değil, güncel içgörülere bakmanız gerektiği anlamına gelir. İlk kontrol için site audit bulguları ile sayfa hız verisini yan yana okumak daha sağlıklı bir başlangıç verir.

1. adım: Doğru boyutlandırma ve responsive image teslimi

En hızlı ve en güvenilir kazanım çoğu zaman burada gelir. Masaüstünde 1200 piksel genişliğinde görünen bir görseli mobilde 390 piksel ekranda da aynı dosyayla taşımak gereksiz bayt yükler. Bu yüzden önce gerçek render ölçüsünü bulun, sonra o kullanım için türev üretin. Çoğu projede format dönüşümünden önce yalnızca bu düzeltme LCP’yi hissedilir biçimde toparlar.

Google Search Central ve MDN, responsive teslim için srcset, sizes ve gerektiğinde picture kullanımını öneriyor. Pratik kural basit: aynı görsel farklı ekran genişliklerinde sadece boyut değiştiriyorsa srcset ve sizes yeterlidir; mobilde farklı kırpım gerekiyorsa picture devreye girer. Böylece tek büyük dosyayı herkese göndermek yerine tarayıcının uygun varyantı seçmesini sağlarsınız.

Bu aşamada width, height ve gerekirse aspect-ratio tanımlamak da önemlidir. Çünkü tarayıcı alanı baştan ayırır ve görsel gelmeden önce düzen stabil kalır. Bu yalnızca CLS tarafında değil, kullanıcının ilk algısında da fark yaratır. Özellikle ürün listeleme, blog kapakları ve kategori banner’larında yanlış oranlı görseller hız kadar düzen kayması üretir.

• İlk ekran görseli için gerçek render ölçüsünü baz alın.
• 2x ekranlar için makul bir üst sınır belirleyin, körü körüne dev dosya üretmeyin.
• Fallback için src özniteliğini boş bırakmayın; Google bazı durumlarda buna ihtiyaç duyar.

2. adım: AVIF, WebP, JPEG ve PNG arasında doğru formatı seçin

Boyutlandırma düzeldikten sonra format seçimi gelir. Fotoğraflarda AVIF ve WebP çoğu zaman JPEG’den daha iyi sıkıştırma verir; ancak her görseli otomatik olarak AVIF’e çevirmek doğru yaklaşım değildir. Transparan alan, keskin kenarlı grafik, ekran görüntüsü ve ikon gibi dosyalarda kalite eşiği ile işlem maliyeti birlikte değerlendirilmelidir. Küçük bir logo için modern formata geçmek yerine SVG kullanmak daha mantıklı olabilir.

Google Search Central Blog’un 30 Ağustos 2024 tarihli duyurusuna göre AVIF, Google Search tarafında destekleniyor. Bu bilgi 2026 için kritik, çünkü AVIF artık yalnızca laboratuvar tercihi değil; indekslenebilir ve operasyonel olarak uygulanabilir bir seçenek. Yine de aynı duyuruda Google, tüm siteyi düşünmeden topluca dönüştürmek yerine her görsel türünü ayrı değerlendirmeyi öneriyor.

Pratik karar matrisi şöyle çalışır: büyük fotoğraf dosyalarında önce AVIF’i deneyin; kalite eşiği bozuluyorsa WebP’ye dönün. Ekran görüntülerinde ve keskin metin içeren görsellerde WebP çoğu zaman daha dengeli sonuç verir. Şeffaflık gereken alanlarda PNG yerine WebP veya AVIF test edilebilir, ama görsel kaliteyi piksel piksel kontrol etmeden yalnızca bayt tasarrufuna göre karar vermeyin.

• Fotoğraf: Önce AVIF, gerekirse WebP.
• Ekran görüntüsü ve grafik: WebP sık sık daha dengeli davranır.
• İkon ve basit illüstrasyon: Raster yerine SVG daha doğru olabilir.

3. adım: LCP görselinde preload, fetchpriority ve lazy-load kararını verin

En çok karıştırılan bölüm burasıdır. İlk ekranda görünen hero görseline lazy-load vermek, çoğu durumda tarayıcıya “bunu bekletebilirsin” demek anlamına gelir. Google Search Central, hemen görünmesi beklenen içeriğe lazy-load eklememeyi açıkça öneriyor. Yani LCP kaynağı hero görselse varsayılan kararınız eager yükleme olmalı; lazy-load değil.

web.dev’in 10 Temmuz 2026 güncellemeli preload responsive images rehberi, kritik görsellerde preload ile fetchpriority=”high” kullanımını birlikte düşünmeyi öneriyor. Fakat bu araçlar her görsel için değil, tarayıcının geç fark ettiği net bir kritik kaynak için anlamlıdır. HTML içinde zaten erken keşfedilen sıradan bir görsele preload eklemek çoğu zaman ek karmaşa yaratır.

Hero alanı CSS background olarak geliyorsa durum daha hassastır. Google Search Central, Google’ın CSS içindeki görselleri indekslemediğini ve standart img öğelerinin daha güvenli olduğunu söylüyor. Bu nedenle mümkünse kritik hero alanını HTML img veya picture yapısına taşıyın. Slider kullanan yapılarda ise ilk slide görseli kritik, diğer slide görselleri ikincildir; hepsine aynı önceliği vermek ağ yarışına yol açar.

• HTML içindeki LCP görseli: eager, gerekirse preload ve fetchpriority.
• Sayfa altı görseller: lazy-load genellikle doğru seçimdir.
• JS ile sonradan eklenen hero görseli: mümkünse erken keşfedilecek HTML yapısına alın.

4. adım: CDN, cache ve CMS kaynaklı darboğazları en sona bırakın

CDN, image optimizer ve cache katmanı değerlidir; ama yanlış sırada kullanıldığında temel sorunu gizler. 2400 piksel bir hero görselini olduğu gibi bırakıp yalnızca CDN’e güvenmek, yanlış boyutlandırılmış sorunu tam çözmez. Önce görselin doğru varyantlarını üretin, sonra otomatik format dönüşümü ve cache ömrü gibi katmanları devreye alın. Bu sıra, neden-sonuç ilişkisini daha temiz görmenizi sağlar.

WordPress tarafında otomatik lazy-load bazen hero görseline de uygulanır; özel yazılımlarda ise yaygın sorun srcset eksikliği veya tüm cihazlara tek görsel gitmesidir. CDN kullanan yapılarda bir diğer hata, dönüşüm kuralı yazılmış olsa bile HTML’in hâlâ büyük orijinal dosyayı çağırmasıdır. Yani optimizer tek başına strateji değildir; doğru işaretleme ile birlikte çalışır.

Ölçüm tarafında düzenli tekrar şarttır. Değişiklik sonrası sayfa hızı testi ile LCP ve INP etkisini tek yerde izlemek, özellikle ekip içi operasyonlarda dağınıklığı azaltır. Ahrefs veya SEMrush benzer çevresel veriler sunabilir; SEOYEN bunu Türkiye pazarına uyarlanmış Türkçe arayüz, tek platformda SEO araçları, TL bazlı fiyatlandırma ve yerel Türkçe destek ile daha doğrudan bir iş akışına çevirir. Plan yapısını görmek isterseniz paket detayları sayfası bu açıdan yeterli bir referans noktasıdır.

Adım Adım Yavaş Açılan Büyük Görselleri Doğru Sırayla Optimize Etme

Ekip içinde kararları hızlandırmak için aşağıdaki sıra işe yarar. Buradaki mantık, önce yanlış kaynağı ayıklamak, sonra en büyük bayt kazancını almak, en sonda ise ince ayarları yapmak üzerine kuruludur.

1. Darboğazı LCP ve offscreen diye ayırın. Ağ şelalesinde en geç başlayan veya en çok bayt taşıyan isteği bulun.
2. Görseli gerçek ekran ölçüsüne indirin. Mobil ve masaüstü için tek dev dosya kullanmayın.
3. Uygun formatı seçin. AVIF veya WebP kararını görsel türüne göre verin.
4. LCP görselinin önceliğini netleştirin. Hero görselde lazy-load yerine preload ve fetchpriority düşünün.
5. CDN ve cache katmanını en sona bırakın. Temel işaretleme ve varyantlar düzelmeden otomasyona güvenmeyin.

Bu sıranın avantajı, her adımın etkisini ayrı ölçebilmenizdir. Önce boyutlandırmayı, sonra formatı, en sonda yükleme önceliğini değiştirirseniz hangi düzeltmenin gerçekten fark yarattığını net görürsünüz. 2026’da en çok zaman kazandıran yaklaşım hâlâ budur.

Saha notu: Aynı sayfada üç adım sonrası gerçek LCP farkı

Benzer denetimlerde tekrar eden patern şu: en büyük sıçrama çoğu zaman format dönüşümünden değil, doğru boyutlandırmadan gelir. Bu yüzden mini vaka akışını da aynı sırayla okumak gerekir. Örnek bir kategori sayfasında önce tek büyük hero dosyası mobil ve masaüstüne aynı şekilde gidiyordu; ilk düzeltme olarak varyant üretildi ve srcset ile sizes tanımlandı. Daha sonra uygun görseller AVIF ve WebP’ye çevrildi, son aşamada hero için fetchpriority ayarı yapıldı.

• 1. adım sonrası: Toplam görsel baytı ciddi biçimde düşer; LCP’de ilk hissedilir iyileşme burada görülür.
• 2. adım sonrası: Aynı kalite eşiğinde ek bayt tasarrufu gelir; fakat kazanç çoğu zaman ilk adımdan küçüktür.
• 3. adım sonrası: Tarayıcının kritik görseli daha erken istemesi sağlanır; özellikle geç keşfedilen hero alanlarında son rötuş etkisi yaratır.

Bu bölümün ana dersi basit: önce yanlış ölçekte dosya göndermeyi bırakın, sonra dosyayı daha iyi sıkıştırın, en son öncelik katmanını ayarlayın. Lighthouse ekranında sadece “modern format kullan” uyarısına odaklanmak bu yüzden eksik kalır. Önce ağ şelalesi mantığını okuyun; sonra her değişiklikten sonra aynı test koşuluyla tekrar ölçün. Böylece hız çalışması, rastgele bir optimizasyon listesi olmaktan çıkıp kontrollü bir teknik SEO akışına dönüşür.

Sıkça Sorulan Sorular