Hız Endeksi

TL;DR — Speed Index, sayfa yüklenirken içeriğin ne kadar hızlı göründüğünü ölçen bir Lighthouse puanıdır. Daha düşük (daha hızlı) daha iyidir ve saniye cinsinden ölçülür. Mobilde 3,4 saniyenin altı iyidir. Core Web Vital değildir ve Google sıralamalarınızı doğrudan etkilemez — ancak onu düzelten şeyler genellikle etkileyen metriklere de yardımcı olur.

Speed Index nedir?

Bir sayfayı Lighthouse veya PageSpeed Insights üzerinden çalıştırdığınızda elde ettiğiniz sayılardan biri Speed Index’tir. Basit bir soruya yanıt verir: sayfanızın görünen kısmı ne kadar hızlı dolar?

Çoğu hız metriği tek bir anı işaretler — örneğin ilk içerik parçasının göründüğü anı (First Contentful Paint) veya en büyük öğenin göründüğü anı (Largest Contentful Paint). Speed Index farklıdır. Yüklemenin tamamını izler ve öğelerin görünür hâle gelme hızının ortalamasını verir. Her şeyi neredeyse anında boyayan bir sayfa düşük (iyi) puan alır; boş kaldıktan sonra içeriği azar azar getiren bir sayfa ise yüksek (kötü) puan alır.

Puanınız nasıl okunur?

Lighthouse, Speed Index’i mobilde şöyle derecelendirir:

• İyi: 0 – 3,4 s (yeşil)
• İyileştirme gerekli: 3,4 – 5,8 s (turuncu)
• Zayıf: 5,8 saniyeden fazla (kırmızı)

Masaüstü çok daha katıdır — iyi değer yaklaşık 1,3 saniyenin altıdır — çünkü Lighthouse mobili simüle edilmiş daha yavaş bir cihazda test eder. Bu nedenle masaüstü sayısını mobil sayısıyla karşılaştırmayın; farklı ölçeklerdedir.

SEO için önemi var mı?

İnsanların yanlış anladığı kısım şu. Speed Index bir Core Web Vital değildir ve Google sıralama faktörü değildir. Google’ın sayfa deneyimi sinyalleri gerçek kullanıcılar üzerinde ölçülen Core Web Vitals’tan (LCP, INP ve CLS) gelir. Speed Index bunlardan biri değildir ve gerçek kullanıcılar üzerinde bile ölçülmez — yalnızca test araçlarında gerçekleşen bir yükleme video kaydına ihtiyaç duyar.

Bu, onu işe yaramaz yapmaz. Speed Index’i iyileştiren düzeltmeler — daha hızlı sunucu, daha az oluşturmayı engelleyen dosya ve yazı tipleri yüklenirken görünür kalan metin — FCP ile LCP’yi iyileştiren düzeltmelerin aynısıdır. Dolayısıyla daha iyi bir Speed Index genellikle önemli olan daha iyi bir LCP ile birlikte ilerler.

Formülü, WebPageTest geçmişini, Lighthouse puanındaki yerini ve dikkat edilmesi gereken sınırlamaları görmek istiyorsanız Advanced sekmesine geçin.

TL;DR — Speed Index, sayfa yüklenirken içeriğin görsel olarak ne kadar hızlı gösterildiğini ölçer — görünür içeriğin ortaya çıkma süresinin ortalamasıdır ve saniye cinsinden puanlanır (daha düşük daha iyidir). Yükleme videosundan, görsel ilerleme eğrisinin üstündeki alan toplanarak hesaplanır; bu da onu yalnızca laboratuvar metriği yapar (CrUX’ta, PSI alan verilerinde veya Search Console’da bulunmaz). WebPageTest’te (Pat Meenan) ortaya çıkmıştır; Lighthouse bunu açık kaynaklı Speedline modülüyle hesaplar. Core Web Vital değildir ve sıralama faktörü değildir — Lighthouse 10’da ağırlığı 10% olan beş Lighthouse metriğinden biridir. Mobil: İyi ≤ 3,4 s, İyileştirme gerekli ≤ 5,8 s, Zayıf > 5,8 s; masaüstünde iyi ≤ ~1,3 s. FCP’den daha hızlı olamaz, görünüm alanına bağlıdır ve FCP/LCP ile aynı düzeltmelerle iyileşir.

Speed Index gerçekte neyi ölçer?

Google’ın tanımı tek satırdır: “Speed Index measures how quickly content is visually displayed during page load.” Buradaki anahtar kelime görsel olarak ifadesidir. Speed Index, First Contentful Paint ve Largest Contentful Paint gibi tek bir zaman damgası değildir — sayfanın görünür kısımlarının gösterildiği ortalama zamanı temsil eden bileşik bir puandır. Daha düşük daha iyidir ve saniye cinsinden raporlanır.

En anlaşılır bulduğum zihinsel model şu: X ekseninde zamanı, Y ekseninde 0%‘dan 100%‘e yükselen “sayfanın görsel olarak tamamlanma yüzdesi”ni gösteren bir grafik çizin. Speed Index, bu eğrinin üstündeki alandır. Eğri 100%‘e ne kadar hızlı yükselirse alan o kadar küçük, puan o kadar iyi olur. Bir süre boş kalan sayfa çizginin üstünde büyük bir boş dikdörtgen bırakır; hızlı boyanan sayfa ise neredeyse hiç bırakmaz.

Nasıl hesaplanır?

Lighthouse, sayfa yüklenirken bir video yakalar ve kareler arasındaki görsel ilerlemeyi hesaplar. Her zaman aralığı, sayfanın o andaki tamamlanmamışlık derecesine göre ağırlıklandırılır — tamamen boş bir kare 100% sayılır, büyük ölçüde oluşturulmuş bir kare ise çok az katkıda bulunur. Özgün WebPageTest formülü şöyledir:

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

İşlenmiş bir örnek bunu somutlaştırır. DebugBear bir yüklemeyi şöyle adım adım gösterir:

• 0% tamamlandı (0–253 ms) → 253,0 ms katkı
• 43% tamamlandı (253–403 ms) → 85,5 ms katkı
• 98% tamamlandı (403–536 ms) → 2,7 ms katkı
• 99% tamamlandı (536–653 ms) → 1,2 ms katkı
• Toplam: 342,3 ms

İlk parçaya dikkat edin: hiçbir şey görünür değilken bu sürenin tamamı tam ağırlıkla katkıda bulunur. Bu nedenle Speed Index hiçbir zaman First Contentful Paint’ten daha hızlı olamaz — ilk içerik boyanmadan önceki her milisaniye 100% olarak sayılır.

Lighthouse burada kendi uygulamasını kullanmaz. Açık kaynaklı Speedline modülünü (başlangıçta Paul Irish tarafından geliştirilmiştir) çalıştırır; bu modül, ekran görüntüleri etkinleştirilmiş Chrome DevTools izlerinden yararlanarak WebPageTest’tekiyle aynı video üzerinden görsel ilerleme metodolojisini uygular. Speedline, standart bir Speed Index’i (mevcut kare ile son kare arasındaki histogram farkını) veya SSIM kullanan algısal bir çeşidi hesaplayabilir; normalde gördüğünüz standart olandır.

İyi puan nedir?

Lighthouse 10, Speed Index’i HTTP Archive’daki gerçek web sitesi verilerine göre derecelendirir ve Lighthouse varsayılan olarak kısıtlamalı orta seviye bir mobil cihazı simüle ettiği için eşikler cihaza göre keskin biçimde değişir:

Etrafta dolaşan eski “under 1 000 ms is good” karşılaştırmasını gördüyseniz bu, belirli bir dönem ve bağlantı profili için hazırlanmış eski WebPageTest rehberliğidir — güncel Lighthouse mobil eşiği değildir. Baktığınız sayıyı hangi araç ve hangi cihaz/ağ ayarlarının ürettiğini her zaman bilin; çünkü aynı sayfa Lighthouse, WebPageTest ve GTmetrix’te farklı puan alır.

Lighthouse puanındaki yeri

Speed Index, Lighthouse 10 Performance puanındaki beş metriktan biridir ve ağırlığı 10%‘dur — en düşük ağırlık için FCP ile beraberdir:

Pratik sonuç: Speed Index’in tek başına peşinden koşmak düşük yatırım getirisine sahiptir. Total Blocking Time (30%) ile LCP ve CLS (her biri 25%) genel puanı çok daha fazla değiştirir. Özellikle başarısız olan şey Speed Index değilse, genellikle LCP ve TBT’yi düzelterek daha çok kazanırsınız — Speed Index zaten yan etki olarak iyileşir. PageSpeed Insights’ta Speed Index’i yukarıdaki alan verisi bölümünde değil, laboratuvar (Lighthouse) bölümünde bulursunuz.

Speed Index bir Core Web Vital veya sıralama faktörü müdür?

Her iki sorunun yanıtı da hayırdır ve raporu bir paydaşa açıklarken bu ayrım önemlidir.

• Core Web Vital değildir. Core Web Vitals, CrUX üzerinden gerçek kullanıcılar üzerinde ölçülen LCP, INP ve CLS’dir. Speed Index bu kümede yer almaz ve Search Console’ın Core Web Vitals raporunda görünmez.
• Doğrudan sıralama faktörü değildir. Google’ın sayfa deneyimi sinyali Core Web Vitals’ın alan verisini kullanır. Speed Index, Google’ın gerçek kullanıcılardan toplamadığı yalnızca laboratuvara ait bir tanı metriğidir; bu nedenle Speed Index sayınızdan sıralamalara giden doğrudan bir yol yoktur.

Sıralamalarla ilişkisi dolaylıdır: kötü Speed Index üreten sorunlar — yavaş TTFB, oluşturmayı engelleyen CSS/JS, yazı tipi değişimi sırasında görünmeyen metin — kötü FCP ve LCP üreten sorunların aynısıdır. Bunları düzeltin; daha iyi bir Speed Index genellikle Google’ın gerçekten ödüllendirdiği daha iyi LCP’yi takip eder.

Neden yalnızca laboratuvara ait?

Speed Index, sayfanın oluşturulmasını kare kare gösteren bir video ve ardından her karedeki görsel tamamlanmayı hesaplamak için görüntü işlemeyi gerektirir. Bu, her gerçek ziyaretçide çalıştırılamayacak kadar pahalıdır; bu nedenle yalnızca sentetik/laboratuvar araçlarında — Lighthouse, WebPageTest, GTmetrix — bulunur. Gerçek Kullanıcı İzleme ve CrUX veri kümesi bunu taşımaz. Alan performans verisine ihtiyacınız varsa Core Web Vitals’ı kullanın; Speed Index kontrollü bir testte oluşturmayı teşhis etmek içindir.

Nereden geldi?

Speed Index, Pat Meenan’ın 2008’de oluşturduğu ve açık kaynak hâline getirdiği WebPageTest’te ortaya çıktı (metriğin kendisi yaklaşık 2012’de eklendi). O dönemin metriklerindeki gerçek bir boşluğu gidermek için tasarlanmıştı:

• Oluşturma başlangıcı, tek bir pikselde veya arka plan renginde tetiklenebilirdi — anlamlı içerik değildi.
• Belgenin tamamlanması (onload), ekranın altındaki ve ilgisiz kaynakları içerir.

Speed Index, ekranın üst kısmındaki görsel tamamlanmayı zaman içinde ölçerek bu ikisinin ortasını buldu — kullanıcının gerçekten algıladığı şeye daha iyi bir yaklaştırıcı oldu. Lighthouse daha sonra bu metodolojiyi Speedline modülü aracılığıyla benimsedi; bu nedenle kısıtlamaları farklı olsa da WebPageTest ve Lighthouse sayıları aynı soydan gelir.

Nasıl iyileştirilir?

Speed Index’e özgü bir hile yoktur — Google’ın kendi rehberliği, sayfa yükleme hızını iyileştirmek için yaptığınız her şeyin Speed Index puanınızı da iyileştireceği yönündedir. Uygulamada:

• Sunucu yanıt süresini (TTFB) kısaltın. İlk bayttan önceki her milisaniye, tam ağırlıkla sayılan boş sayfa süresidir.
• Oluşturmayı engelleyen CSS ve JavaScript’i ortadan kaldırın. Bunlar ilk boyamayı geciktirir; eğrinin en pahalı kısmı budur. Kritik CSS’i satır içine alın, kalanını erteleyin.
• Yazı tipi yüklemesini düzeltin. Yazı tipi değişimi sırasında metin görünmez olabilir — bu aralık için tamamlanma 0% sayılır. font-display: swap (veya optional) metni görünür tutar. Lighthouse’ın Speed Index için açıkça işaretlediği denetimlerden biri budur.
• Ana iş parçacığı çalışmasını en aza indirin ve JavaScript yürütme süresini azaltın — Lighthouse’ın Speed Index için yüksek etkili olarak belirttiği diğer iki tanı da budur.
• Ekranın üst kısmındaki içeriğe öncelik verin. Speed Index yalnızca görünür görünüm alanını önemser; bu nedenle ilk ekranın hızlı boyanmasını sağlamak bütün oyundur.

Bunlar neredeyse tamamen FCP ve LCP optimizasyonuyla örtüşür — Speed Index’i ayrı bir yapılacaklar listesi değil, doğrulayıcı bir sinyal olarak görmemin nedeni tam da budur. Tek bir sayıya göre harekete geçmeden önce gerçekten neyin erken veya geç boyandığını doğrulamak için yükleme film şeridine bakın (hem Lighthouse hem WebPageTest bir tane oluşturur) ve tek bir test yerine benzer koşullarda tekrarlanan birkaç çalıştırmayı karşılaştırın — aşağıdaki çalıştırmadan çalıştırmaya değişkenlik notuna bakın.

Bilinmesi gereken sınırlamalar

• Yalnızca laboratuvar — gerçek bir kullanıcının deneyimini değil, yalnızca test ortamının deneyimini yansıtır.
• Görünüm alanına bağlı — görünür alanı ölçer; bu nedenle mobil ve masaüstü çok farklı sonuçlar verir (eşiklerin bu kadar farklı olmasının nedeni budur).
• SPA/AJAX kör noktası — tek sayfalı uygulamalar yapay biçimde hızlı görünebilir: kabuk hızlı boyanırken gerçek içerik daha sonra, sayfa yenilenmeden yüklenir.
• Karuseller, otomatik oynatılan video ve izin katmanları — anlamlı içerik yüklendikten sonra pikselleri değiştirmeyi sürdüren her şey, otomatik dönen karuselleri cezalandıran mekanizmayla aynı şekilde, “tamamlanmamış” olarak kaydolmayı sürdürdüğü için cezalandırılabilir.
• “Tamamen yüklendi” metriği değildir — her komut dosyasının, görselin veya ekranın altındaki öğenin bitmesini değil, ekranın üst kısmındaki görsel ilerlemeyi ölçer. WebPageTest’in ayrı Visually Complete metriği (her zaman Speed Index’e eşit veya ondan büyük) geç yüklenen tembel yüklemeli bir bileşeni yakalayan metriktir.
• Görsel ilerleme yararlılığın kanıtı değildir. Speed Index yalnızca son kareye kıyasla piksel değişimini ölçer — ekrandaki şeyin okunabilir, doğru sıralanmış, erişilebilir veya gerçekten etkileşimli olup olmadığını bilmez. Hızlı boyanan bir iskelet veya kabuk iyi puan alabilir; gerçek içerik (ve onu kullanabilme imkânı) daha sonra gelebilir. Bu, yalnızca metriğin açısından anlatılan, yukarıdaki “anlamsız erken boyama” anti-pattern’iyle aynı arıza modudur.
• Çalıştırmadan çalıştırmaya değişkenlik. Tek bir kaydedilmiş yüklemeden türetildiği için Speed Index test koşullarıyla değişir — Google’ın kendi puanlama rehberliği cihaz farklılıklarını, tarayıcı uzantılarını, antivirüs yazılımını ve hatta puan dalgalanmasına neden olan reklam/A-B testi değişikliklerini, kodunuzla ilgisi olmayan kaynaklar olarak listeler. Tek seferlik sayıları değil, benzer koşullarda tekrarlanan çalıştırmalardan elde edilen dağılımları karşılaştırın.

İlgili metrikler

Speed Index, Core Web Vitals merkezinin ve komşularının bulunduğu web performansı kümesinde yer alır. En yakın olduğu metrikler First Contentful Paint (Speed Index FCP’yi geçemez) ve Largest Contentful Paint (aynı düzeltmeler, aynı kök nedenler); Lighthouse puanında Total Blocking Time’ın yanında bulunur ve Lighthouse ile PageSpeed Insights içinde karşınıza çıkar. Sıralamaları gerçekten etkileyen alan metrikleri için Core Web Vitals merkezinden başlayın.

AI özeti

Advanced sürümünün kısaltılmış özeti:

• Speed Index = yükleme sırasında içeriğin görsel olarak ne kadar hızlı görüntülendiği — tek bir zaman damgası değil, görünür içeriğin ortaya çıkma süresinin ortalamasını veren bileşik bir puandır. Saniye cinsinden raporlanır; daha düşük daha iyidir.
• Zihinsel model: görsel ilerleme eğrisinin üstündeki alan (zaman ile görsel olarak tamamlanma yüzdesi arasındaki ilişki). Yükleme videosundan hesaplanır; her aralık, sayfanın hâlâ ne kadar tamamlanmamış olduğuna göre ağırlıklandırılır.
• Yalnızca laboratuvar: kare kare ekran görüntüleri gerektirdiği için CrUX’ta, PageSpeed Insights alan verilerinde veya Search Console’da bulunmaz. Alan verileri için Core Web Vitals’ı kullanın.
• Köken: WebPageTest (Pat Meenan, 2008; metrik yaklaşık 2012). Lighthouse bunu WebPageTest ile aynı metodolojiyi kullanan açık kaynaklı Speedline modülüyle hesaplar.
• Core Web Vital değildir, sıralama faktörü değildir. CWV’ler LCP, INP ve CLS’dir. Sıralamalarla bağlantısı dolaylıdır: Speed Index’i düzeltmek genellikle FCP/LCP’yi iyileştirir.
• Lighthouse 10 ağırlığı: 10% — en düşük ağırlık için FCP ile beraberdir. TBT (30%) ve LCP/CLS (her biri 25%) çok daha önemlidir; bu nedenle tek başına Speed Index’in peşinden koşmak düşük yatırım getirisine sahiptir.
• Eşikler (mobil): İyi ≤ 3,4 s, İyileştirme gerekli ≤ 5,8 s, Zayıf > 5,8 s; masaüstünde iyi ≤ ~1,3 s. FCP’den daha hızlı olamaz ve görünüm alanına bağlıdır.
• Düzeltmeler = FCP/LCP düzeltmeleri: daha hızlı TTFB, daha az oluşturmayı engelleyen kaynak, font-display: swap, daha az ana iş parçacığı/JS çalışması, ekranın üst kısmındaki içeriğe öncelik.
• Sınırlamalar: SPA’lar yapay olarak iyi puan alabilir; karuseller, otomatik oynatılan video ve izin katmanları cezalandırılabilir; bu metrik “tamamen yüklendi” ölçümü değildir; görsel ilerleme içeriğin okunabilir, erişilebilir veya kullanılabilir olduğunun kanıtı değildir ve tek bir çalıştırma kodunuzla ilgisi olmayan cihaz, uzantı veya reklam/A-B değişiklikleri nedeniyle değişebilir.

Resmî dokümantasyon

Speed Index için birincil kaynak dokümantasyonu.

Google / Lighthouse

• Speed Index (Lighthouse denetimi) — kanonik başvuru: tanım, Lighthouse’ın bunu Speedline üzerinden nasıl hesapladığı, puanlama eşikleri ve optimizasyon denetimleri.
• Lighthouse performans puanlaması — 10% Speed Index ağırlığının ve tüm metrik dökümünün bulunduğu yer.
• Ana iş parçacığı çalışmasını en aza indirin — Lighthouse’ın Speed Index için yüksek etkili olarak işaretlediği üç denetimden biri.
• JavaScript yürütme süresini azaltın — işaretlenen ikinci denetim.
• Web yazı tipi yüklenirken metnin görünür kalmasını sağlayın (font-display) — işaretlenen üçüncü denetim.

Köken / uygulama

• Speedline (paulirish/speedline) — Lighthouse’ın DevTools izlerinden Speed Index’i hesaplamak için kullandığı açık kaynaklı modül.
• Lighthouse kaynak kodu — speed-index.js — denetimin açıklama sabiti.
• WebPageTest — Hakkında — Pat Meenan, Speed Index’in ortaya çıktığı WebPageTest’i oluşturdu ve açık kaynak hâline getirdi.

Kaynaklardan alıntılar

Kayıtlara geçen ifadeler. Her Google/Lighthouse bağlantısı, alıntılanan bölüme atlayan bir derin bağlantıdır.

Google — Speed Index neyi ölçer?

• “Speed Index measures how quickly content is visually displayed during page load.” (Türkçesi: “Speed Index, içeriğin sayfa yüklenirken ne kadar hızlı görsel olarak gösterildiğini ölçer.”) — Lighthouse Speed Index denetimi. Alıntıya git

Google — puan nasıl belirlenir?

• “Your Speed Index score is a comparison of your page’s speed index and the speed indexes of real websites, based on data from the HTTP Archive.” (Türkçesi: “Speed Index puanınız, HTTP Archive verilerine dayalı olarak sayfanızın Speed Index’i ile gerçek web sitelerinin Speed Index’lerinin karşılaştırılmasıdır.”) — Lighthouse Speed Index denetimi. Alıntıya git

Aktarılan kaynaklar (kelimesi kelimesine alıntılanmamış, ikincil dokümantasyondan parafraz edilmiştir)

• Lighthouse, sayfa yüklenirken bir video yakalar, kareler arasındaki görsel ilerlemeyi hesaplar ve puanı Speedline modülüyle üretir — özgün WebPageTest Speed Index’inin aynı ilkelerine dayanır. (Lighthouse Speed Index denetimi, hesaplama bölümü.)
• Bir kare ne kadar uzun görünür ve sayfa o sırada ne kadar az tamamlanmışsa o kare puana o kadar fazla katkıda bulunur — tüm FCP öncesi süre 100% sayıldığı için Speed Index First Contentful Paint’ten daha hızlı olamaz. (DebugBear, Speed Index belgeleri.)
• Speed Index yalnızca kare kare ekran görüntüsü işlemenin maliyeti nedeniyle sentetik/laboratuvar testlerinde kullanılabilir. (DebugBear, Speed Index belgeleri.)
• Metrik, Pat Meenan’ın 2008’de açık kaynak hâline getirdiği aracın üzerine yaklaşık 2012’de WebPageTest’e eklendi. (KeyCDN; WebPageTest Hakkında sayfası.)

Speed Index kopya kağıdı

Eşikler (Lighthouse 10)

Lighthouse 10 Performance ağırlıkları

Hızlı gerçekler

• Tek bir zaman damgasını değil, zaman içindeki görsel tamamlanmayı (ilerleme eğrisinin üstündeki alanı) ölçer. Daha düşük daha iyidir.
• Yalnızca laboratuvar — CrUX’ta, PSI alan verilerinde veya Search Console’da bulunmaz.
• Core Web Vital değildir; doğrudan sıralama faktörü değildir.
• FCP’den daha hızlı olamaz (FCP öncesi süre 100% sayılır).
• Görünüm alanına bağlıdır — mobil ve masaüstü puanları çok farklıdır.
• Speedline tarafından hesaplanır; kökeni WebPageTest’tir (Pat Meenan).

İyileştirin (FCP/LCP ile aynı)

• TTFB’yi kısaltın (daha hızlı sunucu yanıtı).
• Oluşturmayı engelleyen CSS/JS’yi kaldırın; kritik CSS’yi satır içine alın.
• font-display: swap / optional kullanın; böylece metin görünür kalır.
• Ana iş parçacığı çalışmasını ve JS yürütme süresini en aza indirin.
• Ekranın üst kısmındaki oluşturmayı önceliklendirin.

Yanılmayın

• “1 000 ms’nin altı” güncel Lighthouse mobil eşiği değil, eski WebPageTest rehberliğidir.
• SPA’lar yapay olarak iyi puan alabilir; karuseller cezalandırılabilir.

Speed Index’i raporlayan araçlar

• Lighthouse (Chrome DevTools’ta, CLI’da veya Node modülünde) — Speed Index’i Speedline üzerinden hesaplanan beş Performance metriğinden biri olarak raporlar.
• PageSpeed Insights — Lighthouse’ı çalıştırır ve Speed Index’i laboratuvar (Diagnostics) bölümünde gösterir. Not: yukarıdaki alan verisi bölümü Core Web Vitals’ı kullanır; Speed Index orada hiçbir zaman görünmez.
• WebPageTest — metriğin ortaya çıktığı yer; Speed Index’i, yapılandırılabilir bağlantı profilleriyle Visually Complete ve film şeridi görünümleriyle birlikte raporlar.
• GTmetrix — WebPageTest verilerini kullanarak Speed Index’i arayüzünde gösterir; farklı cihaz/ağ simülasyonu nedeniyle sayıları Lighthouse’ınkiyle eşleşmez.
• DebugBear — Speed Index puanının nasıl hesaplandığını kare kare net biçimde gösteren sentetik izleme.

Araçları karşılaştırırken bir hatırlatma: aynı sayfa, farklı kısıtlama ve cihaz varsayımları nedeniyle Lighthouse, WebPageTest ve GTmetrix’te farklı Speed Index değerleri üretir. Karşılaştırmayı aynı koşullardaki testlerle yapın.

Speed Index’te optimizasyon zamanını boşa harcatan hatalar

• Speed Index’i Core Web Vital sanmak. Bu, alan sıralama sinyali değil, yalnızca laboratuvara ait bir görsel ilerleme metriğidir. Bir sayfanın nasıl dolduğunu teşhis etmek için kullanın, ardından gerçek Core Web Vitals’ı ayrıca kontrol edin.
• Mobil ve masaüstü eşiklerini karşılaştırmak. Lighthouse farklı puanlama eğrileri ve test koşulları kullanır. İki puanı birbirinin yerine koymak yerine tek bir profili zaman içinde izleyin.
• Anlamsız erken boyamayla sayıyı iyileştirmek. Bir başlık kabuğu, birincil içerik boş kalırken görsel ilerlemenin daha erken başlamasını sağlayabilir. Yükleme film şeridini metrikle birlikte inceleyin.
• Kritik yolu kontrol etmeden her görseli optimize etmek. Yavaş TTFB, oluşturmayı engelleyen CSS, yazı tipleri ve eşzamanlı JavaScript tüm görsel diziyi geciktirebilir. Şelaledeki ilk darboğazı bulun ve izini sürün.
• Tek çalıştırma değerinin sabit olmasını beklemek. Speed Index sentetik bir videodan türetilir ve test ortamıyla değişir. Gerileme veya kazanım ilan etmeden önce karşılaştırılabilir çalıştırmaları tekrarlayın.

Kendinizi test edin: Speed Index

Speed Index’in neyi ölçtüğüne ilişkin beş kısa soru. Her biri için bir yanıt seçin, ardından kontrol edin.

Vakit ayırmaya değer kaynaklar

Resmî

• Speed Index — Lighthouse denetimi — kanonik tanım, eşikler ve optimizasyon denetimleri.
• Lighthouse performans puanlaması — Speed Index’in 10% ağırlığı da dâhil olmak üzere metrik ağırlıkları.
• WebPageTest — Hakkında — metriğin kökeni.

Uygulama

• paulirish/speedline — Lighthouse’ın Speed Index’i hesaplamak için kullandığı açık kaynaklı modül.

Diğer kaynaklardan

• DebugBear — Speed Index — hesaplamanın ve FCP ilişkisine dair en anlaşılır adım adım işlenmiş örnek.
• KeyCDN — Speed Index — tarihsel bağlam ve WebPageTest formülü.
• Catchpoint — Speed Index — WebPageTest blogunun devamı; görsel ilerleme formülü ile SPA/karusel sınırlamaları.
• Google Search Central — Core Web Vitals — LCP, INP ve CLS’nin sıralama sinyalleri olduğunu doğrular; Speed Index listelenmez, dolayısıyla doğrudan sıralama etkisinin olmadığı pekişir.
• web.dev — Vitals genel bakış — Core Web Vitals’ın (LCP, INP, CLS) yetkili tanımı; Speed Index yoktur ve sıralamaları neden etkilemediğini açıklarken yararlıdır.
• WebPageTest — Speed Index dokümantasyonu — Pat Meenan’ın WebPageTest’i oluşturmasının (2008’de açık kaynak hâline getirdi) ve Speed Index metriğinin ortaya çıkışının arka planı.

Alıntılanmaya değer sayılar

• Lighthouse ağırlığı: 10% — Lighthouse 10’daki Performance puanının içindedir; en düşük ağırlık için FCP ile beraberdir ve TBT’nin (30%) yanı sıra LCP/CLS’nin (her biri 25%) oldukça gerisindedir. Kaynak
• Mobil “İyi” ≤ 3,4 s; masaüstü “İyi” ≤ 1,3 s — HTTP Archive gerçek web sitesi verilerine göre kalibre edilmiş Lighthouse 10 eşikleri. Kaynak
• Speed Index ≥ FCP, her zaman — ilk içerik boyanmadan önceki tüm süre 100% katkıda bulunur; bu nedenle Speed Index First Contentful Paint’ten daha hızlı olamaz. Kaynak
• Köken: WebPageTest, ~2012 — Pat Meenan’ın 2008’de açık kaynak hâline getirdiği aracın üzerine eklenmiştir. Kaynak

Değişiklik günlüğü