Önemli Web Verilerini İyileştirme, Çarpıcı Bir Dergi Vaka Çalışması

"Önemli Web Verilerim neden başarısız oluyor?" Birçok geliştirici son zamanlarda kendilerine bu soruyu soruyor. Bazen bu sorunun cevabını bulmak yeterince kolaydır ve sitenin sadece performansa yatırım yapması gerekir. Bazen, biraz daha yanıltıcıdır ve sitenizin performans açısından harika olduğunu düşünmesine rağmen, bir nedenden dolayı yine de başarısız olur. Kendi smashingmagazine.com'umuza olan buydu ve sorunu çözmek ve düzeltmek biraz araştırma gerektirdi.

Yardım Çığlığı

Her şey, geçen Mart ayında bir dizi tweet'in yardım çağrısıyla başladı:

Pekala, bu ilgimi çekti! Smashing Magazine'in büyük bir hayranıyım ve web performansı ve Önemli Web Verileri ile çok ilgileniyorum. Burada daha önce Önemli Web Verileri hakkında birkaç makale yazdım ve her zaman onların yıllık Web Performansı Kontrol Listelerinde neler olduğunu görmek isterim. Yani, Smashing Magazine web performansını biliyor ve eğer zorlanıyorlarsa, bu ilginç bir test vakası olabilir!

Birkaçımız, WebPageTest veya PageSpeed ​​Insights gibi favori web performans analiz araçlarımızdan bazılarını kullandıktan sonra sorunun ne olabileceği konusunda bazı önerilerde bulunduk.

LCP Sorununun İncelenmesi

Sorun, LCP'nin mobil cihazlarda çok yavaş olmasıydı. LCP veya En Büyük İçerikli Boya, Sayfa Deneyimi Güncellemesinin bir parçası olarak Google'dan tam arama sıralaması yükseltmesi elde etmek için "geçmeniz" gereken üç Temel Web Verisinden biridir. Adından da anlaşılacağı gibi, LCP, sayfanın en büyük içeriğinin ekrana ne zaman çizildiğini (veya "boyalı") ölçmeyi amaçlar. Genellikle bu, kahraman resmi veya başlık metnidir. Site ziyaretçisinin buraya muhtemelen ne görmeye geldiğini ölçmek için tasarlanmıştır.

Önceki ölçümler, ekrana ilk boyanın varyasyonlarını ölçtü (bu genellikle bir başlık veya arka plan rengiydi); kullanıcının gerçekten sayfadan çıkmak istediği şey olmayan tesadüfi içerik. En büyük içerik genellikle iyi bir gösterge veya en önemli şeydir. Ve adın "içerikli" kısmı, bu metriğin göz ardı edilmesinin amaçlandığını gösterir (örneğin arka plan renkleri); bunlar en büyük içerik olabilirler, ancak “içerikli” değillerdir, bu nedenle LCP için sayılmazlar ve bunun yerine algoritma daha iyi bir şey bulmaya çalışır.

LCP yalnızca ilk görünüm alanına bakar. Sayfayı aşağı kaydırdığınız veya sayfayla başka bir şekilde etkileşime girdiğiniz anda LCP öğesi sabitlenir ve sayfanın ilk yüklenmeye başladığı andan itibaren bu öğeyi çizmenin ne kadar sürdüğünü hesaplayabiliriz - ve bu sizin LCP'nizdir!

Önemli Web Verilerinizi ölçmenin birçok yolu vardır, ancak kesin yol - en iyi yol olmasa da, yakında göreceğimiz gibi - Google Arama Konsolu'nda (GSC) bulunur. SEO açısından bakıldığında, diğer araçların size ne söylediği önemli değil, Google Arama'nın gördüğü şey GSC'dir. Elbette, bazı arama motoru tarayıcılarının ne gördüğünden çok kullanıcılarınızın ne deneyimlediği önemlidir, ancak Önemli Web Verileri girişiminin en güzel yanlarından biri, Google Bot'un gördüklerinden ziyade gerçek kullanıcı deneyimini ölçmesidir! Dolayısıyla, GSC kötü deneyimleriniz olduğunu söylüyorsa , kullanıcılarınıza göre kötü deneyimleriniz var demektir.

Search Console, Smashing Magazine'e, sayfalarının çoğu için mobil LCP'lerinin iyileştirilmesi gerektiğini söyledi. GSC'nin bu bölümünün yeterince standart bir çıktısı ve oldukça kolay adreslenebilir: sadece LCP öğenizi daha hızlı çizin! Bu çok uzun sürmemeli. Kesinlikle altı ay değil (ya da biz öyle düşündük). Bu nedenle, ilk önce LCP öğesinin ne olduğunu bulmaktır.

WebPageTest aracılığıyla başarısız bir makale sayfası çalıştırmak, LCP öğesini vurguladı:

LCP Görüntüsünü İyileştirme

Tamam, makale yazarının fotoğrafı LCP öğesidir. İlk içgüdü, bunu daha hızlı hale getirmek için ne yapabileceğimizi sormaktır. Bu, şelaleleri araştırmayı, görüntünün ne zaman istendiğini, indirmenin ne kadar sürdüğünü ve ardından bunun nasıl optimize edileceğine karar vermeyi içerir. Burada, görüntü boyut ve biçim açısından iyi bir şekilde optimize edilmiştir (genellikle görüntülerin performansını iyileştirmek için ilk ve en kolay seçenek!). Görüntü, ayrı bir varlık alanından sunuldu (genellikle performans açısından kötü), ancak bunu kısa vadede değiştirmek mümkün olmayacaktı ve Smashing Magazine, bunu en iyi şekilde hızlandırmak için zaten bir preconnect kaynak ipucu eklemişti. abilir.

Daha önce de bahsettiğim gibi, Smashing Magazine web performansını biliyor, performanslarını geliştirmek için daha yeni çalıştı ve burada her şeyi yaptı, ancak yine de başarısız oldu. İlginç…

Yükün azaltılması, hizmet çalışanının geciktirilmesi (çekişmeyi önlemek için) veya HTTP/2 önceliklerinin araştırılması dahil olmak üzere diğer öneriler sunuldu, ancak bunlar LCP zamanlaması üzerinde gerekli etkiye sahip değildi. Bu nedenle, burada başka neler yapabileceğimizi görmek için tüm ipuçları ve püf noktaları için web performansı araç çantamıza erişmemiz gerekti.

Bir kaynak sayfanın yüklenmesi için kritik öneme sahipse, onu satır içi yapabilirsiniz, böylece HTML'nin kendisine dahil edilir. Bu şekilde, sayfa, ilk boyamayı gecikme olmadan yapmak için gereken her şeyi içerir. Örneğin, Smashing Magazine hızlı bir ilk boyamaya izin vermek için kritik CSS'yi zaten satır içine alıyor, ancak yazarın görüntüsünü satır içine koymadı. Inlineing iki ucu keskin bir kılıçtır ve dikkatli kullanılmalıdır. Sayfayı güçlendirir ve sonraki sayfa görüntülemelerinin, verilerin önceden indirilmiş olması gerçeğinden yararlanmadığı anlamına gelir. Bu nedenle aşırı satır içileştirme hayranı değilim ve dikkatli kullanılması gerektiğini düşünüyorum.

Bu nedenle, normalde satır içi görüntülere önerilmez. Ancak, burada görüntü bize gerçek sorunlara neden oluyordu, oldukça küçüktü ve doğrudan sayfaya bağlıydı. Evet, bir yazara ait çok sayıda makale okuduysanız, yazarın görselini bir kez indirip yeniden kullanmak yerine aynı görseli birden çok kez yeniden indirmek israftır, ancak büyük olasılıkla, farklı yazarların farklı makalelerini okumak için buradasınız. .

Son zamanlarda görüntü formatlarında birkaç gelişme oldu, ancak AVIF burada olduğu için (en azından Chrome ve Firefox'ta) heyecana neden oluyor ve geleneksel olarak fotoğraflar için kullanılan eski JPEG formatlarına göre etkileyici sıkıştırma sonuçlarına sahip. Vitaly, yazar resimlerinin JPEG sürümünü satır içine almak istemedi, ancak AVIF sürümünü satır içine almanın işe yarayıp yaramayacağını araştırdı. Yazar görüntüsünü AVIF kullanarak sıkıştırmak ve ardından görüntüyü HTML'ye temel 64-ing yapmak, HTML sayfa ağırlığında 3 KB'lik bir artışa yol açtı - bu çok küçük ve bu nedenle kabul edilebilirdi.

AVIF o zamanlar yalnızca Chrome'da desteklendiğinden (tüm bunlardan sonra Firefox'a geldi) ve Core Web Vitals bir Google girişimi olduğundan, bir Google fermanı nedeniyle bir Google tarayıcısı için optimizasyon yapmak biraz "ukala" geldi. Chrome genellikle yeni özellik desteğinin ön saflarında yer alır ve bu övgüye değer, ancak işinin bu iki tarafı birbirini etkilediğinde her zaman biraz eksik hisseder. Yine de bu, yalnızca Chrome'a ​​özgü bazı özel biçimler yerine yeni bir standart resim biçimiydi (başlangıçta yalnızca Chrome'da destekleniyor olsa bile) ve performans için aşamalı bir geliştirmeydi (Safari kullanıcıları hala aynı içeriği alıyor, ancak o kadar hızlı değil ), böylece AVIF bükümünün eklenmesiyle Smashing öneriyi aldı ve görüntüyü sıraladı ve gerçekten de laboratuvar araçlarında etkileyici sonuçlar gördü. Sorun çözüldü!

Alternatif Bir LCP

Bu yüzden, o yatağı yatırdık ve Temel Web Verileri sayılarının yeşile dönmesi için her zamanki 28 gün kadar bekledik… ama yapmadılar. Yeşil ve kehribar arasında gidip geldiler, bu yüzden kesinlikle işleri iyileştirdik, ancak sorunu tamamen çözmedik. Vitaly, kehribar rengi “iyileştirme gerekiyor” bölümünde uzun bir süre kaldıktan sonra, başka bir fikir olup olmadığını görmek için elini uzattı.

Görüntü hızla çizildi. Tam olarak anında değil (sonuçta bir görüntüyü işlemek hala zaman alıyor) ama olabildiğince yakın. Dürüst olmak gerekirse, fikirlerim tükeniyordu ama taze gözlerle bir kez daha baktım. Sonra aklıma alternatif bir fikir geldi — doğru LCP öğesini mi optimize ediyorduk? Yazarlar elbette önemlidir, ancak okuyucunun buraya gerçekten görmek için geldiği şey bu mu? Egolarımız evet demek istese de ve güzel parlayan kupalarımız yazdığımız içerikten çok daha önemli olsa da, okuyucular muhtemelen bunu düşünmüyorlar (okuyucular, ha - ne yapabilirsiniz!).

Okuyucu makale için geldi, yazar için değil. Dolayısıyla LCP öğesi bunu yansıtmalıdır, bu da LCP görüntü çizimi sorununu çözebilir. Bunu yapmak için sadece başlığı yazar resminin üstüne koyduk ve mobilde yazı tipi boyutunu biraz artırdık. Bu, kullanıcılar pahasına Core Web Vital SEO Tanrılarını kandırmak için sinsi bir numara gibi gelebilir, ancak bu durumda, her ikisine de yardımcı olur! Pek çok site, gerçek kullanıcılar yerine GoogleBot'u hızlı ve kolay bir şekilde hacklemeye veya optimize etmeye çalışsa da, bu böyle değildi ve buradaki karardan oldukça memnunduk. Aslında, daha fazla ince ayar, yazar resmini tamamen mobil görünümde kaldırır, burada sınırlı alan vardır ve bu makale LCP öğesi vurgulanmış olarak şu anda mobilde şöyle görünür:

Burada başlığı, makaleyle ilgili temel bilgileri ve özetin başlangıcını gösteriyoruz - kullanıcı için büyük bir fotoğrafla tüm değerli mobil ekran alanını kaplamaktan çok daha kullanışlı!

Önemli Web Verileri hakkında sevdiğim en önemli şeylerden biri de bu: kullanıcı deneyimini ölçüyorlar.

Metrikleri iyileştirmek için deneyimi iyileştirmeniz gerekir.

“

Ve ŞİMDİ sonunda işimiz bitti. Metin, resimlerden çok daha hızlı çizilir, bu nedenle LCP sorununu çözmelidir. Hepinize çok teşekkür ederim ve iyi geceler!

Google Arama Konsolundaki CWV Grafiğinden Nefret Ediyorum…

Yine hayal kırıklığına uğradık. Bu, sorunu çözmedi ve Google Arama Konsolu grafiğinin kehribar rengine dönmesi çok uzun sürmedi:

Bu noktada sayfa gruplamalarından ve Temel Web Verilerinden biraz daha bahsetmemiz gerekiyor. Yukarıdaki grafikten, hemen hemen tüm grafiğin aynı anda sallandığını fark etmiş olabilirsiniz. Ancak çoğu zaman yeşil kalan yaklaşık 1.000 sayfalık bir çekirdek grup da vardı. Nedenmiş?

Google Arama Konsolu, sayfaları sayfa gruplamalarına göre sınıflandırır ve bu sayfa gruplamalarının Önemli Web Verileri metriklerini ölçer. Bu, anlamlı kullanıcı deneyimi verilerine sahip olmak için yeterli trafik almayan sayfalar için eksik verileri doldurma girişimidir. Bununla başa çıkmanın birkaç yolu var: bu tür sayfalara herhangi bir sıralama artışı vermemiş olabilirler veya belki de en iyisini varsaymış ve herhangi bir veri içermeyen sayfalara tam bir destek vermiş olabilirler. Veya kaynak düzeyindeki temel web hayati verilerine geri dönmüş olabilirler. Bunun yerine, daha akıllıca bir şey yapmaya çalıştılar; bu, yardımcı olma girişimiydi, ancak birçok yönden daha da kafa karıştırıcıydı: Sayfa gruplamaları .

Temel olarak, her sayfaya bir sayfa gruplaması atanır. Bunu nasıl yaptıkları açıklanmadı, ancak sayfada kullanılan URL'ler ve teknolojilerden daha önce bahsedilmişti. Ayrıca, Google'ın sayfalarınızın her biri için hangi gruplamaları seçtiğini ve algoritmalarının doğru yapıp yapmadığını göremezsiniz; bu, web sitesi sahipleri için başka bir can sıkıcı şeydir, ancak grafiğin altında her bir farklı Önemli Web Verisi puanı için örnek URL'ler verirler. gruplandırmanın bazen ima edilebileceği Google Arama Konsolu'nda.

Sayfa gruplamaları, Smashing Magazine gibi siteler için iyi sonuç verebilir. Diğer siteler için sayfa gruplamaları daha az net olabilir ve birçok sitede yalnızca bir gruplama olabilir. Ancak Smashing sitesinde birkaç farklı sayfa türü vardır: makaleler, yazar sayfaları, kılavuzlar vb. Yazar resmi LCP resmi olduğu için bir makale sayfası yavaşsa, bu muhtemelen tüm makale sayfaları için geçerli olacaktır. Ve düzeltme muhtemelen tüm makale sayfaları için aynı olacaktır. Bu yüzden onları bir arada gruplamak mantıklıdır (Google'ın sayfa gruplamalarını doğru bir şekilde çözebileceğini varsayarsak).

Ancak, bir sayfanın kendi Önemli Web Verileri puanını almaya yetecek kadar ziyaretçi alması ve sayfanın geçmesi, ancak başarısız bir grupla bir araya gelmesi kafa karıştırıcı hale gelebilir. Sitenizdeki tüm sayfalar için CrUX API'sini arayabilir, çoğunun geçtiğini görebilir, ardından aynı sayfalar Search Console'da başarısız olarak göründüğünde kafanız karışabilir, çünkü bunlar başarısız URL'lere sahip bir grupta toplanmıştır ve çoğu o grubun trafiği başarısız olmak içindir. Yine de, Search Console'un sahip olduğu zaman gruplama verilerini kullanmak yerine sayfa düzeyindeki Önemli Web Verilerini kullanması gerekip gerekmediğini merak ediyorum.

Her neyse, bu büyük dalgalanmaları açıklıyor. Temel olarak, tüm makaleler (yaklaşık 3.000 tane var) aynı sayfa grubunda görünüyor (mantıksız değil!) ve bu sayfa gruplaması ya başarılı ya da başarısız oluyor. Değiştiğinde, grafik çarpıcı biçimde hareket eder .

Ayrıca CrUX API aracılığıyla Önemli Web Verileri hakkında daha ayrıntılı veriler elde edebilirsiniz. Bu, kaynak düzeyinde (yani tüm site için) veya tek tek URL'ler için (yeterli verinin bulunduğu yerlerde) mevcuttur, ancak can sıkıcı bir şekilde sayfa gruplama düzeyinde değildir. LCP'nin daha kesin bir ölçüsünü elde etmek için CrUX API'sini kullanarak başlangıç ​​seviyesi LCP'yi izliyordum ve bu da iç karartıcı bir hikaye gösterdi:

Sorunu hiçbir zaman gerçekten “çözemediğimizi” ve “İyi” sayfaların (yukarıdaki yeşil çizgi) miktarının hala %75 geçiş oranına çok yakın olduğunu görebiliyoruz. Ek olarak, p75 LCP puanı (sağ ekseni kullanan noktalı çizgi) 2500 milisaniye eşiğinden hiçbir zaman yeterince uzaklaşmadı. Geçen ve başarısız olan sayfaların bir ileri bir geri dönmesine şaşmamak gerek. Birkaç yavaş sayfa yüklemesiyle birlikte biraz kötü bir gün, tüm sayfa gruplamasını "iyileştirme ihtiyacı" kategorisine çevirmek için yeterliydi. Bu “kötü günleri” özümsemek için bize biraz boşluk bırakacak daha fazla şeye ihtiyacımız vardı.

Bu noktada, daha fazla optimize etmek cazip geldi . Makale başlığının LCP öğesi olduğunu biliyoruz, bu yüzden bunu daha da geliştirmek için ne yapabiliriz? Bir yazı tipi kullanır ve yazı tipleri her zaman web performansının bir baş belası olmuştur, bu yüzden buna bakabiliriz.

Ama bir dakika bekle. Smashing Magazine hızlı bir siteydi. Lighthouse ve WebPageTest gibi web performans araçlarıyla çalıştırmak, daha düşük ağ hızlarında bile bunu gösterdi. Ve her şeyi doğru yapıyordu! Statik bir site oluşturucu olarak inşa edildi, bu nedenle herhangi bir sunucu tarafı oluşturma işleminin gerçekleşmesini gerektirmedi, ilk boyama için her şeyi sıraladı, böylece HTML'nin kendisinden başka kaynak yükleme kısıtlamaları olmadı, Netlify tarafından bir CDN'de barındırıldı, bu nedenle kullanıcılarına yakın olmalıdır.

Elbette, yazı tipini kaldırmayı düşünebiliriz, ancak Smashing Magazine tüm bunlara rağmen hızlı bir deneyim sunamıyorsa, o zaman başka biri nasıl yapabilir? Önemli Web Verilerini geçmek imkansız olmamalı ve yalnızca yazı tipi veya resim içermeyen düz bir sitede olmanızı gerektirmemelidir. Burada başka bir şey daha vardı ve körü körüne başka bir optimizasyon turunu denemek yerine neler olup bittiği hakkında biraz daha fazla şey öğrenmenin zamanı gelmişti.

Metrikleri Biraz Daha Derine İnmek

Smashing Magazine'in bir RUM çözümü yoktu, bunun yerine Google'ın ilk 8 milyona yakın web sitesi için topladığı Chrome Kullanıcı Deneyimi Raporu (CrUX) verilerini inceledik ve ardından bu verileri çeşitli biçimlerde sorgulamak için kullanılabilir hale getirdik. Google Arama Konsolu verilerini ve nihayetinde sıralama etkisini yönlendiren bu CrUX verileridir. Yukarıdaki CrUX API'sini zaten kullanıyorduk ancak diğer CrUX kaynaklarını araştırmaya karar verdik.

Kullanılabilir olduğu tüm site için tüm CrUX verilerine bakmak için site haritasını ve bir Google E-Tablolar komut dosyasını kullandık (Fabian Krumbholz o zamandan beri bunu kolaylaştırmak için çok daha kapsamlı bir araç oluşturdu!) ve sayfalar için karışık sonuçlar gösterdi. Bazı sayfalar geçti, diğerleri, özellikle eski sayfalar başarısız oldu.

CrUX panosu bize bu durumda zaten bilmediğimiz pek bir şey söylemedi: LCP sınırdaydı ve ne yazık ki düşüş eğiliminde değildi:

Diğer istatistikleri (TTFB, First Paint, Online, DOMContentLoaded) incelemek bize herhangi bir ipucu vermedi. Bununla birlikte, mobil kullanımda gözle görülür bir artış oldu:

Bu, mobil benimsemede genel bir eğilimin parçası mıydı? Yaptığımız iyileştirmelere rağmen mobil LCP'yi etkileyen şey bu olabilir mi? Sorularımız vardı ama cevapları veya çözümleri yoktu.

Bakmak istediğim şeylerden biri trafiğin küresel dağılımıydı. Google Analytics'te Hindistan'dan eski makalelere çok fazla trafik geldiğini fark ettik. Bu bir sorun olabilir mi?

Hindistan Bağlantısı

Ülke düzeyinde CrUX verileri, CrUX panosunda bulunmaz ancak BigQuery CrUX veri kümesinde bulunur ve orada www.smashingmagazine.com kaynak düzeyinde bir sorgu çalıştırmak, LCP değerlerinde büyük bir eşitsizlik gösterir (SQL, Aynı şeyi kendi etki alanınızda denemek istemeniz durumunda, bu bağlantının ikinci sekmesi btw). Google Analytics'teki ilk 10 ülkeye göre aşağıdaki verilere sahibiz:

Hindistan trafiği Smashing Magazine için büyük bir oran (%16) ve başlangıç ​​düzeyinde LCP hedefini karşılamıyor. Sorun bu olabilir ve kesinlikle daha fazla araştırmaya değerdi . Çok kötü puanlara sahip Filipinler ve Pakistan verileri de vardı, ancak bu nispeten küçük bir trafik miktarıydı.

Bu noktada, burada neler olabileceğine dair bir fikrim vardı ve potansiyel bir çözüm, Smashing Magazine'in RUM verilerini toplamak ve analiz için Google Analytics'e geri göndermek için web-vitals kitaplığını kurmasını sağladı. Birkaç gün topladıktan sonra, verilerde daha önce görmediğimiz şekillerde, özellikle de ülke düzeyindeki dağılımda bize çok şey vermesi için Web Önemli Raporunu kullandık:

Ve işte oradaydı. Analitikteki en iyi ülkelerin tümü, biri hariç , çok iyi LCP puanlarına sahipti: Hindistan. Smashing Magazine, küresel bir CDN olan Netlify'ı kullanıyor ve Mumbai'de bir varlığı var, bu yüzden diğer ülkeler kadar performans göstermeli, ancak bazı ülkeler diğerlerinden daha yavaş (bundan sonra bahsedeceğiz).

Ancak, Hindistan için mobil trafik 2500 sınırının hemen dışındaydı ve en çok ziyaret edilen ikinci ülkeydi. Elbette iyi ABD puanları bunu dengelemek için yeterli olmalı mıydı? Pekala, yukarıdaki iki grafik trafiğe göre sıralanan ülkeleri gösteriyor. Ancak CrUX, mobil ve masaüstü trafiğini ayrı ayrı sayar (ve tablet btw, ancak hiç kimse bunu umursamıyor!). Trafiği yalnızca mobil trafiğe göre filtrelersek ne olur? Ve bir adım daha ileri - yalnızca mobil Chrome trafiği (yalnızca Chrome CrUX'u beslediği ve dolayısıyla yalnızca Chrome CWV'ye sayıldığı için)? O zaman çok daha ilginç bir resim elde ederiz:

Hindistan aslında bir şekilde en iyi mobil Chrome ziyaretçisidir - bir sonraki en yüksek ziyaretçiyi (ABD) neredeyse üç katına çıkarıyor! Zayıf puanıyla Filipinler de orada üç numaraya yükseldi ve Nijerya ve Pakistan da zayıf puanlarıyla ilk 10'a giriyor. Şimdi mobilde kötü genel LCP puanları mantıklı gelmeye başladı.

Batı dünyasında İnternet'e erişmenin en popüler yolu olarak mobil, masaüstünü geride bırakmış olsa da, burada hala mobil ve masaüstünün adil bir karışımı var - çoğumuzun oturduğu çalışma saatlerimize bağlı. bir masaüstünün önü. Bir sonraki milyar kullanıcı aynı olmayabilir ve mobil bu ülkelerde çok daha büyük bir rol oynar . Yukarıdaki istatistikler bunun Smashing Magazine gibi siteler için bile geçerli olduğunu, tasarım ve geliştirme yaparken masaüstlerinin başında oturan tasarımcılardan ve geliştiricilerden daha fazla trafik alacağını düşünebileceğinizi gösteriyor!

Ek olarak , CrUX yalnızca Chrome kullanıcılarından ölçüm yaptığından , bu, daha fazla iPhone'a sahip ülkelerde (ABD gibi) mobil kullanıcılarının çok daha küçük bir oranının CrUX'ta ve dolayısıyla Önemli Web Verilerinde temsil edileceği ve bu ülkelerin etkisini ek olarak artıracağı anlamına gelir.

Temel Web Verileri Küreseldir

Önemli Web Verilerinin ülke başına farklı bir eşiği yoktur ve sitenizin farklı ülkeler tarafından ziyaret edilip edilmediği önemli değildir; tüm Chrome kullanıcılarını aynı şekilde kaydeder. Google bunu daha önce onayladı, bu nedenle Smashing Magazine iyi ABD puanları için sıralama artışı almayacak ve Hindistan kullanıcıları için almayacak. Bunun yerine, tüm kullanıcılar eritme potasına girer ve bu sayfa gruplamalarının puanı eşiği karşılamıyorsa, tüm kullanıcılar için sıralama sinyali etkilenir.

Ne yazık ki dünya eşit bir yer değil. Ve web performansı ülkeden ülkeye büyük farklılıklar gösteriyor ve zengin ve fakir ülkeler arasında net bir ayrım olduğunu gösteriyor. Teknolojinin maliyeti yüksektir ve birçok ülke, altyapıyı sürekli olarak en yeni ve en iyi teknolojiye yükseltmek yerine nüfuslarını çevrimiçi hale getirmeye daha fazla odaklanmaktadır.

CrUX'ta diğer tarayıcıların (Firefox veya iPhone'lar gibi) eksikliği her zaman biliniyordu, ancak Firefox veya iPhone performansını ölçmek için onu her zaman daha kör bir nokta olarak gördük. Bu örnek, etkinin çok daha büyük olduğunu ve küresel trafiğe sahip siteler için sonuçları önemli ölçüde Chrome kullanıcıları lehine çarpıtıyor; bu da genellikle daha kötü ülkeler anlamına geliyor ve bu da genellikle daha kötü bağlantı anlamına geliyor.

Önemli Web Verileri Ülkeye Göre Bölünmeli mi?

Bir yandan, altyapı bu kadar değişkense web sitelerini aynı standartta tutmak haksızlık gibi görünüyor. Smashing Magazine neden yalnızca Batı dünyasından tasarımcılar ve geliştiriciler tarafından okunan benzer bir web sitesinden cezalandırılmalı veya daha yüksek bir standartta tutulmalı? Smashing Magazine Hintli kullanıcıların Önemli Web Verilerini mutlu etmelerini engellemeli mi (burada bunun hiçbir zaman tartışma konusu olmadığı konusunda net olmak istiyorum, bu yüzden lütfen bunu Smashing'de bir çabukluk değil, konuyu vurgulayan yazar olarak kabul edin!).

Öte yandan, yavaşlıklarını kabul ederek bazı ülkelerden “vazgeçmek”, onları kalıcı olarak birçoğunun bulunduğu alt kademeye düşürme riskini taşır. Smashing Magazine'in ortalama Hintli okuyucusunun, altyapılarının daha yavaş olması ve birçok yönden kusuru pek de sayılmaz. bunlar daha az değil, daha fazla vurgulamayı ve çabayı hak eden insanlar!

Ve bu sadece zengin bir ülke-fakir ülke tartışması değil. Fransa'daki okuyuculara yönelik, Fransa'dan reklam veya satışlarla finanse edilen ve o ülkede hızlı bir web sitesine sahip olan bir Fransız web sitesi örneğini ele alalım. Bununla birlikte, site birçok Fransız Kanadalı tarafından okunuyorsa, ancak şirket global bir CDN kullanmadığı için sorun yaşıyorsa, o zaman bu şirket, bu Kanadalı kullanıcılar için o kadar hızlı olmadığı için Fransızca Google Arama'dan zarar görmeli mi? Şirket, Önemli Web Verileri tehdidiyle "fidyeye alınmalı" ve bu Kanadalı okuyucuları ve Google'ı mutlu etmek için küresel CDN'ye yatırım yapmalı mı?

Eh, izleyicilerinizin yeterince önemli bir kısmı acı çekiyorsa, Core Web Vital girişiminin ortaya çıkması gereken şey tam olarak budur. Yine de, Core Web Vitals girişiminin SEO sıralama artışıyla bağlantılı olmasının bir yan etkisi olan ilginç bir ahlaki ikilem: para her zaman bir şeyleri değiştirir!

Bir fikir, sınırları aynı tutmak, ancak bunları ülke başına ölçmek olabilir. Fransızca Google Arama sitesi, Fransızca'daki bu kullanıcılara bir sıralama artışı sağlayabilir (çünkü bu kullanıcılar bu site için CWV'yi geçer), Google Arama Kanada'da olmayabilir (çünkü başarısız oldukları için). Bu, hedefler aynı olsa bile, oyun alanını düzleştirir ve sahaları her ülkeye göre ölçer.

Benzer şekilde, Smashing Magazine ABD'de ve geçtikleri diğer ülkelerde iyi bir sıralamaya sahip olabilir, ancak diğer Hint sitelerine göre sıralanabilir ("geliştirilmeye ihtiyaç duyan" segmentte oldukları gerçeğinin, oradaki birçok siteden daha iyi olabileceğini varsayarsak) hepsi aynı performans kısıtlamalarından muzdariptir).

Ne yazık ki, bunun olumsuz bir etkisi olacağını düşünüyorum, bazı ülkeler yine göz ardı edilirken, siteler yalnızca daha kazançlı ülkeler için web performansı yatırımını haklı çıkarır. Ayrıca, bu örneğin zaten gösterdiği gibi, Önemli Web Verileri, dünyadaki her ülke için bir taneye sahip olarak oyuna yaklaşık 200 ek boyut getirmeden zaten yeterince karmaşık!

Peki Nasıl Düzeltilir?

Sonunda, Smashing Magazine'in neden Önemli Web Verilerini geçmekte zorlandığını anladık ama bu konuda ne yapılabilirdi? Barındırma sağlayıcısı (Netlify) zaten Mumbai CDN'sine sahip, bu nedenle Hintli kullanıcılar için hızlı erişim sağlamalıdır, peki bu, bunu geliştirmek için bir Netlify sorunu muydu? Siteyi mümkün olduğu kadar optimize etmiştik, yani bu sadece yaşamak zorunda kalacakları bir şey miydi? Hayır, şimdi daha önceki fikrimize dönüyoruz: web yazı tiplerini biraz daha optimize etmek .

Yazı tiplerini hiç teslim etmeme gibi sert bir seçeneği kullanabiliriz. Veya yazı tiplerini belirli yerlere teslim etmemek (ancak Smashing Magazine'in web sitesinin SSG doğası göz önüne alındığında bu daha karmaşık olacaktır). Alternatif olarak, belirli kriterlere göre yazı tiplerini bekleyip ön uçta yükleyebiliriz, ancak bu, kriterleri değerlendirirken başkaları için yazı tiplerini yavaşlatma riskiyle karşı karşıya kaldı. Keşke bu sert eylemi ne zaman yapmamız gerektiğine dair kullanımı kolay bir tarayıcı sinyali olsaydı. Tam olarak bunun için tasarlanmış SaveData başlığı gibi bir şey!

SaveData Ve prefers-reduced-data

SaveData , kullanıcıların gerçekten istediklerinde tarayıcılarında açabilecekleri bir ayardır… iyi veri kaydetmek. Bu, kısıtlı veri planlarına sahip kişiler, pahalı dolaşım ücretleri ile seyahat edenler veya altyapının istediğimiz kadar hızlı olmadığı ülkelerdeki kişiler için faydalı olabilir.

Kullanıcılar bu ayarı destekleyen tarayıcılarda açabilir ve ardından web siteleri bu bilgileri sitelerini normalden daha fazla optimize etmek için kullanabilir. Belki daha düşük kaliteli resimler döndürmek (veya resimleri tamamen kapatmak!) veya yazı tiplerini kullanmamak. Ve bu ayarla ilgili en iyi şey, kullanıcının isteğine göre hareket etmeniz ve onlar için keyfi bir karar vermemenizdir (birçok Hintli kullanıcı hızlı erişime sahip olabilir ve web sitesinin kısıtlı bir sürümünü istemeyebilir!).

Verileri Kaydet bilgileri iki (yakında üç olacak!) şekilde sunulur:

1. Her HTTP isteğinde bir SaveData başlığı gönderilir. Bu, dinamik arka uçların döndürülen HTML'yi değiştirmesine izin verir.
2. NetworkInformation.saveData JavaScript API'si. Bu, ön uç komut dosyalarının bunu kontrol etmesine ve buna göre hareket etmesine izin verir.
3. Yaklaşan prefers-reduced-data ortamı sorgusu, CSS'nin bu ayara bağlı olarak farklı seçenekler belirlemesine olanak tanır. Bu, Chrome'da bir bayrağın arkasında mevcuttur, ancak standardizasyonu tamamlarken henüz varsayılan olarak açık değildir.

Öyleyse soru şu ki, Smashing Magazine okuyucularının çoğu (ve özellikle Önemli Web Verileri ile mücadele eden ülkelerdekiler) bu seçeneği kullanıyor mu ve bu nedenle onlara daha hızlı bir site sunmak için kullanabileceğimiz bir şey mi? Pekala, yukarıda bahsedilen web-vitals scriptini eklediğimizde, Efektif Bağlantı Tipinin yanı sıra bunu da ölçmeye karar verdik. Komut dosyasının tamamını burada görebilirsiniz. Toplanmasına biraz izin verdikten sonra, sonuçları Chrome tarayıcı sürümüyle birlikte basit bir /Google Analytics panosunda görüntüleyebiliriz:

Dolayısıyla, iyi haber şuydu ki mobil Hintli kullanıcıların büyük bir kısmı (yaklaşık üçte ikisi) bu ayara sahipti. Çoğu 4g olarak gösterilen ECT daha az kullanışlıydı. Çoğu kullanıcı bu 4g ayarı altında sınıflandırıldığından, bu API'nin giderek daha az kullanışlı hale geldiğini daha önce tartışmıştım. Ayrıca ilk yükler için bu değeri etkin bir şekilde kullanmak sorunlarla doludur.

Çoğu kullanıcı güncel bir Chrome'da göründüğünden daha iyi haber, bu nedenle, tam olarak kullanılabilir olduğunda prefers-reduced-data medya sorgusu gibi daha yeni özelliklerden yararlanacaktır.

Ilya from the Smashing team applied the JavaScript API version to their font-loader script so additional fonts are not loaded for these users. The Smashing folks also applied the prefers-reduce-data media query to their CSS so fallback fonts are used rather than custom web fonts for the initial render, but this will not be taking effect for most users until that setting moves out of the experimental stage.

I Love That Graph In Google Search Console

And did it work? Well, we'll let Google Search Console tell that store as it showed us the good news a couple of weeks later:

Additionally, since this was introduced in mid-November, the original level LCP score has steadily ticked downwards:

There's still not nearly enough headroom to make me comfortable, but I'm hopeful that this will be enough for now, and will only improve when the prefers-reduced-data media query comes into play — hopefully soon.

Of course, a surge in traffic from mobile users with bad connectivity could easily be enough to flip the site back into the amber category, which is why you want that headroom, so I'm sure the Smashing team will be keeping a close eye on their Google Search Console graph for a bit longer, but I feel we've made the best efforts basis to improve the experience of users so I am hopeful it will be enough.

Impact Of The User Experience Ranking Factor

The User Experience ranking factor is supposed to be a small differentiator at the moment, and maybe we worried too much about a small issue that is, in many ways outside of our control? If Smashing Magazine is borderline, and the impact is small, then maybe the team should worry about other issues instead of obsessing over this one? But I can understand that and, as I said, Smashing Magazine are knowledgeable in performance and so understand why they wanted to solve — or at the very least understand! — this issue.

So, was there any impact? Interestingly we did see a large uptick in search impression in the last week at the same time as it flipped to green:

It's since reverted back to normal, so this may have been an unrelated blip but interesting nonetheless!

Conclusions

So, an interesting case study with a few important points to take away:

• When RUM (including CrUX or Google Search Console) tells you there's a problem, there probably is! It's all too easy to try to compare your experiences and then blame the metric.
• Implementing your own RUM solution gives you access to much more valuable data than the high-level data CrUX is intended to provide, which can help you drill down into issues, plus also give you potentially more information about the devices your site visitors are using to visit your site.
• Core Web Vitals are global, and that causes some interesting challenges for global sites like Smashing Magazine. This can make it difficult to understand CrUX numbers unless you have a RUM solution and perhaps Google Search Console or CrUX could help surface this information more?
• Chrome usage also varies throughout the world, and on mobile is biased towards poorer countries where more expensive iPhones are less prevalent.
• Core Web Vitals are getting much better at measuring User Experience. But that doesn't mean every user has to get the same user experience — especially if they are telling you (through things like the Save Data option) that they would actually prefer a different experience.

I hope that this case study helps others in a similar situation, who are struggling to understand their Core Web Vitals. And I hope you can use the information here to make the experience better for your website visitors.

Mutlu optimizasyon!

Note: It should be noted that Vitaly, Ilya and others at the Smashing team did all the work here, and a lot more performance improvements were not covered in the above article. I just answered a few queries for them on this specific problem over the last 6 months and then suggested this article might make an interesting case study for other readers to learn from.