Sayfa Hızı Optimizasyonu ve Core Web Vitals Rehberi

Hız skorunu yükseltmeye çalışırken asıl sorunu ıskalamak kolaydır; sayfa hızı optimizasyonunda işe yarayan yol, gerçek ziyaretçilerin yaşadığı deneyimi ölçmek ve sorunu sitenin hangi bileşeninin yarattığını bulmaktır. Bu rehber, saha ve laboratuvar verisini ayırır, üç Core Web Vitals metriğini içerik sitelerinin tipik parçalarıyla eşler ve düzeltmeleri etki, emek ve riske göre sıralamanız için bir çerçeve verir.

Reklam yerleşimi kaynaklı sorunlar ayrı bir konudur ve reklam ve Core Web Vitals dengesi yazısında ele alınır; burada reklamsız bir blog, kurumsal site ya da katalog sitesinin genel bileşenlerine odaklanıyoruz.

Sayfa Hızı Optimizasyonu Neden Gündeme Gelir

Hız konusu genellikle üç yoldan gündeme gelir: bir geliştirici PageSpeed Insights'tan kırmızı bir skor görür, Search Console'da “iyileştirme gerekiyor” uyarısı çıkar ya da bir ziyaretçi sayfanın geç açıldığından yakınır. Bu üç sinyal farklı şeyleri ölçer ve aynı sonuca götürmez; birini öbürüyle karıştırmak, yanlış işe zaman harcatır.

Hızın önemi iki ayrı eksende okunur. Birincisi kullanıcı deneyimidir: sayfa geç açılır, tıklamaya geç yanıt verir ya da okurken yer değiştirirse ziyaretçi sayfadan ayrılır. İkincisi aramadır: Google, iyi Core Web Vitals değerlerini arama başarısı için önerir ve sayfa deneyimini sıralama sistemlerinin ödüllendirmek istediği şeylerle uyumlu görür. Ancak aynı belge bu metriklerin sıralamadaki ağırlığını belirtmez; bu yüzden “hızlanırsak sıralamamız yükselir” gibi bir beklenti kurmak doğru olmaz.

Hız çalışmasını mantıklı kılan, neyi ölçtüğünüzü bilmektir. Önce hangi metrikte, hangi cihaz grubunda ve hangi sayfa grubunda sorun olduğunu görün; ardından sorunu yaratan bileşene inin. Rastgele “sıkıştırma eklentisi kurmak” ya da tüm betikleri ertelemek gibi genel müdahaleler, çoğu kez sorunun asıl kaynağına dokunmaz ve yeni bozulmalara yol açabilir.

Core Web Vitals: LCP, INP ve CLS Ne Ölçer

Core Web Vitals üç metrikten oluşur ve her biri deneyimin farklı bir yanını ölçer.

• LCP (Largest Contentful Paint): Görünür alandaki en büyük görselin, metin bloğunun ya da videonun ekranda tamamlanma zamanını ölçer. Sayfanın ne zaman “yüklenmiş gibi” hissettirdiğinin göstergesidir.
• INP (Interaction to Next Paint): Tıklama, dokunma ve tuş basma gibi etkileşimlerden sonra tarayıcının görsel geri bildirimi çizmesine kadar geçen gecikmeyi ölçer. Sayfa ziyareti boyunca tek bir özet değer raporlar; kaydırma, üzerine gelme ve yakınlaştırma sayılmaz.
• CLS (Cumulative Layout Shift): Sayfa ömrü boyunca içeriğin beklenmedik biçimde yer değiştirmesini ölçer. Kullanıcı girdisinden hemen sonra olan kaymalar beklenen sayıldığı için dışarıda kalır.

Web.dev'in Core Web Vitals genel bakışı (yeni sekmede açılır) eşikleri şöyle verir: LCP için 2,5 saniye ve altı, INP için 200 milisaniye ve altı, CLS için 0,1 ve altı “iyi” kabul edilir. Daha ayrıntılı metrik sayfaları orta aralığı da belirtir: LCP için 2,5 ile 4 saniye arası, INP için 200 ile 500 milisaniye arası ve CLS için 0,1 ile 0,25 arası “iyileştirme gerekir”, bunların üstü ise “zayıf” sayılır. Değerlendirme, sayfa yüklemelerinin 75. yüzdeliğinde ve mobil ile masaüstü ayrı ayrı yapılır. Bir sayfanın geçmesi için üç metriğin de hedefi tutturması gerekir. INP, daha önce kullanılan FID metriğinin ardılı olarak tanımlanır.

Saha Verisi ile Laboratuvar Verisini Ayırmak

Hız tartışmalarında en sık yapılan hata, iki veri türünü aynı şey sanmaktır. Saha verisi, gerçek ziyaretçilerin gerçek cihazlarında ve ağlarında yaşadığı deneyimden toplanır. Laboratuvar verisi ise kontrollü bir ortamda, sabit bir cihaz ve ağ profiliyle yapılan simülasyonlardan gelir.

Saha verisi neyi söyler

Saha verisi, “gerçekte ne oluyor” sorusunun cevabıdır. Core Web Vitals'ın üç metriği de öncelikle saha metrikleridir ve Google'ın değerlendirme çerçevesi bu veriye dayanır. Zayıf cihazlar, yavaş ağlar, farklı ülkeler ve gerçek etkileşim kalıpları bu veride yansır. Dezavantajı, sorunun nedenini söylememesidir: sayı kötüyse neden kötü olduğunu başka araçlarla aramanız gerekir.

Laboratuvar verisi neyi söyler

Laboratuvar ölçümü tekrarlanabilir olduğu için bir değişikliğin etkisini hemen görmeye yarar. Geliştirme sırasında yararlıdır, ancak saha ölçümünün yerini tutmaz. Bir de teknik fark vardır: Lighthouse gibi araçlar gerçek bir kullanıcı girdisi olmadığı için INP'yi ölçemez; yerine Total Blocking Time gibi bir vekil metrik gösterir. Bu yüzden laboratuvar skorunda INP yoksa sorun yok anlamına gelmez; sadece o ortam o metriği göremiyordur.

Pratik kural şudur: karar vermek için saha verisine, neden aramak ve düzeltmeyi denemek için laboratuvar verisine bakın.

Search Console ve PageSpeed Insights Raporlarını Okumak

İki araç farklı roller üstlenir. Search Console'daki Core Web Vitals raporu, Search Console Yardım'da anlatıldığı (yeni sekmede açılır) gibi gerçek kullanıcı verisine, yani CrUX raporuna dayanır. Mobil ve masaüstü ayrı raporlanır, URL'ler benzer sayfa gruplarında toplanır ve bir grubun durumu en zayıf metriğine göre belirlenir. Yeterli veri yoksa bir grup raporda görünmeyebilir; yeni bir sitede verinin birkaç gün sonra belirmesi de normaldir.

PageSpeed Insights ise iki bölümlü bir tablo sunar: üstte varsa gerçek kullanıcı verisi, altta ise o anda çalıştırılan laboratuvar analizi. Bu ayrımı okurken iki soruyu sorun:

1. Gerçek kullanıcı bölümünde bu URL ya da alan adı için veri var mı ve metrikler hangi aralıkta?
2. Laboratuvar bölümündeki öneriler, saha tarafında kötü çıkan metriğin nedenini açıklıyor mu?

Laboratuvar skoru yüksek, saha verisi kötü çıkıyorsa, gerçek kullanıcıların koşulları test ortamından daha zordur: eski cihazlar, kalabalık ağ, tarayıcı eklentileri ya da yalnızca oturum açmış kullanıcılarda yüklenen bileşenler. Tersi durumda, yani laboratuvar kötü, saha iyi ise, çoğu zaman test profili gerçek kitlenizden daha zayıftır. İki veriyi çelişki değil, tamamlayıcı olarak okuyun. Sayfa deneyimi konusundaki resmi çerçeve için Google Search Central'ın Core Web Vitals sayfası (yeni sekmede açılır) da başvurulacak kaynaktır.

LCP: Görsel, Sunucu Yanıtı ve Kaynak Öncelikleri

LCP öğesi içerik sitelerinde çoğunlukla ilk ekrandaki büyük görseldir; bazen de büyük bir başlık bloğudur. Ölçüm, sayfaya gidildiği andan başladığı için sunucu yanıt süresi, yönlendirmeler ve bağlantı kurulumu da bu sürenin içindedir. Bu yüzden LCP'yi iyileştirirken iki yere bakmak gerekir: öğe ne zaman bulunuyor ve ne zaman yükleniyor.

Sık görülen nedenler ve karşılıkları şöyledir:

• Yavaş sunucu yanıtı: Önbellek yok ya da sayfa her istekte yeniden üretiliyor. Sunucu tarafında önbellekleme, veritabanı sorgularını azaltma ve gereksiz yönlendirmeleri kaldırma ilk adımdır. Sunucu davranışını görmek için SEO için sunucu log analizi yazısındaki yaklaşım işe yarar.
• Ağır ya da yanlış boyutlu görsel: Kapak görseli gereğinden büyük boyutta ve eski biçimde sunuluyor. Görselin uygun boyutta, sıkıştırılmış ve WebP gibi modern biçimde olması gerekir; ayrıntılar için görsel SEO ve Google Görseller optimizasyonu yazısına bakın.
• İlk ekran görselinin ertelenmesi: Tembel yükleme (lazy loading) ekran altı görseller için doğrudur; LCP öğesine uygulanırsa yükleme gecikir.
• Geç keşfedilen kaynak: Görsel, betikle ya da stil dosyasıyla sonradan ekleniyorsa tarayıcı onu geç fark eder. Öğenin HTML'de doğrudan yer alması ve gerekirse öncelik ipucuyla işaretlenmesi yardımcı olur.

Önce LCP öğesinin hangisi olduğunu geliştirici araçlarından doğrulayın; tahminle çalışmak, yanlış görseli optimize etmenize yol açar.

INP: Üçüncü Taraf Script ve Etkileşim Gecikmesi

INP, sayfanın tıklamaya ya da dokunmaya ne kadar çabuk görsel yanıt verdiğini ölçer. Gecikme üç parçadan oluşur: girdinin işlenmeye başlamasını bekleyen süre, işleyicilerin çalışma süresi ve sonuçların ekrana çizilmesi. Ana iş parçacığı meşgulse, yani tarayıcı o anda uzun bir betiği çalıştırıyorsa, kullanıcı tıklasa bile yanıt gecikir.

İçerik sitelerinde ana iş parçacığını en çok meşgul eden şeyler genellikle sitenin kendi kodu değil, sonradan eklenen betiklerdir: analitik, etiket yöneticisi, sohbet pencereleri, kayan paylaşım düğmeleri, A/B test araçları ve gömülü widget'lar. Her biri tek başına küçük görünür, ama birlikte uzun görevler üretir.

Üçüncü taraf kaynaklı INP sorununu azaltmak için şunları deneyin:

1. Yüklü her betiğin bir sahibi ve bir gerekçesi olduğundan emin olun; kimsenin kullanmadığı betikleri kaldırın.
2. Kritik olmayan betikleri sayfa etkileşime hazır olduktan sonra yükleyin.
3. Tıklamaya bağlanan işleyicilerde ağır hesaplamaları bölün ve yalnız gerekli olanı o anda çalıştırın.
4. Menü, filtre ve arama gibi sık kullanılan arayüzlerde DOM'un gereksiz büyümesini önleyin.

Betiklerin tarayıcıda nasıl çalıştığı ve işlenmesi konusunda JavaScript SEO, rendering ve indeksleme yazısı tamamlayıcı bir bakış sunar. Unutmayın: INP laboratuvar ortamında doğrudan ölçülemez; gerçek etkileşim verisi ve geliştirici araçlarındaki performans kayıtları birlikte okunmalıdır.

CLS: Yer Tutucu, Font ve Dinamik Alanlar

CLS, içeriğin yükleme sırasında ya da sonrasında yer değiştirmesini ölçer. Kayma puanı, kaymadan etkilenen alanın büyüklüğü ile içeriğin ne kadar uzağa hareket ettiğinin çarpımıdır. Ölçüm, 5 saniyeyi geçmeyen kayma pencereleri halinde toplanır ve en yüksek pencere raporlanır. Kullanıcı girdisinden hemen sonra olan kaymalar beklenen sayılır.

İçerik sitelerinde CLS'in sık görülen kaynakları ve çözümleri şunlardır:

• Boyutu belirtilmemiş görseller ve videolar: Genişlik ve yükseklik niteliklerini ya da en-boy oranını tanımlayın; tarayıcı yüklemeden önce yer ayırsın.
• Font değişimi: Web fontu yüklenince metnin genişliği değişir ve satırlar kayar. Font sunumunu ve yedek font ölçülerini yakın tutmak kaymayı azaltır.
• Sonradan eklenen bantlar: Çerez bildirimi, kampanya şeridi ya da abonelik kutusu içeriği aşağı itiyorsa, bu alanı baştan ayırın ya da içeriği itmeyen bir konumda gösterin.
• Gömülü içerikler: Harita, video ya da sosyal medya yerleştirmelerine sabit bir kutu tanımlayın.

Tek bir yer tutucu kuralı çoğu kaymayı çözer: dinamik olarak gelecek her şey için sayfa ilk çizildiğinde yeri hazır olmalıdır. Bunu bir tasarım ilkesi olarak ekibin ortak kuralına dönüştürürseniz, yeni eklenen bileşenler de aynı sorunu üretmez.

İçerik Sitelerinde Sık Görülen Hız Hataları

Bir içerik sitesi hızını çoğu zaman birkaç tekrar eden hata belirler. Bunları bilmek, sorun avına başlarken doğru yerden bakmanızı sağlar.

• Gereğinden büyük kapak görselleri: Yazı başına yüklenen yüksek çözünürlüklü görsel, mobilde küçücük görünse de tam boyutta indirilir. Duyarlı boyutlar ve sıkıştırma sorunun çoğunu çözer.
• Çok sayıda font ağırlığı: Kullanılmayan kalınlık ve stil varyantları gereksiz indirme yükü getirir.
• Kullanılmayan eklenti ve betikler: Eski bir kampanyadan kalan, artık hiçbir işe yaramayan betikler her sayfa görüntülemesinde çalışmaya devam eder.
• Sunucu önbelleğinin olmaması: Değişmeyen bir blog yazısının her istekte yeniden üretilmesi, yanıt süresini boşuna yükseltir.
• Çok fazla yönlendirme: Eski URL'lerden yeni URL'lere zincirleme yönlendirme, ilk baytın gelmesini geciktirir.
• Düzensiz sayfa şablonları: Bir şablon hatası yüzlerce sayfaya yayılır; sorun tek sayfada değil, şablonda aranmalıdır.

Bu hataların ortak yanı, çoğunun teknik olarak karmaşık olmaması, yalnızca düzenli bir denetim eksikliğinden doğmasıdır. Tarama verimliliğiyle ilişki kurmak isterseniz, hız sorunları büyük sitelerde tarama bütçesi optimizasyonu ile de kesişir; yavaş yanıt veren sunucu hem ziyaretçiyi hem tarayıcıyı yorar.

Düzeltme Önceliği: Etki, Emek ve Risk

Elinizde onlarca öneri olduğunda hepsini aynı anda yapmak ne mümkün ne de gerekli. Önceliği üç ölçütle kurun: düzeltmenin kaç sayfayı ve hangi metriği etkilediği, işin ne kadar emek istediği ve değişikliğin site işlevini bozma riski.

1. Önce şablon düzeyindeki ve düşük riskli işler: Görsel boyutları, kullanılmayan betiklerin kaldırılması ve yer tutucular gibi tek değişiklikle çok sayfayı etkileyen işler.
2. Sonra metriğe doğrudan bağlı orta emekli işler: LCP görselinin keşfedilmesi, font yükleme stratejisi, sunucu önbelleği.
3. En sona yüksek riskli ve geniş kapsamlı işler: Temanın yeniden yapılandırılması, betik mimarisinin değiştirilmesi, barındırma değişikliği.

Şöyle bir durumu düşünün: bir blogda Search Console mobil için LCP'nin zayıf olduğunu gösteriyor. Geliştirici incelemesinde kapak görselinin çok büyük olduğu ve tembel yüklemeyle geciktirildiği anlaşılıyor. İlk müdahale, tek şablon değişikliği ve görsel yeniden boyutlandırmasıdır; temayı yeniden yazmak bu aşamada gereksizdir. Bu sıra, düşük riskle en büyük etkiyi arar ve her adımdan sonra ölçüm yapmanıza imkân verir.

Düzeltmeyi Doğrulamak ve Gerilemeyi Önlemek

Bir düzeltmeyi yayına aldıktan sonra sonucu iki aşamada doğrulayın. Önce laboratuvar ortamında aynı sayfayı değişiklikten önceki ve sonraki haliyle karşılaştırın; amaç, düzeltmenin beklenen metriği iyileştirdiğini hızla görmektir. Sonra saha verisini bekleyin. Gerçek kullanıcı verisi sürekli birikir ve raporlara yansıması zaman alır, bu yüzden Search Console'da sonuç görmek için günler ya da haftalar geçmesi normaldir; sabit bir süre vaat edilemez.

İkinci iş gerilemeyi önlemektir. Hız, bir kez düzeltilip unutulan bir konu değildir; her yeni betik, görsel ya da bileşen eski kazanımı bozabilir. Şu alışkanlıklar yardımcı olur:

• Yeni betik ya da eklenti eklemeden önce etkisini ölçen kısa bir kontrol adımı koyun.
• Önemli şablonlar için laboratuvar ölçümünü düzenli aralıklarla yineleyin.
• Search Console raporunda “zayıf” grupların sayısını aylık izleyin.
• İçerik ekibine görsel boyutu ve biçimi için basit bir yükleme kuralı verin.

Genel site sağlığı denetimi içinde hızı da düzenli bir kalem olarak görmek için içerik denetimi nasıl yapılır yazısındaki yaklaşımı kullanabilirsiniz. Böylece hız, tek seferlik bir proje değil, rutin bir kalite kontrolü olur.

Örnek Şablon: Core Web Vitals Düzeltme Önceliği Tablosu

Düzeltme listenizi sıralamak için bir taslak tablo aşağıda. Sayfa grupları, metrik değerleri ve notlar örnek değerlerdir ve kurgudur; yerlerine kendi Search Console ve PageSpeed Insights verinizi yazın.

Bu örnek senaryoda küçük bir haber blogunun mobil sayfa gruplarında üç ayrı sorun görülüyor; satırlar bu sorunları öncelik sırasına dizmek için kurgulandı.

Tablo, her sorunu aynı önemde görmemenizi sağlar: ilk iki satır kısa sürede kazanım getirir, son iki satır daha fazla koordinasyon ister. Her satırın yanına bir ölçüm tarihi yazmak, düzeltmenin gerçekten işe yarayıp yaramadığını sonradan kanıtlamanızı sağlar.

Sıkça Sorulan Sorular

Core Web Vitals nedir?

Core Web Vitals, Google'ın sayfa deneyimini ölçmek için kullandığı üç metriktir: LCP yükleme hızını, INP etkileşime yanıt gecikmesini, CLS ise görsel kararlılığı ölçer. Değerlendirme gerçek kullanıcı verisinin 75. yüzdeliğine göre, mobil ve masaüstü için ayrı yapılır. Bir sayfanın geçmesi için üç metriğin de hedefi tutturması gerekir.

İyi bir LCP süresi kaç saniyedir?

İyi bir LCP süresi 2,5 saniye ya da altıdır. Web.dev'e göre 2,5 ile 4 saniye arası iyileştirme gerektirir, 4 saniyenin üstü zayıf sayılır. Değerlendirme, sayfa yüklemelerinin 75. yüzdeliğinde ve mobil ile masaüstü için ayrı yapılır; tek bir hızlı deneme sonucu yeterli kanıt değildir.

Core Web Vitals sıralama faktörü mü?

Core Web Vitals, Google'ın sayfa deneyimi değerlendirmesinin bir parçasıdır ve iyi değerler arama başarısı için önerilir. Ancak Google bu metriklerin sıralamadaki ağırlığını belirtmez; alaka ve içerik kalitesi belirleyici olmaya devam eder. Hız çalışması sıralama artışı vaadi olarak değil, deneyim iyileştirmesi olarak ele alınmalıdır.

Sayfa hızı nasıl ölçülür?

Sayfa hızı hem saha hem laboratuvar verisiyle ölçülür. Search Console'daki Core Web Vitals raporu ve PageSpeed Insights'ın gerçek kullanıcı bölümü saha verisini verir. PageSpeed Insights'ın laboratuvar bölümü ve Chrome DevTools ise sorunun nedenini aramak ve düzeltmeyi denemek için kullanılır. İki veri türünü birlikte okumak gerekir.

Siteyi hızlandırmak için ilk ne yapılmalı?

İlk adım, sorunun hangi metrikte ve hangi sayfa grubunda olduğunu saha verisiyle belirlemektir. Çoğu içerik sitesinde ardından büyük ya da yanlış yüklenen görselleri ve sunucu yanıt süresini incelemek, genellikle düşük riskle büyük kazanım sağlar. Rastgele eklenti kurmak yerine, nedeni bulduktan sonra müdahale edin.

Mobil sayfa hızı neden masaüstünden düşük çıkar?

Mobil ölçüm, daha zayıf cihaz ve ağ koşullarını simüle ettiği için genellikle daha düşük çıkar. Gerçek kullanıcı verisinde de mobil ziyaretçiler çoğunlukla daha sınırlı donanım ve bağlantıyla gelir. Bu yüzden Core Web Vitals mobil ve masaüstü için ayrı değerlendirilir; mobil sonucu önceliklendirmek genellikle daha gerçekçidir.

Sonuç ve Sonraki Adım

Hız çalışmasında kazandıran akış, sorunu saha verisiyle bulup nedenini laboratuvar verisiyle araştırmak, düzeltmeleri etki, emek ve riske göre dizmek ve sonucu hem kısa hem uzun vadede doğrulamaktır. Skor yerine metrik eşiği ve gerçek kullanıcı deneyimi esas alındığında, hız çalışması abartılı beklentilerden arınır.

Hız denetimi sonunda düzeltilecek sayfa metinleri, görsel açıklamaları ya da yeniden yazılması gereken içerikler çıkarsa makale yazdırma seçeneklerini inceleyebilirsiniz. Ürün seçimi, sepet ve ödeme adımları, satıcı onayı ve teslimat bildirimi sırasıyla ilerler; gerekirse itiraz süreci kullanılır. Önce önceliklendirme tablosunu kendi verinizle doldurmak, hangi içeriğe gerçekten ihtiyaç duyduğunuzu netleştirir.