Tek sayfa uygulamaları, Core Web Vitals ve Core Web Vitals'ın bunları nasıl ele aldığı hakkında sık sorulan soruların yanıtları.
Yayınlanma tarihi: 14 Eylül 2021, Son güncelleme tarihi: 11 Ağustos 2026
2020 Mayıs'ta Web Verileri girişimini ilk kez duyurduğumuzdan beri Chrome Ekibi olarak programla ilgili birçok harika soru ve geri bildirim aldık.
Belki de en çok soru aldığımız ve yanıtlaması en zor olan konu, tek sayfalık uygulamalarda (SPA) Core Web Vitals'ın nasıl ölçüleceği ve SPA mimarilerinin Core Web Vitals puanlarını nasıl etkilediğiyle ilgili.
Bu soruların yanıtlanması zordur çünkü sorun oldukça ayrıntılıdır. Bu nedenle, bu yayında en sık sorulan soruları olabildiğince ayrıntılı ve bağlam bilgisi vererek yanıtlamaya çalışacağız.
Ancak ayrıntılara girmeden önce Google'ın bir site oluşturmak için hangi mimarinin veya teknolojinin kullanılacağı konusunda herhangi bir tercihi olmadığını belirtmek önemlidir. Tek sayfa uygulamalarının (SPA'lar) ve çok sayfalı uygulamaların (MPA'lar) kullanıcılara yüksek kaliteli deneyimler sunabileceğine inanıyoruz. Web Vitals girişimiyle amacımız, deneyimi teknolojiden bağımsız olarak ölçen metrikler sağlamaktır.
Sık sorulan sorular
Bu konuyla ilgili en sık sorulan sorulardan bazılarını aşağıda bulabilirsiniz. Geri bildirim grubumuzdan veya sorun bildirerek bu SSS'ye eklemek üzere geri bildirimlerinizi almaktan memnuniyet duyarız.
Core Web Vitals metrikleri, SPA rota geçişlerini içerir mi?
İlk kullanıma sunulduğunda, Core Web Vitals metriklerinin her biri mevcut üst düzey sayfa gezinmesine göre ölçülüyordu. Bir sayfa dinamik olarak yeni içerik yükleyip adres çubuğundaki sayfa URL'sini güncellediğinde bu durum, Core Web Vitals metriklerinin nasıl ölçüldüğünü etkilemez.
Metrik değerleri sıfırlanmadı ve her metrik ölçümüyle ilişkili URL, kullanıcının sayfa yüklemeyi başlatan gezinme işlemi için kullandığı URL'dir.
Chrome 151, Core Web Vitals'ın SPA rota geçişlerinde ölçülmesine olanak tanıyan yeni API'ler kullanıma sundu. Bu makalenin yazıldığı sırada (Ağustos 2026), bu API'ler web-vitals gibi ölçüm kitaplıklarında, RUM çözümlerinde ve Chrome Geliştirici Araçları gibi araçlarda kullanılmaya başlanıyordu. Chrome, bu metriklerin Chrome Kullanıcı Deneyimi Raporu'na (CrUX) entegrasyonuyla ilgili zaman aralıklarını henüz yayınlamadı. Ayrıca, diğer tarayıcı motorları bu yeni API'leri henüz desteklemediğinden Core Web Vitals yalnızca bu tarayıcılarda tam sayfa yüklemeleri için ölçülebilir.
Bu sorunu çözmek neden zordu?
Günümüzde SPA oluşturmanın standart bir yolu yoktur ve popüler SPA ile yönlendirme kitaplıkları arasında bile kullanıcı deneyimi uygulamadan uygulamaya oldukça farklı olabilir:
- Bazı tek sayfa uygulamaları URL'yi yalnızca yeni "tam sayfa" içeriği yüklerken güncellerken diğer siteler URL'yi küçük içerik değişiklikleri veya yalnızca kullanıcı arayüzü durumu değişiklikleri için günceller.
- Bazı SPA'lar URL'yi History API'yi kullanarak güncellerken bazıları eski tarayıcıları desteklemek için karma değişikliklerini kullanır (diğerleri ise URL'yi hiç güncellemez).
- Bazı tek sayfa uygulamaları içeriği yükledikten sonra URL'yi güncellerken bazıları içeriği yüklemeden önce URL'yi günceller.
- Bazı tek sayfa uygulamaları içeriği tek bir JavaScript görevinde eşzamanlı olarak yüklerken diğerleri içeriği eşzamansız olarak birden fazla görevde (net bir geçiş sonu etkinliği olmadan) geçirir.
- Bazı tek sayfa uygulamaları içeriği her zaman ağdan yüklerken bazıları tüm içeriği önceden yükler. Böylece rota değişiklikleri anında bellekten yüklenir.
Bu farklılıklar, SPA rotası değişikliğinin veya SPA'nın ne olduğunu tanımlamayı ve belirlemeyi büyük ölçekte çok zor hale getirir.
Bazı durumlarda, bir SPA rotası değişikliği mantıksal olarak bir MPA sayfa yüklemesiyle aynıdır ve bu gibi durumlarda mevcut Core Web Vitals metriklerinin uygulanabilmesi iyi olur.
Ancak, tüm diğer URL değişikliklerinden "gerçek" rota değişikliklerini güvenilir bir şekilde tanımlamak için sağlam bir sezgisel yöntem olmadan ve bu tür geçişlerin başlangıcını ve sonunu işaretleyen net sinyaller olmadan, bu durumlarda Core Web Vitals metriklerinin raporlanması verileri karıştırır ve sitedeki gerçek kullanıcı deneyimini daha az kullanışlı veya temsili hale getirir.
Yumuşak gezinme çalışması, iki yeni performans API'siyle bu soruna çözüm sunmuştur:
PerformanceSoftNavigation: Kullanıcı etkileşimi hem boyama hem de URL değişikliğine yol açtığında ölçüm yapar. Bu üç öğenin birleşimi, kullanılan çerçeveden ve daha önce bahsedilen bazı farklılıklardan bağımsız olarak "yumuşak gezinme" için standartlaştırılmış bir tanım sağlar. Bu sayede performans zaman çizelgesi ayrı "gezinmelere" bölünebilir ve her gezinme için CLS ve INP ölçülebilir.- Etkileşimden sonraki "içerik boyamalarını" ölçen
InteractionContentfulPaint. Bu sayede FCP ve LCP, bu yumuşak gezinmeler için ölçülebilir.
Bu iki API'nin kombinasyonu, Core Web Vitals'ın hem tam sayfa yüklemeleri hem de yumuşak gezinmeler genelinde ölçülmesine olanak tanır.
SPA rota değişiklikleri, Core Web Vitals için tam sayfa yüklemeleriyle aynı mı?
Hayır, bu gezinme türleri arasında farklı Core Web Vitals metriklerine yol açabilecek birçok fark vardır.
Yumuşak gezinme, sayfada içerik bulundurur ve yeni "sayfayı" göstermek için bu içeriğin bir kısmını veya tamamını günceller. Bu durum, birçok açıdan, sayfa kaynaklarının bir kısmı veya tamamı önbelleğe alınmışken yapılan sayfa yüklemesi ile önbelleğe alınmamış tam sayfa yüklemesi arasındaki farka benzer. Ancak bazı içerikler oluşturulmuş halde kalabileceğinden bu durum daha da uç bir noktaya ulaşabilir.
Teorideki temel fark, yumuşak gezinmelerin çok daha hızlı olabilme potansiyelidir. Ancak daha ince farklılıklar da vardır.
Yeni yumuşak gezinme API'leri yalnızca yeni içeriği dikkate alır. Bu nedenle, <h1> ve metin içeriğini güncelleyen ancak sayfalar arasında aynı hero resmini bırakan bir sayfada, yeniden boyanmadığı takdirde hero resmi LCP adayı olarak kabul edilmez. Bu durum, aynı sayfanın tam sayfa yüklemesi olarak mı yoksa başka bir mevcut sayfadan yumuşak gezinme olarak mı yüklendiğine bağlı olarak LCP süresini hesaplamak için kullanılan öğelerde farklılıklara yol açar.
Benzer şekilde, siteyi çalıştırmak için gereken JavaScript'in çoğu zaten yüklendiğinden INP, yumuşak gezinmelerde daha düşük olabilir. Aynı şekilde, yumuşak gezinme daha az (veya daha fazla!) Aynı içerik tam sayfa yüklemede CLS'ye neden oluyorsa ancak yumuşak gezinmede yüklenmesi veya yeniden oluşturulması gerekmiyorsa CLS
Ayrıca, tam sayfa yüklemelerinde (gezinme etkileşimi işlendikten sonra ölçülür) ve yumuşak gezinmelerde (etkileşim başlangıç zamanından itibaren ölçülür) ölçümlerin ne zaman alındığı konusunda da küçük farklılıklar vardır.
Daha önce de belirtildiği gibi, bu farklılıkların çoğu önbelleğe alınmamış ve alınmış sayfalar arasındaki farklara benzer. Core Web Vitals'ın ölçmeye çalıştığı kavram geçerliliğini korur. Ancak Core Web Vitals sorunlarını incelerken bu ayrıntıları anlamak faydalı olacaktır.
Tek sayfa uygulamalarının Core Web Vitals'da iyi performans göstermesi çok sayfalı uygulamalara kıyasla daha mı zordur?
SPA mimarisinde, bir SPA'daki sayfanın bir MPA'daki benzer bir sayfa kadar hızlı yüklenmesini ve tüm Core Web Vitals metriklerinde aynı derecede iyi puan almasını engelleyecek hiçbir şey yoktur.
Ancak, düzgün şekilde optimize edilmiş çok sayfalık uygulamalar, tek sayfalık uygulamalarda olmayan bazı avantajlara sahiptir. Bu avantajlar, Önemli Web Verileri eşiklerini karşılamayla ilgilidir. Bu sorun, daha önce bahsedilen yumuşak gezinme çalışmasıyla büyük ölçüde giderilmiştir ancak bu yeni API'ler henüz kullanılmadığında sorun devam edebilir. Bunun nedeni, MPA mimarisinde her "sayfanın" tam sayfa gezinme olarak yüklenmesidir (içeriği dinamik olarak getirip mevcut sayfaya eklemek yerine). Bu da MPA'yı ziyaret eden kullanıcıların siteden birden fazla sayfa yükleme olasılığının daha yüksek olduğu anlamına gelir. Bu da MPA'daki tüm sayfa yüklemelerinin dağıtımının daha büyük bir yüzdesinin, alt kaynakların bir kısmının veya tamamının önbelleğe alınmasını içereceği anlamına gelir.
Elbette, bir MPA'nın Core Web Vitals metriklerinde SPA'dan daha iyi performans göstermesi için birkaç koşulun karşılanması gerekir:
- MPA'nın, aynı kaynaklı sayfa yüklemelerinin 75. yüzdelik dilimde gerçekten kaynaklar arası sayfa yüklemelerinden daha hızlı olmasını sağlamak için alt kaynak önbelleğe almayı optimize etmesi gerekir.
- MPA'ları ziyaret eden kullanıcıların, sitenin daha hızlı sayfa yüklemeleri sağlayan önbelleğe alma avantajlarından yararlanabilmesi için birden fazla sayfayı ziyaret etmesi gerekir.
Core Web Vitals değerlendirmelerinde sayfa ziyaretlerinin 75. yüzdelik dilimi dikkate alındığından veri kümesinde daha fazla sayıda iyi performans gösteren sayfa ziyareti olması, dağılımın 75. yüzdelik dilimindeki ziyaretin önerilen eşikler içinde olma olasılığını artırır.
Core Web Vitals puanlarını karşılaştırırken göz önünde bulundurulması gereken önemli bir nokta, verilerin nasıl toplandığıdır. Yani dağıtımdaki veri kümesi, sitenizdeki veya kaynağınızdaki tüm sayfaları mı yoksa yalnızca belirli bir sayfa URL'si için sayfa yüklemelerini mi içerir?
Bir kaynakta tüm sayfaların puanları toplanırken, tek tek hızlı sayfalar kaynağın genel olarak 75. yüzdelik dilimini iyileştirebilir. Ancak, tek tek sayfalara göre toplama yapıldığında bir sayfanın puanları bir sonraki sayfanın puanlarını etkilemez. Başka bir deyişle, bir MPA'nın puanları sayfaya göre toplandığında, ödeme sayfasında görülen hızlı önbellek yüklemeleri, sitenin açılış sayfasında yaşanan yavaş ilk yüklemelerin puanlarını iyileştirmez.
PageSpeed Insights veya hem tek tek sayfa URL'leri hem de kaynağın tamamı için puanları bildiren Chrome Kullanıcı Deneyimi Raporu API'sini kullanarak sitenizin farklı toplama yöntemlerine göre puanını kontrol edebilirsiniz.
SPA mimarisinin Core Web Vitals puanlarını etkileyebileceği bir diğer yol da bir sayfanın tam kullanım ömrünü dikkate alan metriklerdir. SPA'ları ziyaret eden kullanıcılar oturum boyunca aynı "sayfada" kalma eğiliminde olduğundan, zaman içinde biriken metrikler SPA'lar için MPA'lara kıyasla daha olumsuz olabilir.
Yumuşak gezinme özelliği sayesinde, Core Web Vitals'ın ölçülme şekli açısından tek sayfa uygulamalarının herhangi bir dezavantajı olmayacağını düşünüyoruz. Ancak bu API'lerin tüm araç ve raporlama çözümlerine tam olarak entegre edilmesi zaman alacaktır.
SPA mimarileri kullanıcı deneyimini iyileştiriyorsa bu iyileşme metriklerde yansıtılmalı değil mi?
Evet, olmalıdır. Tek sayfalı uygulamaların web'de bugün uygulandığı tüm farklı yöntemler göz önüne alındığında, deneyimin ne kadar iyileştiğini ölçekli olarak ölçmek zordu. Artık ölçüm sorununa yönelik bir çözümümüz var ve bu yeni API'ler kullanıldığında, SPA'lara geçişten kaynaklanan tüm iyileştirmeler metriklere yansıtılmalıdır.
Gerçek şu ki web performansı sektörü (Google dahil) geçmişte bir sayfanın yükleme sonrası performansı için kullanıcı odaklı metrikler geliştirmeye, sayfa yükleme için harcadığı kadar zaman ve çaba harcamadı. Bunun nedeni, yükleme sonrası performansın önemli olmaması değil, yükleme sonrası kullanıcı deneyimi ve etkileşimlerin çok daha çeşitli ve daha az tanımlanmış olmasıdır. Bu durum, bu etkileşimler için metrik tasarlamayı zorlaştırır.
Ancak artık SPA performansını ölçmek için yükleme sonrası daha fazla metriğe sahip olsak da yükleme sonrası deneyim iyileştiği için yükleme deneyimini göz ardı etmek istemeyiz.
Web Vitals girişiminin hedeflerinden biri, web sayfasının yüklenmesi ve kullanılmasıyla ilgili mümkün olduğunca çok konuda iyi kullanıcı deneyimlerini teşvik etmek ve desteklemektir. Yeterli sayıda iyi deneyimle telafi edebileceğiniz kötü deneyimlerin haklı gösterilmesini istemiyoruz. Kullanıcılar sayfaların hızlı yüklenmesini ve yeni içeriğe hızlı geçiş yapılmasını ister. Bu nedenle, bu tür deneyimleri destekleyen metrikler tasarlamaya çalıştık.
Sitemizi MPA'dan SPA'ya geçirdik ve puanlarımız geriledi. Bu beklenen bir durum mu?
Duruma göre değişir. Büyük bir mimari taşıma işleminden sonra puanlarınızın değişmesinin çeşitli nedenleri olabilir. Ancak, sıcak önbellek yükleme sayısındaki azalma, bu değişikliğin bir kısmını açıklayabilir.
Hızlı bir kontrol için açılış sayfalarınızdan birinin hem MPA hem de SPA sürümünü Lighthouse ile test edebilirsiniz. Lighthouse puanı, SPA sürümünün Core Web Vitals metriklerinden herhangi birinde daha düşükse güncellemeden sonra yükleme deneyiminin kötüleşmiş olması muhtemeldir.
Core Web Vitals'da daha iyi puan almak için sitemi SPA'dan MPA'ya geçirmeli miyim?
Muhtemelen karşılaşmazsınız. Yalnızca SPA yığınınızdan memnun değilseniz ve MPA'nın daha iyi bir kullanıcı deneyimi sağlayacağına inanmak için nedenleriniz varsa SPA'dan MPA'ya geçmelisiniz.
Yumuşak gezinme özelliğiyle ilgili çalışmalarımız sayesinde ölçüm sorunlarını çözdüğümüzü düşünüyoruz. Bu nedenle, yalnızca bu özellik için geçiş yapmanız mantıklı olmayacaktır.
Ancak, yalnızca ölçümlerin iyileşmesi yerine performansın iyileşeceğini göstermek için bir nedeniniz varsa bu, SPA'dan MPA'ya (veya tam tersi) geçmek için bir neden olabilir.
Core Web Vitals puanları yalnızca bir SPA'nın açılış sayfaları için bildiriliyorsa rota geçişinden sonra "sayfalarda" oluşan sorunlarda nasıl hata ayıklayabilirim?
Core Web Vitals metriği için alan verilerini bildiren Google araçları (ör. Search Console ve PageSpeed Insights) verilerini Chrome Kullanıcı Deneyimi Raporu (CrUX) üzerinden alır. CrUX, verileri kaynak veya sayfa URL'sine (yani yükleme sırasındaki sayfa URL'si) göre toplar.
CrUX'un, toplu verilerinde SPA rotasına göre verileri içermesine olanak tanımak için çalışıyoruz. Ancak site sahibi olarak, puanlarınızın nasıl değişebileceğini anlamak için bu değişiklikten önce Core Web Vitals'ı SPA rotasına göre ölçmek üzere yeni API'leri kullanabilirsiniz.
Bu konuyla ilgili daha fazla ayrıntı ve en iyi uygulamalar için Yumuşak gezinmeleri ölçme başlıklı makaleyi inceleyin.
Google, MPAs'in SPAs'e kıyasla haksız avantaj elde etmemesini sağlamak için ne yapıyor?
Daha önce de belirtildiği gibi, yumuşak gezinme özelliğiyle ilgili çalışmalarımız sayesinde, tüm araç ve raporlama çözümlerinde tam entegrasyon zaman alsa da bu konuda tek sayfa uygulamalarının herhangi bir dezavantajı olmayacağını düşünüyoruz.
Çapraz kaynaklı ve aynı kaynaklı sayfa ziyaretlerini ayrı ayrı değerlendirme
Bugün Core Web Vitals metrikleri, tüm sayfa ziyaretlerini tek bir pakette toplar. Yeni ziyaretler ile geri gelen ziyaretler veya açılış sayfaları ile ödeme sayfaları arasında ayrım yapmaz. Ayrıca, önbellek durumunun performansı etkileyebileceği diğer toplama türleri arasında da ayrım yapmaz.
SPA ve MPA performansı arasındaki farklılıkları normalleştirmenin bir yolu, farklı ziyaret türlerine farklı ağırlıklar uygulamaktır. Hatta bu ağırlıklar, tamamen farklı eşik önerileri içerebilir.
Etkili önbellek uygulamalarını kesinlikle ödüllendirmek istesek de hızlı site içi gezinmelerin yavaş açılış sayfası yüklemelerini telafi etmesini istemiyoruz. Ayrıca, siteleri yalnızca metrik puanlarını iyileştirmek için uzun sayfaları daha kısa sayfalara bölmeye teşvik etmek de istemiyoruz.
Çapraz kaynaklı ve aynı kaynaklı sayfa ziyaretlerini ayrı ayrı değerlendirerek, belirli bir sitede bir türün göreceli popülerliğinin belirli bir metriğin dağılımını çarpıtmasına izin vermeden her iki deneyim türünün de önemli olmasını sağlayabiliriz.
Son düşünceler
Google, Web Verileri metriklerini iyileştirmeye ve kullanıcılar için önemli olan yüksek kaliteli deneyimleri ölçüp teşvik etmelerini sağlamaya büyük önem vermektedir. Bununla birlikte, günümüzde ölçüm boşluklarının olduğunu kabul ediyoruz. Metrikler artık ana boşluklardan birini ele alan SPA rota geçişlerini kapsayabiliyor.
Ayrıca bu yeni API'lerin (özellikle InteractionContentfulPaint) yumuşak gezinmeler için Core Web Vitals ölçümünün ötesinde başka kullanım alanları ve potansiyel avantajları olduğuna inanıyoruz. Bu özelliklerin kullanıma sunulmasının temel nedeni ele alındığından, bu özellikleri geliştirmeye devam etmekten heyecan duyuyoruz.
Bu yayının, karmaşık ve ayrıntılı bir konu olan bu konuya biraz ışık tuttuğunu umuyoruz. Her zaman olduğu gibi, mevcut veya gelecekteki Web Verileri metrikleriyle ilgili geri bildiriminiz varsa web-vitals-feedback@googlegroups.com adresine e-posta gönderin.