Web Sitesi Hızlandırma: Core Web Vitals Rehberi

Web sitesi hızlandırma, üç Core Web Vitals metriğini Google'ın eşiklerine çekmek demektir: LCP 2,5 saniyenin altında, INP 200 milisaniyenin altında, CLS 0,1'in altında. Bu eşikleri gerçek ziyaretçilerinizin %75'i görmelidir; ölçüt laboratuvar testi değil, saha verisidir.

Çoğu site sahibi hız konusunu bir skorla eşitliyor. PageSpeed Insights'ta yeşil 90 görünce rahatlıyor, turuncu 60 görünce panikliyor. Oysa Google'ın sıralama sistemlerine giden veri o skor değil; Chrome kullanıcılarının sitenizde yaşadığı gerçek deneyim. Bu rehberde hem metriklerin ne anlama geldiğini hem de hangi müdahalenin gerçekten fark yarattığını sırayla ele alıyoruz.

İçindekiler

• Yavaş Site Ne Kaybettiriyor?
• Core Web Vitals: Üç Metrik, Üç Eşik
• 2026'da Neyin Değiştiği, Neyin Değişmediği
• Sitenizin Gerçek Hızını Ölçmek: Lab mı, Saha mı?
• LCP'yi 2,5 Saniyenin Altına Çekmek
• Görsel Optimizasyonu: En Hızlı Kazanç
• INP: Tıkladıktan Sonraki Donma
• CLS: Sayfanın Zıplamasını Durdurmak
• Üçüncü Parti Scriptlerin Gerçek Faturası
• Önbellek, CDN ve Sunucu Tarafı
• 30 Günlük Hızlandırma Yol Haritası
• Sıkça Sorulan Sorular

Yavaş Site Ne Kaybettiriyor?

Hız tartışması teknik bir konu gibi görünse de faturası doğrudan ciroya çıkıyor. Google ve Deloitte'un perakende sitelerinde yürüttüğü "Milliseconds Make Millions" çalışmasında, mobil hızda yalnızca 0,1 saniyelik iyileşme dönüşüm oranını %8,4, ortalama sepet tutarını %9,2 yükseltti. Yani ölçek milisaniye; etki yüzde.

Tek bir markanın rakamları da aynı yönü gösteriyor. Vodafone, web.dev'de yayımlanan vaka çalışmasında LCP değerini %31 iyileştirdiğinde satışlarda %8, sepet/ziyaret oranında %11 artış raporladı. Değişiklikler dramatik değildi: widget'ları sunucu tarafında render etmek, kritik HTML'i erken göndermek ve görselleri doğru boyutta sunmak.

Kötü haber şu: bu eşiği geçen site hâlâ azınlıkta. HTTP Archive Web Almanac 2025 performans bölümüne göre mobilde sitelerin yalnızca %48'i üç Core Web Vitals metriğinin hepsinden "iyi" alıyor; masaüstünde bu oran %56. Rakiplerinizin yarısından fazlası sınıfta kalıyorsa, web sitesi hızlandırma çalışması sizin için ucuz bir rekabet avantajı demektir.

Kaybın bir de görünmeyen tarafı var. Yavaş bir açılış sayfası, reklam bütçenizin verimini doğrudan düşürür: Google Ads'te tıklama başına ödediğiniz ücret aynı kalırken, sayfa açılmadan geri dönen her ziyaretçi müşteri edinme maliyetinizi yukarı taşır. Aynı bütçeyle daha az müşteri kazanırsınız ve bunu raporda "reklam performansı düştü" olarak görürsünüz. Bu yüzden web sitesi hızlandırma bütçesini ayrı bir teknik gider gibi değil, mevcut pazarlama bütçenizin verimini artıran bir kaldıraç olarak değerlendirin.

Arama tarafında da tablo net. Core Web Vitals tek başına sıralamayı belirleyen bir düğme değil; ancak içerik kalitesi ve otorite bakımından benzer sayfalar yarışırken terazinin dengesini bozan sinyallerden biri. Aynı sorguda iki iyi içerikten biri 4 saniyede, diğeri 1,8 saniyede açılıyorsa Google'ın tercihini tahmin etmek zor değil.

Core Web Vitals: Üç Metrik, Üç Eşik

Google üç metriği web.dev'in Web Vitals dokümanında tanımlıyor. Eşikler şöyle:

Google üç metriği de 75. yüzdelik üzerinden değerlendirir; mobil ve masaüstünü ayrı ayrı hesaplar. Yani ziyaretlerinizin dörtte üçü eşiği görmelidir; ortalama iyi olsa bile kuyruktaki kötü deneyimler sizi düşürebilir.

Metriklerin adları teknik dursa da ölçtükleri şey son derece sıradan: sayfa ne zaman göründü, tıklayınca ne zaman tepki verdi, okurken yerinde durdu mu. Web sitesi hızlandırma çalışmasının tamamı bu üç soruya daha iyi yanıt vermeye çalışır. Teknik olmayan paydaşlarla konuşurken metrik kısaltmaları yerine bu üç cümleyi kullanmak, önceliğin hızla anlaşılmasını sağlar ve bütçe tartışmasını kısaltır.

Pratikte hangi metrik daha çok sorun çıkarıyor? Web Almanac 2025 verisi ayrımı net gösteriyor: mobilde CLS'de sayfaların %81'i, INP'de %77'si, LCP'de ise yalnızca %62'si "iyi" bandında. Yani zincirin zayıf halkası neredeyse her zaman LCP; yükleme hızı. Bir siteye ilk müdahale listesi hazırlarken bu sıralama yol gösterir.

2026'da Neyin Değiştiği, Neyin Değişmediği

İnternette dolaşan bir iddiayı baştan netleştirelim: "Google 2026'da LCP eşiğini 2,0 saniyeye indirdi" cümlesinin resmi bir karşılığı yok. web.dev bugün hâlâ 2,5 saniye yazıyor ve Google metrikleri "stable" statüsünde tutuyor — bu statü, bir metriğin yılda birden fazla değişmeyeceği ve her değişikliğin önceden duyurulacağı anlamına geliyor. Kaynağı Google olmayan eşik haberlerine bütçe ayırmayın.

Gerçek kırılma 2024'te yaşandı: INP, FID'in yerini alarak kalıcı Core Web Vitals metriği oldu. FID yalnızca ilk etkileşimin gecikmesini ölçüyordu; INP ise sayfa ömrü boyunca yaşanan etkileşimlerin neredeyse en kötüsünü raporluyor. Bu değişiklik, "ilk tık hızlı görünüyor ama menü açılırken site donuyor" tipindeki sorunları görünür kıldı.

Değişen bir şey daha var: bar yükseliyor. Mobilde geçiş oranı 2024'te %44 iken 2025'te %48'e çıktı. Aynı dönemde mobil TBT (Total Blocking Time) medyanı %58 arttı — yani sayfalar ağırlaşırken tarayıcılar ve geliştiriciler bu ağırlığı telafi etmeye çalışıyor. Sitenizde hiçbir şey yapmazsanız yerinizde saymazsınız; geriye düşersiniz.

Pratik sonuç şu: web sitesi hızlandırma planınızı Google'ın resmi dokümantasyonuna göre kurun, ajans bloglarında dolaşan eşik iddialarına göre değil. Metrik tanımları ve eşikler tek bir yerde, web.dev üzerinde güncel duruyor. Bir eşiğin gerçekten değiştiğini duyduğunuzda ilk kontrol noktanız orası olmalı. İkinci kontrol noktanız da Google Search Central duyuruları; büyük değişiklikler oradan da geçer.

Sitenizin Gerçek Hızını Ölçmek: Lab mı, Saha mı?

PageSpeed Insights raporu iki bloktan oluşur. Üstteki blok saha verisidir ve Chrome User Experience Report'tan (CrUX) gelir; gerçek kullanıcıların son 28 günde yaşadığı deneyimi özetler. Alttaki blok ise Lighthouse'un tek seferlik laboratuvar testidir.

İkisi arasındaki fark, çoğu yanlış kararın kaynağı. Lighthouse simüle edilmiş kısıtlama kullanır: sayfayı hızlı bir bağlantıda ölçer, sonra yavaş bir mobil bağlantıda ne olacağını hesaplar. Bu modelleme, ağır JavaScript ayrıştıran sayfalarda ve donanım farklarında yanılabilir. Bu yüzden "Lighthouse 95 ama sahada LCP zayıf" tablosu da mümkündür, tam tersi de.

Sahadan gelen deneyimimiz bunu doğruluyor. Müşterilerimizin bize gelme sebebi genellikle turuncu bir skor oluyor; saha verisine baktığımızda LCP'nin 2,1 saniyede olduğunu, yani sıralama açısından hiçbir sorun bulunmadığını görüyoruz. Tersi de oluyor: skoru 90 olan bir kurumsal sitede sahada LCP 4,3 saniye çıkıyor, çünkü ziyaretçilerin çoğu orta seviye Android telefonlarda ve mobil veriyle geliyor.

Karar kuralı basit: sıralama ve dönüşüm sorusunu saha verisi yanıtlar, "neyi düzelteceğim" sorusunu lab raporu. Search Console'daki Core Web Vitals raporu ise URL'leri gruplayarak hangi şablonun sorunlu olduğunu gösterir; 28 günlük kayan pencere nedeniyle düzeltmeleriniz oraya birkaç hafta gecikmeyle yansır.

Üçüncü bir katman daha var: kendi gerçek kullanıcı ölçümünüz. Google'ın açık kaynaklı web-vitals kütüphanesini siteye ekleyerek her ziyaretin LCP, INP ve CLS değerini kendi analitiğinize gönderebilirsiniz. Bu katman iki soruna çözüm üretir. Birincisi, CrUX yalnızca yeterli trafiğe ulaşan sayfaları raporlar; düşük trafikli kurumsal sitelerde saha verisi çoğu zaman boş görünür. İkincisi, kendi ölçümünüz cihaz modeli, tarayıcı ve sayfa şablonu kırılımı verir; böylece "hangi şablon sorunlu" sorusuna tahminle değil veriyle yanıt verirsiniz. Web sitesi hızlandırma projelerine her zaman bu üç kaynağı birlikte kurarak başlıyoruz.

Kendi sitenizde nereden başlayacağınızı görmek isterseniz ücretsiz site analizi aracımız PageSpeed altyapısıyla mobil performansı ve temel SEO kontrollerini yaklaşık 30 saniyede raporluyor.

LCP'yi 2,5 Saniyenin Altına Çekmek

LCP, ekranın görünen bölümündeki en büyük içerik öğesinin ne zaman boyandığını ölçer. Mobil sayfaların %76'sında bu öğe bir görseldir. Dolayısıyla LCP çalışması, çoğunlukla "hero görselini erken bul, erken indir, doğru boyutta gönder" çalışmasıdır.

Buradaki en yaygın hata keşfedilebilirlik. web.dev'in aktardığı veriye göre LCP görsellerinin yalnızca %35'i ilk HTML yanıtında görünüyor; kalanını tarayıcı ancak JavaScript çalıştıktan sonra fark ediyor. Slider'ını JavaScript ile kuran bir anasayfa, tarayıcıya "önce bu görseli indir" deme şansını daha baştan harcıyor.

İkinci hata öncelik. Uygun sayfaların yalnızca %15'i fetchpriority="high" özniteliğini kullanıyor. Üçüncüsü ise doğrudan kendi ayağına sıkmak: sayfaların %17'si LCP görselini lazy-load ediyor. Ekranın üstündeki görsele loading="lazy" koymak, tarayıcıya "acelesi yok" demektir.

Sıralı bir müdahale listesi işinizi kolaylaştırır:

1. TTFB'yi 800 ms altına indirin. web.dev'in TTFB rehberi bu eşiği hedef gösteriyor; sunucu geç yanıt veriyorsa görsel optimizasyonunun etkisi sınırlıdır.
2. LCP görselini HTML kaynağına taşıyın, src/srcset ile doğrudan verin ve fetchpriority="high" ekleyin.
3. Ekran üstündeki hiçbir görseli lazy-load etmeyin; lazy yükleme yalnızca kıvrımın altı içindir.
4. Kritik fontları preload edin ve font-display: swap ile metnin görünmesini geciktirmeyin.

Bu dört adım, çoğu kurumsal sitede web sitesi hızlandırma çalışmasının en büyük tek kazancını verir.

Görsel Optimizasyonu: En Hızlı Kazanç

Sayfa ağırlığı büyümeye devam ediyor. Web Almanac 2025 sayfa ağırlığı bölümüne göre mobilde medyan sayfa 2.164 KB; bunun 911 KB'ı görsel, 632 KB'ı JavaScript. Medyan sayfa ağırlığı bir yılda mobilde %8,4 arttı. Yani hiçbir şey yapmazsanız siteniz her yıl biraz daha yavaşlıyor.

Format tarafında sektör hâlâ geride. LCP görsellerinin %57'si JPG, %26'sı PNG; WebP %11'de, AVIF ise %0,7'de kalıyor. Oysa modern formatlar aynı görsel kalitede ciddi kazanç sağlıyor:

AVIF'in tek dezavantajı kodlama süresi: WebP'ye kıyasla belirgin biçimde yavaş üretilir. Kullanıcıların yüklediği çok sayıda görseli anında işleyen bir platformda bu maliyeti hesaba katın; kurumsal bir sitede ise sorun değil.

Web sitesi hızlandırma listesinde görsel optimizasyonu, harcanan efora göre en yüksek getiriyi veren maddedir; çünkü kod mimarisine dokunmadan uygulayabilirsiniz. Bir e-ticaret kategori sayfasında 40 ürün görselini AVIF'e çevirmek sayfa ağırlığını rahatlıkla yarıya indirir. Aynı kazancı JavaScript tarafında elde etmek haftalar süren bir yeniden yapılandırma gerektirir.

Format kadar önemli üç alışkanlık daha var. Görseli kullanılacak boyutta üretin — 3000 pikselik ürün fotoğrafını 600 piksellik kutuya sığdırmak, ziyaretçiye görmeyeceği veriyi indirtir. srcset ve sizes ile cihaza uygun varyantı gönderin. Son olarak her img etiketine width ve height yazın; bu hem CLS'yi düşürür hem de tarayıcının yer ayırmasını sağlar.

INP: Tıkladıktan Sonraki Donma

INP, kullanıcının tıklama, dokunma veya klavye etkileşimiyle ekranda gördüğü ilk değişiklik arasındaki gecikmeyi ölçer. Sayfadaki tek bir yavaş etkileşim bile metriği aşağı çeker, çünkü INP en kötüye yakın deneyimi raporlar.

Rakamlar sorunun nerede olduğunu söylüyor: masaüstünde sayfaların %97'si INP eşiğini geçiyor, mobilde ise %77'si. Aradaki uçurum ağ değil, işlemci. Orta segment bir Android telefon, aynı JavaScript'i masaüstünden kat kat yavaş çalıştırır.

Teknik sebep genelde uzun görevler: ana iş parçacığını 50 milisaniyeden uzun süre meşgul eden JavaScript blokları. Kullanıcı bu sırada butona bastığında tarayıcı yanıt veremez. Çözüm, işi bölmek ve tarayıcıya nefes aldırmaktır. scheduler.yield() bugün bunun standart yolu; eski tarayıcılar için setTimeout(resolve, 0) yedeğini kullanabilirsiniz. Kritik ayrıntı: await yazmayı unutmayın; onsuz tarayıcı görevi bölmez.

Web sitesi hızlandırma çalışmasında INP genelde en son sıraya kalır, çünkü çözümü doğrudan ön yüz mimarisine dokunur. Yine de mobil trafiği yoğun sitelerde en çok şikâyet üreten metrik budur: kullanıcı butona iki kez basar, form iki kez gider, destek ekibi de sebebini anlamadan "sistem hatası" kaydı açar. INP'yi düzeltmek çoğu zaman bir hata kaydını da kapatır.

Bunun ötesinde üç müdahale işe yarar: kullanılmayan JavaScript'i paketten çıkarın, sayfa bazlı kod bölme uygulayın ve gereksiz hydration'ı azaltın. Statik bir kurumsal sayfaya React hydration'ı eklemek çoğu zaman gereksiz maliyettir; modern web tasarım yaklaşımlarını ele aldığımız yazımızda bu tercihin arayüz tarafındaki karşılığını da bulabilirsiniz.

CLS: Sayfanın Zıplamasını Durdurmak

CLS, sayfa yüklenirken içeriğin ne kadar kaydığını ölçer. Kullanıcı "Satın Al" butonuna basmak üzereyken üstte bir banner yüklenir, buton aşağı kayar ve tıklama reklamın üzerine gider — bu deneyim CLS'nin ta kendisidir.

Ana sebep şaşırtıcı derecede basit: boyutsuz görseller. web.dev'in aktardığına göre sayfaların %66'sında en az bir görselde width/height bilgisi yok; Web Almanac 2025 mobilde bu oranı %62 olarak veriyor. Tarayıcı görselin boyutunu ancak indirdikten sonra öğrenirse, o ana kadar altındaki her şeyi yukarı çeker.

Dört önlem sorunun büyük bölümünü kapatır:

• Görsellere ve iframe alanlarına açık width/height ya da CSS aspect-ratio verin.
• Reklam, kampanya çubuğu ve gömülü içerik için önceden min-height ayırın.
• Web fontlarında size-adjust ve uygun font-display değeriyle metin sıçramasını azaltın.
• Animasyonlarda margin veya border yerine transform kullanın; layout tetikleyen özellikleri animasyona sokan sayfalar kötü CLS oranını neredeyse iki katına çıkarıyor.

Çerez bandı ve duyuru çubuğu gibi geç yüklenen bileşenleri içeriği aşağı iten değil, üzerine binen bir katman olarak kurgulayın.

Üçüncü Parti Scriptlerin Gerçek Faturası

Kimse sitesine "yavaşlatıcı" eklemek istemez; ama pazarlama tarafının her talebi bir script olarak geri döner. Web Almanac 2025 üçüncü parti bölümüne göre sayfaların %90'ından fazlası en az bir üçüncü parti kaynak yüklüyor. Medyan bir sayfa mobilde 79, masaüstünde 83 üçüncü parti isteği yapıyor; en popüler 1.000 sitede bu sayı 106–129 aralığına çıkıyor.

En kritik bulgu ise zincir derinliği: medyan değer 3. Yani yüklediğiniz üçüncü parti, kendi içinde başka üçüncü partileri çağırıyor. Etiket yöneticisine tek bir kod eklediğinizi sanırken tarayıcıya onlarca istek ve yüzlerce milisaniyelik ana iş parçacığı işi bindirmiş olabilirsiniz.

Tipik bir Türk KOBİ sitesinde envanter şöyle çıkıyor: Google Analytics, Google Ads dönüşüm etiketi, Meta pikseli, bir ısı haritası aracı, bir canlı destek widget'ı ve iki sosyal medya gömülü içeriği. Bunların büyük kısmı ölçüm yapıyor, hiçbiri ziyaretçiye değer üretmiyor.

Üçüncü parti temizliği, web sitesi hızlandırma işinin en politik kısmıdır; çünkü her scriptin arkasında onu isteyen bir ekip vardır. Kararı kolaylaştıran tek bir soru var: "Bu scriptin ürettiği veriyi son 90 günde kim, hangi kararı almak için kullandı?" Yanıtı olmayan script listeden çıkar. Bu soru, teknik tartışmayı fikir kavgası olmaktan çıkarıp ölçülebilir bir gerekçeye bağlar.

Şu üç adım envanteri hızla toparlar. Önce etiket yöneticinizde artık kullanılmayan tag'leri silin — çoğu sitede kapatılmış kampanyaların etiketleri yıllarca çalışmaya devam eder. Sonra canlı destek ve yorum widget'larını sayfa açılışında değil, kullanıcı etkileşiminde yükleyin. Son olarak ölçüm scriptlerini onay (consent) sonrasına erteleyin; hem KVKK uyumu hem hız açısından doğru olan budur. Ölçüm kurulumunu doğru yapmak isterseniz Google Analytics kurulumunu anlattığımız rehber başlangıç için yeterli.

Önbellek, CDN ve Sunucu Tarafı

Hiçbir ön yüz optimizasyonu yavaş bir sunucuyu kurtarmaz. TTFB hedefi 800 milisaniye; Web Almanac 2025'e göre mobil sayfaların yalnızca %44'ü bu eşiği tutturuyor. Daha çarpıcı olan şu: HTML belge isteklerinin sadece %33'ü bir CDN üzerinden geliyor. Yani sitelerin üçte ikisi, ziyaretçisi nerede olursa olsun tek bir sunucudan yanıt vermeye çalışıyor.

Önbellek dört katmanda çalışır ve her biri farklı bir sorunu çözer. Tarayıcı önbelleği (Cache-Control, uzun ömürlü statik dosyalar için immutable) tekrar ziyaretleri hızlandırır. Tam sayfa önbelleği sunucunun aynı HTML'i tekrar tekrar üretmesini engeller. Nesne önbelleği (Redis gibi) tekrarlayan veritabanı sorgularını keser. Veritabanı tarafında ise eksik indeksler çoğu yavaş sorgunun sebebidir.

Sunucu tarafı, web sitesi hızlandırma çalışmasının görünmeyen ama en kalıcı katmanıdır. Ön yüzde yaptığınız her iyileştirmeyi bir tema güncellemesi geri getirebilir; doğru kurulmuş bir önbellek ve CDN katmanı ise yıllarca yerinde durur. Bu yüzden bütçe kısıtlı projelerde sıralamayı sunucudan başlatmak daha güvenli bir tercihtir.

CDN kararı Türkiye için ayrıca önemli. Ziyaretçilerinizin ağırlığı yurt içindeyse İstanbul ya da yakın bölge PoP'u bulunan bir sağlayıcı, tek başına birkaç yüz milisaniye kazandırır. Brotli sıkıştırma ve HTTP/2/HTTP/3 desteği bugün standart beklenti. Konunun mantığını CDN nedir yazımızda daha ayrıntılı anlattık.

Türkiye'deki kurumsal sitelerde en sık gördüğümüz sunucu sorunu paylaşımlı hosting. Aylık birkaç yüz liralık bir paket, aynı fiziksel makinede yüzlerce siteyle kaynak paylaşır; komşu sitelerden biri trafik aldığında sizin TTFB'niz de yükselir. Bu tabloda ön yüzde ne yaparsanız yapın, ziyaretçi ilk baytı 1,5 saniyede alır. Ölçüm kolaydır: aynı sayfayı günün farklı saatlerinde test edin, TTFB'nin saatlere göre 400 ms'den 1.500 ms'ye savrulduğunu görüyorsanız sorun kodda değil paketinizde. Bu noktada VPS ya da yönetilen hosting'e geçmek, haftalarca sürecek kod optimizasyonundan daha hızlı ve daha ucuz sonuç verir.

Türkiye'de mobil taraf hızla değişiyor: 5G ihalesi 16 Ekim 2025'te yapıldı ve Ulaştırma ve Altyapı Bakanlığı'nın duyurduğu takvimle ticari kullanım 1 Nisan 2026'da İstanbul, Ankara ve İzmir'de başladı. Ancak sabit genişbant tarafındaki ortalamalar aynı hızda iyileşmiyor ve ziyaretçilerinizin önemli bir kısmı hâlâ 4.5G'de. "Nasılsa herkesin interneti hızlı" varsayımıyla sayfa ağırlığını serbest bırakmak erken bir karar olur.

30 Günlük Hızlandırma Yol Haritası

Aşağıdaki plan, orta ölçekli bir kurumsal siteyi dört haftada ölçülebilir biçimde iyileştirir. Sıralama önemlidir: ölçmeden müdahale etmek, kazancı da kaybı da görünmez kılar.

Plan boyunca tek bir kural işi kolaylaştırır: her hafta sonunda ölçümü tekrarlayın ve neyi değiştirdiğinizi yazın. Web sitesi hızlandırma çalışmalarının çoğu, hangi müdahalenin ne kazandırdığı bilinmediği için ikinci yılda sessizce geri gider. Kayıt tutan ekipler ise bir sonraki site yenilemesinde aynı hatalara dönmez ve kazanımı korur.

Dördüncü haftanın sonunda saha verisinin tamamen yenilenmesini beklemeyin. CrUX 28 günlük kayan pencere kullandığı için Search Console'daki grafiklerin düzelmesi genellikle 3–4 hafta daha sürer. Bu gecikmeyi bilmek, ekibin "işe yaramadı" sonucuna erken varmasını önler.

Sıkça Sorulan Sorular

Web sitesi hızlandırma çalışması ne kadar sürer?

Teknik müdahalelerin büyük kısmı 2–4 hafta içinde tamamlanır. Ancak Core Web Vitals raporlarına yansıması, CrUX'ün 28 günlük veri penceresi nedeniyle ek 3–4 hafta alır. Toplamda ölçülebilir sonuç için 6–8 hafta hesaplayın.

PageSpeed skorumun 100 olması gerekir mi?

Hayır. PageSpeed skoru laboratuvar ölçümüne dayanan bir özet nottur ve Google sıralamada bu skoru kullanmaz. Hedefiniz saha verisinde LCP'yi 2,5 saniyenin, INP'yi 200 milisaniyenin, CLS'yi 0,1'in altında tutmak olmalıdır.

Core Web Vitals sıralamayı gerçekten etkiliyor mu?

Evet, ancak tek başına belirleyici değil. Google bu metrikleri sayfa deneyimi sinyalleri arasında değerlendiriyor; içerik kalitesi ve otorite bakımından benzer sayfalar yarışırken fark yaratıyor. Kötü Core Web Vitals iyi içeriğin tavanını düşürür, iyi Core Web Vitals zayıf içeriği kurtarmaz.

WordPress sitemi eklenti ile hızlandırabilir miyim?

Önbellek ve görsel eklentileri gerçek kazanç sağlar, ama tavanı vardır. Ağır bir tema, çok sayıda sayfa oluşturucu bileşeni ve onlarca üçüncü parti script varsa eklenti bunları maskeleyemez. Bu durumda tema ve script envanterini sadeleştirmek kalıcı çözümdür. Pratik sıra şudur: önce eklenti sayısını düşürün, sonra sayfa oluşturucu bileşenlerini sadeleştirin, en son önbellek eklentisini kurun. Tersi sırada ilerleyen projelerde eklenti yalnızca sorunu gizler.

Mobil ve masaüstü skorları neden bu kadar farklı çıkıyor?

Fark çoğunlukla işlemci gücünden kaynaklanır. Orta segment bir telefon aynı JavaScript'i masaüstü bilgisayardan kat kat yavaş çalıştırır; buna mobil ağ gecikmesi de eklenir. Google değerlendirmeyi mobil ve masaüstü için ayrı yaptığından, önceliğiniz mobil olmalıdır.

Hız iyileştirmesi dönüşüm oranını ne kadar artırır?

Sektör çalışmaları her saniyelik iyileşme için %2–7 bandında dönüşüm artışı raporluyor; Google ve Deloitte'un perakende araştırmasında 0,1 saniyelik mobil iyileşme dönüşümü %8,4 yükseltti. Kesin rakam sektöre, cihaz dağılımına ve çıkış noktanıza bağlı değişir. Çıkış noktası 5 saniye olan bir sitede kazanç büyük, 2 saniye olan bir sitede sınırlıdır.

Web sitesi hızlandırma, tek seferlik bir proje değil sürdürülen bir disiplindir. Sayfa ağırlığı her yıl artıyor, pazarlama ekibi her ay yeni bir script istiyor ve tema güncellemeleri kazanımları geri alabiliyor. Kalıcı sonuç isteyen ekipler saha verisini düzenli izler ve yeni yayınlanan her şablonu ölçerek devreye alır.

Master Web olarak kurumsal web tasarım projelerimizde performansı sonradan eklenen bir optimizasyon adımı değil, tasarım kararlarının parçası olarak ele alıyoruz. Mevcut sitenizin nerede kan kaybettiğini kalem kalem görmek isterseniz bizimle iletişime geçin; saha verinizle birlikte önceliklendirilmiş bir yol haritası çıkaralım.