Google Önemli Web Verilerini Ölçme ve Optimize Etme: Teknik bir SEO kılavuzu

Sitenizin performansına ilişkin veri toplamak, harika bir kullanıcı deneyimi sunmanın ilk adımıdır. Yıllar boyunca Google, web performansını değerlendirmek ve raporlamak için çeşitli araçlar sağlamıştır.

Bunlar arasında, Google'ın tüm web deneyimleri için kritik olduğunu düşündüğü bir dizi performans sinyali olan Önemli Web Verileri de bulunmaktadır.

Bu makale, kullanıcılara iyi bir sayfa deneyimi sunmak amacıyla web performansınızı iyileştirmeye yönelik mevcut Önemli Web Verileri setini ve önemli ipuçlarını ve araçları kapsar.

Web performansının gelişimine bir bakış

Site performansını iyileştirmenin basit olduğu günler geride kaldı.

Geçmişte, şişirilmiş kaynaklar ve gecikmeli bağlantılar genellikle web sitelerini durduruyordu. Ancak bazı görselleri sıkıştırarak, metin sıkıştırmayı etkinleştirerek veya stil sayfalarınızı ve JavaScript modüllerinizi küçülterek rakiplerinizden daha iyi performans gösterebilirsiniz.

Günümüzde bağlantı hızları daha yüksektir. Çoğu kaynak varsayılan olarak sıkıştırılır ve birçok eklenti görüntü sıkıştırmayı, önbellek dağıtımını vb. yönetir.

Google'ın daha hızlı bir web arayışı devam ediyor. PageSpeed ​​Insights (PSI), web.dev'de hâlâ yayında olup, bireysel sayfa yüklemelerini değerlendirmek için en iyi araç olarak hizmet vermektedir.

Pek çok kişi PSI derecelendirmelerinin gereksiz derecede cezalandırıcı olduğunu düşünse de, Google'ın sayfaları sayfa hızı sinyalleri aracılığıyla nasıl değerlendirebileceğine ve sıralayabileceğine en yakın nokta bu.

Google'ın sayfa hızı testinin en son sürümünü geçmek için Temel Web Verileri Değerlendirmesini karşılamanız gerekir.

Önemli Web Verilerini Anlamak

Önemli Web Verileri, 2021'de kullanıma sunulan daha geniş sayfa deneyimi arama sinyallerine entegre edilmiş bir dizi metriktir. Her metrik, "kullanıcı deneyiminin farklı bir yönünü temsil eder, sahada ölçülebilirdir ve kritik bir kullanıcının gerçek dünya deneyimini yansıtır. merkezli sonuç”, Google'a göre.

Mevcut Önemli Web Verileri metrikleri şunları içerir:

• İlk İçerikli Boya
• İlk Giriş Gecikmesi (Sonraki Boyayla Etkileşim ile değiştirilecektir)
• Sonraki Boyayla Etkileşim
• İlk Bayt Süresi
• En Büyük İçerikli Boya
• Kümülatif Düzen Kayması

Web.dev her metriğin nasıl çalıştığını şu şekilde açıklıyor.

İlk İçerikli Boya (FCP)

“İlk İçerikli Boya (FCP) ölçümü, sayfanın yüklenmeye başlamasından sayfa içeriğinin herhangi bir bölümünün ekranda görüntülenmesine kadar geçen süreyi ölçer. Bu metrik için "içerik" metni, resimleri (arka plan resimleri dahil), <svg> öğelerini veya beyaz olmayan <canvas> öğelerini ifade eder."

Bunun teknik SEO'lar için anlamı nedir?

FCP'nin anlaşılması oldukça kolaydır. Bir web sayfası yüklenirken, belirli öğeler diğerlerinden önce gelir (veya "boyanır"). Bu bağlamda “resim”, ekrandaki görüntü anlamına gelir.

Sayfanın herhangi bir kısmı oluşturulduktan sonra (örneğin ana gezinme çubuğunun diğer öğelerden önce yüklendiğini varsayalım), FCP o noktada günlüğe kaydedilecektir.

Bunu, sayfanın kullanıcılar için görünür şekilde yüklenmeye başlama hızı olarak düşünün. Sayfa yüklemesi tamamlanmayacak ancak başlamış olacak.

İlk Giriş Gecikmesi (FID)

"FID, bir kullanıcının bir sayfayla ilk etkileşime girdiği andan (yani bir bağlantıya tıkladığı, bir düğmeye dokunduğu veya özel, JavaScript destekli bir kontrol kullandığı zaman) tarayıcının gerçekten başlayabileceği ana kadar geçen süreyi ölçer. olay işleyicilerini bu etkileşime yanıt olarak işlemek."

Bunun teknik SEO'lar için anlamı nedir?

FID, Mart 2024'te Sonraki Boyayla Etkileşim (INP) ile değiştirilecek olan bir kullanıcı etkileşimi yanıt verme metriğidir.

Bir kullanıcı sayfadaki bir öğeyle etkileşime girerse (ör. bir bağlantı, bir tabloyu sıralama veya yönlü gezinme uygulama), sitenin bu isteği işlemeye başlaması ne kadar sürer?

Sonraki Boyayla Etkileşim (INP)

“INP, bir kullanıcının bir sayfayı ziyaret ettiği süre boyunca meydana gelen tüm tıklama, dokunma ve klavye etkileşimlerinin gecikmesini gözlemleyerek bir sayfanın kullanıcı etkileşimlerine genel yanıt verme yeteneğini değerlendiren bir ölçümdür. Nihai INP değeri, aykırı değerleri göz ardı ederek gözlemlenen en uzun etkileşimdir."

Bunun teknik SEO'lar için anlamı nedir?

Belirtildiği gibi INP, Mart 2024'te Core Web Vital olarak FID'nin yerini alacak.

INP daha derin bilgileri hesaba katar (görünüşe göre klavyeye kadar uzanır) ve muhtemelen daha ayrıntılı ve karmaşıktır.

İlk Bayta Kadar Geçen Süre (TTFB)

"TTFB, bir kaynağa yönelik istek ile yanıtın ilk baytının gelmeye başlaması arasındaki süreyi ölçen bir ölçümdür."

Bunun teknik SEO'lar için anlamı nedir?

Bir "kaynak" (ör. gömülü resim, JavaScript modülü, CSS stil sayfası vb.) istendiğinde, sitenin bu kaynağı sunmaya başlaması ne kadar sürer?

Diyelim ki bir web sayfasını ziyaret ettiniz ve o sayfada gömülü bir resim var. Yüklemeye başlıyor ancak yükleme henüz tamamlanmadı. Bu görüntünün ilk baytının sunucudan istemciye (web tarayıcısına) iletilmesi ne kadar sürer?

En Büyük İçerikli Boya (LCP)

"En Büyük İçerikli Boya (LCP) ölçümü, sayfanın ilk yüklenmeye başladığı zamana göre görünüm alanında görünen en büyük görüntünün veya metin bloğunun oluşturulma süresini rapor eder."

Bunun teknik SEO'lar için anlamı nedir?

LCP, en önemli ölçümlerden biri olmasına rağmen karşılanması en zor olanıdır.

Görsel medyanın en büyük kısmı (yani metin veya resim) yüklendikten sonra LCP günlüğe kaydedilir.

Bunu şu şekilde okuyabilirsiniz: Bir sayfanın ana içeriğinin büyük bir kısmının yüklenmesi ne kadar sürer?

Belki sayfanın aşağılarına doğru yüklenen küçük parçalar ve çoğu kullanıcının fark etmeyeceği şeyler olabilir.

Ancak LCP günlüğe kaydedildiğinde sayfanızın büyük ve belirgin bir kısmı yüklenmiştir. Bunun gerçekleşmesi çok uzun sürerse LCP kontrolünde başarısız olursunuz.

Kümülatif Düzen Kayması (CLS)

“CLS, bir sayfanın tüm ömrü boyunca meydana gelen her beklenmedik düzen değişikliği için en büyük düzen değişikliği puanları artışının ölçüsüdür.

Görünür bir öğenin, oluşturulan bir çerçeveden diğerine konumunu değiştirmesi durumunda düzen değişikliği meydana gelir. (Bireysel düzen kaydırma puanlarının nasıl hesaplandığına ilişkin ayrıntılar için aşağıya bakın.)

Oturum penceresi olarak bilinen bir düzen değişikliği patlaması, bir veya daha fazla bireysel düzen değişikliğinin, her vardiya arasında 1 saniyeden daha kısa bir süre ve toplam pencere süresi boyunca maksimum 5 saniye olacak şekilde hızlı bir şekilde art arda meydana gelmesidir.

En büyük patlama, o pencere içindeki tüm düzen değişikliklerinin maksimum kümülatif puanına sahip olan oturum penceresidir."

Bunun teknik SEO'lar için anlamı nedir?

Sayfa hızı optimizasyonunun daha basit olduğu günlerde, birçok site sahibi, oluşturmayı engelleyen tüm kaynakları (genellikle CSS sayfaları ve JavaScript modülleri) erteleyerek inanılmaz derecede yüksek sayfa hızı derecelendirmelerine ulaşabileceklerini fark etti.

Bu, sayfa yüklemelerini hızlandırmak açısından harikaydı ancak web'i daha sorunlu ve sinir bozucu bir gezinme deneyimi haline getirdi.

Sayfanızın tüm stilini kontrol eden CSS'niz ertelenirse, sayfanın içeriği CSS kuralları uygulanmadan önce yüklenebilir.

Bu, sayfanızın içeriğinin biçimlendirilmeden yükleneceği ve ardından CSS yüklenirken biraz atlayacağı anlamına gelir.

Bir sayfayı yükleyip bir bağlantıya tıklarsanız, ancak daha sonra bağlantı atlar ve yanlış bağlantıya tıklarsanız bu gerçekten can sıkıcı bir durumdur.

Benim gibi biraz OKB iseniz, bu tür deneyimler kesinlikle çileden çıkarıcıdır (sadece birkaç saniye sürmesine rağmen).

Site sahiplerinin tüm kaynakları erteleyerek sayfa hızı derecelendirmelerini "oynamaya" çalışması nedeniyle, Google'ın, tüm sayfa hızı kazanımlarını kullanıcı deneyimi açığına karşı dengeleyecek bir karşı metriğe ihtiyacı vardı.

Kümülatif Düzen Kaydırma'ya (CLS) girin. Bu, kullanıcılarınızı düşünmeden sayfa hızı artışlarını kapsamlı bir şekilde uygulamaya çalışırsanız gününüzü mahvetmeye çalışan kurnaz bir müşteridir.

CLS temel olarak sayfa yüklemelerinizi aksaklıklar ve gecikmiş CSS kuralları açısından analiz edecektir.

Çok fazla sayıda ölçüm varsa hızla ilgili tüm ölçümleri karşılamış olmanıza rağmen Önemli Web Verileri değerlendirmesinde başarısız olursunuz.

Daha iyi UX ve SEO sonuçları için Önemli Web Verilerinizi değerlendirme

Tek bir web sayfasının performansını analiz etmenin en iyi yollarından biri, onu PageSpeed ​​Insights'a yüklemektir. Görünüm aşağıdakilerin bir kombinasyonuna bölünmüştür:

• URL düzeyindeki veriler.
• Kaynak (etki alanı düzeyinde) verileri.
• Laboratuar verileri.
• Saha verileri.

Bunu anlamak için bir örneğe bakmamız gerekiyor:

https://pagespeed.web.dev/analiz/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Burada TechCrunch ana sayfasına ilişkin sayfa hızı derecelendirmelerini ve ölçümlerini görebiliriz.

Yukarıda Önemli Web Verileri Değerlendirmesinin başarısız olduğunu görebilirsiniz.

Mobil öncelikli bir web'de, varsayılan olarak oluşturulması gereken Mobil sonuçlar sekmesini seçmek önemlidir (bunlar gerçekten önemli olan sonuçlardır).

Yalnızca ana sayfa (veya taramak için yerleştirdiğiniz sayfa) yerine sitenizin alan adı genelinde ortalama alınan genel verileri görmek için Kaynak geçiş düğmesini seçin.

Sayfanın ilerleyen kısımlarında eski, tanıdık sayısal sayfa hızı derecelendirmesini göreceksiniz:

Peki, yeni Önemli Web Verileri değerlendirmesi ile eski sayfa hızı derecelendirmesi arasındaki fark nedir?

Temel olarak, yeni Önemli Web Verileri değerlendirmesi (Geçti/Kaldı) saha (gerçek kullanıcı) verilerine dayanmaktadır.

Eski sayısal derecelendirme, yalnızca tahmin niteliğinde olan simüle edilmiş mobil taramalara ve laboratuvar verilerine dayanmaktadır.

Temel olarak Google, arama sıralamalarını değiştirmek açısından Temel Web Verileri değerlendirmesine geçti.

Açık olmak gerekirse, simüle edilmiş laboratuvar verileri neyin yanlış gittiğine dair güzel bir döküm verebilir, ancak Google bu sayısal derecelendirmeyi sıralama algoritmalarında kullanmaz.

Bunun tersine, Önemli Web Verileri değerlendirmesi çok fazla ayrıntılı bilgi sunmaz. Ancak bu değerlendirme Google'ın sıralama algoritmalarına dahil edilir.

Bu nedenle, asıl amacınız daha zengin laboratuvar teşhislerini kullanmak ve böylece Temel Web Verileri değerlendirmesini (saha verilerinden elde edilen) geçmenizi sağlamaktır.

Sitenizde değişiklik yaptığınızda, sayısal derecelendirme değişiklikleri anında gözlemlese de Önemli Web Verileri değerlendirmesini geçebilmeniz için Google'ın daha fazla alan verisi çekmesini beklemeniz gerekeceğini unutmayın.

Hem Önemli Web Verileri değerlendirmesinin hem de eski sayfa hızı derecelendirmesinin aynı ölçümlerden bazılarını kullandığını fark edeceksiniz.

Örneğin, her ikisi de İlk İçerikli Boya'ya (FCP), En Büyük İçerikli Boya'ya (LCP) ve Kümülatif Düzen Kaymasına (CLS) atıfta bulunur.

Bir bakıma her derecelendirme sistemi tarafından incelenen metrik türleri oldukça benzerdir. Farklı olan, incelenen verinin ayrıntı düzeyi ve kaynağıdır.

Saha bazlı Önemli Web Verileri değerlendirmesini geçmeyi hedeflemelisiniz. Ancak veriler çok zengin olmadığından, ilerlemek için geleneksel laboratuvar verilerinden ve teşhislerden yararlanmak isteyebilirsiniz.

Laboratuvar fırsatlarını ve teşhisleri ele alarak Önemli Web Verileri değerlendirmesini geçebilmenizi umuyoruz. Ancak unutmayın, bu iki test özünde birbiriyle bağlantılı değildir.

CWV'lerinizi PageSpeed ​​Insights aracılığıyla değerlendirme

Artık Temel Önemli Web Verileri metriklerini ve bunların teknik olarak nasıl karşılanabileceğini bildiğinize göre, bir örnek üzerinden geçmenin zamanı geldi.

TechCrunch incelememize geri dönelim:

https://pagespeed.web.dev/analiz/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Burada FID tatmin olmuş durumda ve INP yalnızca dar bir farkla başarısız oluyor.

CLS'nin bazı sorunları var ancak asıl sorunlar LCP ve FCP ile ilgili.

PageSpeed ​​Insights'ın Fırsatlar ve Teşhis açısından neler söylediğini görelim.

Artık saha verilerinden laboratuvar verilerine geçmemiz ve Önemli Web Verilerini etkileyebilecek tüm kalıpları ayırmaya çalışmamız gerekiyor:

Yukarıda, sağ üst köşede yeşil kutulu küçük bir alt gezinme görebilirsiniz.

Farklı fırsatları ve teşhisleri belirli Önemli Web Verileri metriklerine göre daraltmak için bunu kullanabilirsiniz.

Ancak bu durumda veriler daraltılmadan çok net bir hikaye anlatıyor.

Öncelikle kullanılmayan JavaScript'i azaltmamız söylendi. Bu, bazen JavaScript'in yürütülmeden yüklendiği anlamına gelir.

Kullanılmayan CSS'yi azaltmaya yönelik notlar da vardır. Başka bir deyişle, uygulanmayan bazı CSS stilleri yükleniyor (benzer sorun).

Ayrıca neredeyse her zaman JavaScript modülleri ve CSS sayfalarıyla ilgili olan, oluşturmayı engelleyen kaynakları da ortadan kaldırmamız söylendi.

Oluşturmayı engelleyen kaynakların sayfa yüklenmesini engellemelerini önlemek için ertelenmesi gerekir. Ancak daha önce de incelediğimiz gibi bu, CLS derecelendirmesini bozabilir.

Bu nedenle, hem kritik bir CSS hem de kritik bir JavaScript oluşturma yolu oluşturmaya başlamak akıllıca olacaktır. Bunu yapmak, gerisini ertelerken ekranın üst kısmında ihtiyaç duyulan JavaScript ve CSS'yi satır içi hale getirecektir.

Bu yaklaşım, site sahibinin CLS metriği ile dengeleme yaparken sayfa yükleme taleplerini karşılamasını sağlar. Bunu yapmak kolay bir şey değildir ve genellikle kıdemli bir web geliştiricisi gerektirir.

Kullanılmayan CSS ve JavaScript'i de bulduğumuzdan, JavaScript'in daha akıllıca konuşlandırılıp dağıtılamayacağını görmek için genel bir JavaScript kod denetimi de yapabiliriz.

Fırsatlar ve Teşhis'e geri dönelim:

Şimdi teşhise odaklanmak istiyoruz. Google, zayıf 4G bağlantıları nedeniyle bu kontrolleri kasıtlı olarak kısıtlıyor, bu nedenle ana iş parçacığı çalışması gibi öğeler çok uzun görünüyor (17 saniye).

Bu, dünya çapında yaygın olan düşük bant genişliğine ve/veya yavaş cihazlara sahip kullanıcıları memnun etmek için kasıtlı olarak yapılmıştır.

Burada “Ana iş parçacığı çalışmasını en aza indirin” konusuna dikkatinizi çekmek istiyorum. Bu tek giriş genellikle bir içgörü altın madenidir.

Varsayılan olarak, bir web sayfasının oluşturma ve komut dosyası yürütme (JavaScript) görevlerinin çoğu, istemcinin web tarayıcısının ana işleme iş parçacığı (tek bir işlem iş parçacığı) aracılığıyla iletilir. Bunun nasıl önemli sayfa yükleme darboğazlarına neden olduğunu anlayabilirsiniz.

Tüm JavaScript'iniz mükemmel bir şekilde küçültülmüş ve kullanıcının tarayıcısına hızlı bir şekilde gönderilmiş olsa bile, varsayılan olarak tek bir iş parçacığı işleme kuyruğunda beklemesi gerekir; bu, aynı anda yalnızca bir komut dosyasının çalıştırılabileceği anlamına gelir.

Bu nedenle, kullanıcınıza çok sayıda JavaScript'i hızlı bir şekilde göndermek, bir santimetre boşluklu bir tuğla duvara bir yangın hortumunu ateşlemeye eşdeğerdir.

İyi iş çıkardınız, ancak her şey yolunda gitmeyecek!

Google, müşteri tarafı hız duyarlılığını giderek daha fazla sorumluluğumuz haline getiriyor. Beğenin ya da kabul etmeyin, bu böyledir (bu yüzden aşina olsanız iyi olur).

Hayal kırıklığı içinde şöyle diyebilirsiniz: “Neden böyle!? Web tarayıcıları yıllardır birden fazla işlem parçacığına erişime sahip oldu, hatta mobil tarayıcılar bile bu duruma yetişti. İşlerin bu kadar tuhaflaşmasına gerek yok, değil mi?”

Aslında evet. Bazı komut dosyaları, yürütülmeden önce diğer komut dosyalarının çıktısına güvenir.

Büyük olasılıkla, eğer tüm tarayıcılar birdenbire tüm JavaScript'i paralel ve sıra dışı bir şekilde işlemeye başlasaydı, web'in çoğu büyük olasılıkla çökecek ve yanacaktı.

Bu nedenle, sıralı komut dosyası yürütmenin modern web tarayıcıları için varsayılan davranış olmasının iyi bir nedeni vardır. "Varsayılan" kelimesini vurgulamaya devam ediyorum. Nedenmiş?

Çünkü başka seçenekler de var. Bunlardan biri, istemcinin tarayıcısının herhangi bir komut dosyasını kullanıcı adına işleyerek işlemesini engellemektir. Bu, sunucu tarafı oluşturma (SSR) olarak bilinir.

İstemci tarafında JavaScript yürütme düğümlerini çözmek için güçlü bir araçtır ancak aynı zamanda çok pahalıdır.

Sunucunuz, (tüm kullanıcılardan gelen) tüm komut dosyası isteklerini, ortalama kullanıcı tarayıcınızın tek bir komut dosyasını işlemesinden daha hızlı işlemelidir. Bir anlığına bunun içinize sinmesine izin verin.

Bu seçeneğin hayranı değil misiniz? Tamam, JavaScript paralelleştirmesini inceleyelim. Temel fikir, hangi komut dosyalarının sırayla yükleneceğini ve hangilerinin paralel olarak yüklenebileceğini tanımlamak için web çalışanlarından yararlanmaktır.

JavaScript'i paralel olarak yüklenmeye zorlayabilirsiniz ancak bunu varsayılan olarak yapmak son derece tavsiye edilmez. Bunun gibi teknolojilerin entegre edilmesi çoğu durumda SSR ihtiyacını büyük ölçüde azaltacaktır.

Ancak uygulaması çok zahmetli olacak ve (tahmin ettiniz!) kıdemli bir web geliştiricisinin zamanını gerektirecek.

Tam JavaScript kod denetiminizi yapması için kiraladığınız kişi bu konuda da size yardımcı olabilir. JavaScript paralelleştirmesini kritik bir JavaScript oluşturma yolu ile birleştirirseniz, o zaman gerçekten uçuyorsunuz.

Bu örnekte gerçekten ilginç olan şey şu:

Ana iş parçacığı 17 saniye boyunca meşgulken, JavaScript yürütmesinin 12 saniye sürdüğünü hemen görebilirsiniz.

Bu, 17 saniyelik iş parçacığı çalışmasının 12 saniyesinin JavaScript yürütmesi olduğu anlamına mı geliyor? Bu oldukça muhtemeldir.

Tüm JavaScript'lerin varsayılan olarak ana iş parçacığı üzerinden aktarıldığını biliyoruz.

Aktif CMS olan WordPress de varsayılan olarak bu şekilde ayarlanmıştır.

Bu site WordPress çalıştırdığından, bu 12 saniyelik JavaScript yürütme süresinin tamamı muhtemelen 17 saniyelik ana iş parçacığı çalışmasından kaynaklanmaktadır.

Bu harika bir fikir çünkü bize ana işlem dizisinin zamanının çoğunun JavaScript'i yürütmek için harcandığını söylüyor. Referans verilen senaryoların sayısına bakıldığında buna inanmak zor değil.

Mücadeleyi Chrome Geliştirici Araçları'na taşımak

Teknik hale gelme ve eğitim tekerleklerini çıkarma zamanı geldi.

Yeni bir Chrome örneği açın. Bulgularımızı şişirecek karışıklık veya etkinleştirilmiş eklenti olmadığından emin olmak için bir misafir profili açmalısınız.

Unutmayın: Bu işlemleri temiz bir konuk Chrome profilinden gerçekleştirin.

Analiz etmek istediğiniz siteyi yükleyin. Bizim durumumuzda bu TechCrunch.

Gerektiğinde çerezleri kabul edin. Sayfa yüklendikten sonra Chrome DevTools'u açın (bir sayfayı sağ tıklayın ve Denetle'yi seçin).

Performans > Ekran Görüntüleri'ne gidin.

Sayfa yükünü kaydetmek için yeniden yükle düğmesine basın. Daha sonra bir rapor oluşturulacaktır:

İşte bu noktada hepimizin derin bir nefes alması ve paniğe kapılmamaya çalışması gerekiyor.

Yukarıda yeşil kutulu, zaman içindeki istekleri gösteren ince bir bölmeyi görebilirsiniz.

Bu kutunun içinde, bir zaman dilimini seçmek için farenizi sürükleyebilirsiniz; sayfanın geri kalanı ve analiz otomatik olarak uyarlanacaktır.

Manuel olarak seçtiğim bölge yarı şeffaf mavi kutunun kapladığı alandır.

Ana sayfa yükünün gerçekleştiği yer burasıdır ve benim incelemek istediğim şey budur.

Bu durumda kabaca zaman aralığını ve olayları 32 ms ile 2,97 saniye arasında seçtim. Bakışlarımızı ana konunun iç kısmına odaklayalım:

Biliyor musunuz, daha önce çoğu oluşturma görevinin ve JavaScript yürütmesinin ana iş parçacığının darboğazından geçmeye zorlandığını söylüyordum.

Şimdi zaman içinde o ana konunun iç kısmına bakıyoruz. Ve evet, sarı renkte birçok komut dosyası yazma görevini görebilirsiniz.

En üstteki birkaç satırda, zaman ilerledikçe, yürütülen tüm komut dosyalarını ve bunların işlenmesinin ne kadar sürdüğünü onaylayan giderek daha fazla koyu sarı parça bulunur. Her bir öğe için bir okuma almak üzere ayrı çubuk parçalarına tıklayabilirsiniz.

Bu güçlü bir görsel olmasına rağmen Özet bölümünde daha güçlü bir görsel bulacaksınız:

Bu, halka grafiğinin sindirimi kolay görsel ortamı aracılığıyla tüm ayrıntılı verileri basit tematik bölümlere (örneğin, Komut Dosyası Oluşturma , Yükleme , Oluşturma ) ayrılmış şekilde özetler.

Gördüğünüz gibi, komut dosyası oluşturma (komut dosyası yürütme) sayfa yükünün çoğunu kaplar. Dolayısıyla, Google'ın saha ve laboratuvar verileri karışımından elde edilen ve ana başlıktaki JavaScript yürütme darboğazlarına işaret eden önceki varsayımımız doğru gibi görünüyor.

2023'te bu, birkaç basit, kullanıma hazır çözümün yanı sıra en yaygın karşılaşılan sorunlardan biri.

Kritik JavaScript oluşturma yolları oluşturmak karmaşıktır. JavaScript kod denetimlerini gerçekleştirmek uzmanlık gerektirir ve JavaScript paralelleştirmesini veya SSR'yi benimsemek o kadar kolay değildir.

Şimdi gidip Çağrı Ağacına bakalım:

Çağrı Ağacı genellikle Aşağıdan Yukarıya'dan daha kullanışlıdır.

Veriler benzerdir ancak Çağrı Ağacı, görevleri , Komut Dosyasını Değerlendir (komut dosyası yürütme) gibi kullanışlı gruplar halinde tematik olarak gruplayacaktır.

Daha sonra bir gruba tıklayıp genişletebilir ve komut dosyalarını ve yüklenmelerinin ne kadar sürdüğünü görebilirsiniz. Sürenin %11'i pubads_impl.jsm yüklenirken, %6'sı opus.js yüklenirken harcandı.

Bu modüllerin ne olduğunu bilmiyorum (ve siz de bilmiyor olabilirsiniz), ancak optimizasyon yolculuğunun genellikle başladığı yer burasıdır.

Artık bir adım geriye gidebiliriz:

• Bu komut dosyalarını Google'da arayın ve üçüncü taraf kitaplıkların parçası olup olmadıklarını, ne yaptıklarını ve etkilerinin ne olduğunu görün.
• Bunların nasıl daha akıllıca dağıtılabileceği konusunda geliştiriciye danışın.
• Sorunu bireysel kaynaklara kadar daraltın ve alternatifler arayın.
• Performans açığının üstesinden gelin (veya alternatif olarak daha fazla kaynak/bant genişliği, güçlü bir barındırma ortamı için mücadele edin - eğer gerçekten gerekiyorsa).

Önemli Web Verilerini ölçmeye ve optimize etmeye yönelik diğer araçlar

Buraya kadar benimle kalmayı başardıysan tebrikler. Derin Önemli Web Verileri ve sayfa hızı analizi açısından yalnızca şunları kullandık:

• Sayfa Hızı Analizleri
• Chrome Geliştirici Araçları ( Performans sekmesi)

Evet, gerçekten bu kadar zayıf olabilirsin. Ancak size çok yardımcı olabilecek başka araçlar da vardır:

• GTMetrix : Özellikle şelale grafiği açısından kullanışlıdır (şelale için ücretsiz bir hesap gerektirir), burada nasıl okunacağını öğrenebilirsiniz. GTMetrix'in varsayılan olarak kısıtlanmadan çalışacağını ve aşırı olumlu sonuçlar vereceğini unutmayın. LTE bağlantısına ayarladığınızdan emin olun.
• Google Arama Konsolu : Bunu kurar ve sitenizi doğrularsanız, birden çok sayfadaki (toplu) Önemli Web Verileri ölçümleri de dahil olmak üzere, zaman içinde çok sayıda performans ve kullanılabilirlik verisi görebilirsiniz.
• Screaming Frog SEO Spider : Bu, Önemli Web Verileri Başarılı veya Başarısız notlarının (birden fazla sayfa için) toplu olarak alınmasına olanak sağlamak üzere sayfa hızı API'sine bağlanabilir. Ücretsiz sayfa hızı API'sini kullanıyorsanız, onu mantıksız bir şekilde zorlamayın

Sayfa hızı derecelendirmelerinizi iyileştirmek, eskiden bazı resimleri sıkıştırıp yüklemek kadar basitti.

Bu günlerde? Bu, karmaşık bir Temel Web Verileri kampanyası.

Tamamen devreye girmeye hazırlanın. Daha azı başarısızlıkla sonuçlanacaktır.