Google'ın Mayıs 2021 güncellemesi: Önemli Web Verilerine daha yakından bir bakış

GÜNCELLEME: Dijital pazarlama dünyası sürekli değişiyor, ancak endişelenmeyin, biz bunun zirvesindeyiz. Google, yaklaşmakta olan algoritma hakkındaki fikirlerini değiştirdi.

Güncellememizdeki son değişiklikleri buradan okuyun, ancak bu blogu da okumaktan çekinmeyin.

Mayıs 2021'de Google, arama sıralama algoritmasının bir parçasını oluşturmak için Önemli Web Verileri (CWV) metriklerini tanıtacak. İşte o zamana kadar bilmeniz ve yapmanız gerekenler…

Hızlı sitelerin önemli olduğunu hepimiz biliyoruz. Daha iyi bir kullanıcı deneyimi oluşturarak dönüşüm oranlarının artmasını sağlar ve mobil uyumluluk gibi diğer sayfa deneyimi metrikleriyle birlikte Google'daki mobil arama sıralamasını zaten etkiler.

Ancak Google orada durmuyor. Mayıs 2020'de bize Core Web Vitals'den bahsettiler ve 10 Kasım 2020'de, Core Web Vitals'in Mayıs 2021'de genel sıralama algoritmasına bir arama sinyali olarak dahil edileceğini duyurdular.

Ayrıca, "harika sayfa deneyimine sahip arama sonuçlarındaki sayfaları vurgulayan görsel bir göstergeyi test etmeyi" planlıyorlar. Dolayısıyla, yalnızca CWV optimizasyonu yoluyla daha yüksek sıralama şansına sahip olmakla kalmıyoruz, aynı zamanda arama motoru sonuç sayfalarından daha yüksek tıklama oranları elde etme olasılığımız da var.

Bu yeni CWV metrikleriyle işaretlenen olası sorunları denetlemek ve düzeltmek için şimdi harekete geçmek, bu değişiklik 2021'de yürürlüğe girdiğinde sitelerimize daha yüksek Google sıralaması şansı verecektir.

Ama önce bir özet…

Özet: Temel Web Verileri nedir?

Önemli Web Verileri, genel site hızı puanlarına giden 3 yeni sayfa deneyimi metriği kümesidir. Bu metrikler, Google'ın PageSpeed ​​Insights aracı PSI ve Lighthouse Performance'ın başka yerlerde izlenmesinde zaten önemli bir rol oynamaktadır.

Yeni CWV metrikleri aşağıdakilerden oluşur:

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

Bu, katlamanın üstündeki en büyük öğenin kullanıcıya sunulmasından önce geçen süredir. Genel hız puanı mekanizmasının %25'ini oluşturur ve bu nedenle en büyük öğenin teslimini mobil cihazlarda 2,5 saniye veya daha kısa bir süreye indirmek hayati derecede önemlidir.

Sunucu yanıt hızı, oluşturmayı engelleyen komut dosyaları ve stiller, CSS'nin karmaşıklığı, yazı tipleri ve resimler dahil olmak üzere çok sayıda faktör yüksek bir LCP'ye katkıda bulunur

İlk Giriş Gecikmesi (FID)

Bu, etkileşimi ölçer; örneğin dokunma veya tıklama yoluyla kullanıcı girişine sayfanın ne kadar duyarlı olduğu. Tarayıcının ilk girişe yanıt verdiği hedef hız 100ms veya daha az olmalıdır.

Tarayıcı, sayfa yükleme sırasında çok fazla JavaScript ayrıştırıyor veya yürütüyorsa, bu, CPU'yu bağlayacak veya 'Ana Konuyu' engelleyerek cihazların girişe daha az yanıt vermesine neden olacaktır. Yüksek bir FID, genellikle karmaşık JavaScript'in bir göstergesidir. Bu, tek bir komut dosyası veya işlev veya çok sayıda komut dosyası olabilir.

Etkileşim Süresi ve Toplam Engelleme Süresi için mevcut PSI metrikleri FID ile ilgilidir ve toplu olarak toplam hız puanlarının %35'ini oluşturur.

Kümülatif Düzen Kaydırma (CLS)

Bu, ekranın üst kısmındaki içeriğin görsel kararlılığının bir ölçüsüdür. Genel hız puanlarının sadece %5'ini oluştursa da, genel resimde dikkate alınmaya değer. Yüksek bir CLS, sayfa yükleme sırasında, örneğin afişler yüklendiğinde, sayfa içeriğini aşağı kaydırırken, genellikle görsel düzende bir veya daha fazla değişikliği gösterebilir.

Hız puanı dökümü

Aşağıdaki şema, genel hız puanının bir dökümünü ve bu yeni CWV ölçümlerinin GPSI puanlarında ne kadar büyük bir rol oynadığını göstermektedir.

Lighthouse puanı güncellemesinden gelen kaynak veriler

İlk İçerik Boyama (FCP), Etkileşim Süresi (TTI) ve Toplam Engelleme Süresi (TBT) dahil olmak üzere CWV olmayan metrikler genel puanı oluştururken, üç CWV metriğine odaklanmanın diğerleri üzerinde doğrudan etkisi olacaktır. Örneğin hızlı bir FCP olmadan hızlı bir LCP mümkün değildir ve yüksek FID puanları TBT ve TTI'dan doğrudan etkilenir.

En Büyük İçerikli Paint optimizasyonu için ipuçları

LCP metriği, çok sayıda bireysel faktörden oluşur ve yüksek bir FCP'den doğrudan etkilenir. FCP zayıf olarak işaretleniyorsa, buradan başlamak isteyebilirsiniz. Ağ bağlantısı, sunucu yanıt hızı, İlk Bayt TTFB Süresi ve oluşturma engelleme dosyaları gibi her şey FCP değerini etkiler. Bu daha genel sayfa hızı önerilerinin bazılarına daha derin bir bakış için, aşağıdaki LCP'ye özel ipuçlarına ek olarak konuyla ilgili sayfa hızı e-Kitabımıza göz atın.

LCP değeri FCP'den çok daha yüksekse, bu en büyük öğenin gösterimini nasıl daha iyi hale getirebileceğimize bakmamız gerekir.

En büyük elemanı belirleyin

Muhtemelen yapmak isteyeceğiniz ilk şey, en büyük öğenin ne olduğunu belirlemektir. En büyük öğe, farklı kesme noktalarında değişebilen piksel alanına dayalıdır, bu nedenle görsel bir tarama, doğru öğeyi mutlaka tanımlamayabilir.

PSI'da, Teşhis bölümünde bir 'En Büyük İçerikli Paint öğesi' paneli olmalıdır. Alternatif olarak, aşağıda gösterildiği gibi Chrome'un Performans İzleme aracındaki göstergenin üzerine gelerek LCP'yi görüntüleyebilirsiniz.

Yukarıdaki örnekteki Hallam sitesinde, Performans İzleyicisi LCP'yi ana 'Çevrimiçi Gelişme' başlığı olarak gösterir. İdeal olarak, LCP, bu örnekte olduğu gibi FCP'yi hemen takip etmelidir ve ikisi arasında bir boşluk varsa, nedenini anlamaya çalışmamız gerekir.

Yazı tipleri optimize edildi mi?

Katlamanın üstündeki en büyük öğe tipografi ise, yazı tipi dağıtımının mümkün olduğunca akıcı olduğundan emin olmamız gerekir. Bu içerir:

1. CSS yazı tipi ekranını kullanın: takas; yazı tipi dosyası yüklenirken anında yazı tipinin görüntülenmesini sağlamak için. Hem Google Yazı Tipleri hem de Adobe'nin Typekit'i, yazı tipi 'görüntüleme' parametresini ayarlama yeteneğine sahiptir.
2. Üçüncü taraf yazı tiplerine etki alanları arası isteklerde bulunmak yerine, .woff ve .woff2 yazı tipi dosyalarını sunucuda yerel olarak barındırmayı deneyin. Google Fonts oldukça hızlıdır, Typekit fontları daha yavaştır ve bazı üçüncü taraf font dökümhaneleri daha az güvenilir olabilir.
3. Yazı tipi dosyalarını önceden yüklemek yardımcı olabilir. Yerel olarak barındırılan yazı tipleri genellikle web sitelerinin ana stil sayfasına dahil edilir, ancak içindeki yazı tipine ek bir istek yapılmadan önce bu stil sayfasının indirilmesi ve ayrıştırılması gerekir. Önceden yükleme, tarayıcıya CSS'nin ayrıştırılmasını beklemeden yazı tipini daha erken indirmeye başlamasını söyler.
4. Üçüncü taraf yazı tipi dökümhaneleri için ön bağlantı ve dns-önceden getirme kullanın. Bu yönergeler, yazı tiplerine istek yapılmadan önce üçüncü taraf etki alanları arasında bir DNS, TLS ve TCP bağlantılarının kurulmasına yardımcı olacaktır.
5. Yalnızca katlanır ekranın üst kısmı için gerekli olan tipografi için yazı tipi dosyalarını ekleyin. Font Awesome gibi simge kitaplıkları için yazı tipi varlıkları herkesin bildiği gibi ağırdır, ancak bunlara (ve ilgili simge kitaplığı CSS'sine) yönelik istekler genellikle ertelenebilir ve <head> öğesinden sonra yüklenebilir.
6. Ana sitenin stil sayfasındaki yazı tipi dosyalarına etki alanları arası isteklerde bulunmayın, çünkü bu bağlantıya ve bir üçüncü taraf etki alanının ek olarak aranmasına dayanır.
7. Web uyumlu yazı tiplerini düşünün. Bunlar, estetik açısından çok sınırlı olabilse de, yazı tipi dosyalarına herhangi bir istek gerektirmez.

Görüntüler optimize edildi mi?

Çoğu zaman, ekranın üst kısmındaki en büyük öğe, görüntülerin optimize edilmesini sağlamak için çok önemli bir görüntü olacaktır. Aşağıdakiler genel olarak iyi bir uygulamadır, ancak özellikle LCP öğesi için önemlidir.

1. Doğru görüntü dosyası türünü kullanın. Fotoğraflar için JPG görüntüleri, vektör grafikleri ve simgeler için SVG'ler veya daha karmaşık, fotoğrafik olmayan görüntüler için ve şeffaflık gerekiyorsa PNG'ler kullanılmalıdır.
2. JPG resimlerinin kaydedildiğinden veya %50-60 civarında kalitede çıktı alındığından emin olun. Bu seviyede, kalitede fark edilebilir bir kayıp olmamalıdır. Ayrıca, görsellerden meta verilerin çıkarıldığından emin olun.
3. Tinypng.com gibi sıkıştırma eklentileri veya hizmetleri, görüntüleri otomatik olarak ve toplu olarak optimize edebilir ve gereksiz meta verileri çıkarabilir.
4. Resimler, görüntülendikleri alan için uygun boyutta olmalıdır. Yüksek kaliteli masaüstü görüntüsünü mobil cihazlarda çıkarmayın.
5. Görüntüler, duyarlı görüntüler için 'srcset' özniteliğine sahip standart <img> etiketi kullanılarak çıkarılmalıdır.
6. Ekranın alt kısmındaki veya ekran dışındaki resimler loading=”lazy” niteliğini kullanmalıdır.
7. Daha da iyi sıkıştırma oranları için yeni nesil .web görüntü dosyası biçimini kullanın. Bu kolayca %30 ve çoğu durumda çok daha fazla tasarruf sağlayabilir.
8. İndirmeyi diğer, potansiyel olarak daha az kritik içerikten daha hızlı başlatmak için ekranın üst kısmındaki en büyük görüntüyü önceden yüklemeyi düşünün.

Oluşturmayı engelleyen dosyaları azaltın

<head></head> öğesine yüklenen herhangi bir JavaScript veya CSS dosyası, sayfanın oluşturulmaya başlayabilmesi için bu dosyaların indirilmesi gerektiğinden, oluşturmayı engelliyor olarak kabul edilir. Bunun hem FCP hem de LCP metriği üzerinde büyük bir etkisi olabilir. Başlıktaki oluşturma engelleme dosyaları, yalnızca sayfadaki ekranın üst kısmındaki ilk görüntü için kritik olduklarında kullanılmalıdır.

<head> içindeki kullanılmayan dosyaları kaldırmak, kritik olmayan dosyaları altbilgiye yüklemek veya birden çok dosyayı daha az dosyada birleştirmek, oluşturmayı engelleyen varlıkların miktarını azaltacaktır.

LCP'yi görüntülemek için JavaScript kullanmayın

CWV'den önce, bu önemli bir şey değildi. JavaScript'in, genellikle hız puanları üzerinde çok az veya hiç etkisi olmayan, soluk metin veya kahraman karuselleri gibi ekranın üst kısmındaki öğeleri canlandırmak veya görüntülemek için kullanılması yaygındır.

En büyük öğenin görüntülenmesi JavaScript'e dayanıyorsa, öğe görünmeden önce JavaScript'in indirilmesi, ayrıştırılması ve yürütülmesi gerektiğinden bu genellikle uzun bir gecikmeye neden olabilir. JavaScript dosyaları genellikle (ve oldukça haklı olarak) <head> öğesinden sonra yüklenir, bu nedenle 'oluşturmayı engellemezler', ancak bu, LCP'nin oluşturulmasını yine de etkili bir şekilde engelleyebilecekleri anlamına gelir.

Aşağıdaki örneğe bir göz atın (logo bulanık ve başlık değişti) bu, PSI'da aksi halde yüksek puan alan bir siteden. LCP (ana başlık metni), metin solmadan önce JavaScript'in (sarı bantlarla temsil edilen) indirme, ayrıştırma ve yürütme gereksiniminden kaynaklanan FCP'den birkaç saniye uzaktadır.

Metnin kendi içinde solması da bir sorun olabilir ve en büyük öğenin gecikmeli olarak görüntülenmesine neden olabilir.

Bunun gibi JavaScript teknikleri, genel hız puanlarını anında %25 oranında azaltabilir ve en büyük öğenin yüklenmesini hiçbir şekilde engellemek veya engellemek için kullanılmamalıdır.

Komut Dosyalarını Pencere Yükünde Yürütün

JavaScript, ekranın üst kısmındaki kritik içeriği görüntülemek için nadiren gereklidir (ve gerekli olmamalıdır), ancak gördüğümüz yaygın bir sorun, işlevlerin DOM hazır olur olmaz tetiklenebilmesidir. Popüler jQuery çerçevesinde bu, 'hazır' olay aracılığıyla yapılır. Google Etiket Yöneticisi ayrıca hazır olduğunda işlevleri veya 'etiketleri' tetikleyebilir.

Ana sayfa içeriği yüklendikten sonra, ekranın üst kısmındaki içeriğin ve LCP öğesinin oluşturulmasıyla herhangi bir olası etkileşimi önlemek için, pencere yükleme olayında içeriğin kritik olarak görüntülenmesi için gerekli olmayan tüm JavaScript'leri tetiklemeyi düşünün.

LCP'yi değiştir

Bir görsel ne kadar iyi optimize edilmiş ve akıcı hale getirilmiş olursa olsun, bir tipografik öğeye kıyasla indirmek ve görüntülemek neredeyse her zaman daha uzun sürer. Görüntüler için hızlı LCP puanları elde etmek tamamen mümkün olsa da, bazen en büyük görüntü öğesini en büyük metin öğesinden daha küçük olacak şekilde azaltmak için yapılan bir ince ayar, bunun yerine metnin LCP için kullanılabileceği anlamına gelir.

LCP'nin bir metin öğesine geçirildiği aşağıdaki örnekte gösterildiği gibi, tasarım izin veriyorsa bu, puanlarda büyük bir fark yaratabilir.

İlk Giriş Gecikmesi optimizasyonu için ipuçları

Daha önce bahsettiğimiz gibi, FID, sayfanın kullanıcı girdisine ne kadar duyarlı olduğunu ölçer. Genel hız puanlarının %35'ini oluşturabilen Etkileşimli TTI Süresi ve Toplam Engelleme Süresi TBT'yi birleştirir.

Bu ölçümler öncelikle sayfa yüklenirken ayrıştırılan ve yürütülen komut dosyalarından etkilenir; CPU'nun ana iş parçacığını bloke eder ve özellikle alt uç akıllı telefon aygıtları için potansiyel olarak aygıtın yanıt verme hızını etkiler.

PSI'da gösterilen 'Lab Verileri'nin doğrudan FID'yi ölçmediğine dikkat etmek önemlidir. Bunun nedeni, simülasyonu zor olan kullanıcı tarafından yapılan dokunma veya tıklamalardan kaynaklanan ölçümün etkileşimli doğasıdır. Bunun yerine, 'Alan Verileri' tarafından toplanır; Chrome Kullanıcı Deneyimi Raporu CrUX'a dayalı olarak 28 günlük bir süre boyunca gerçek kullanıcılardan toplanan ölçümler.

Bu nedenle, bir şeyi değiştirip daha fazla veri toplanması için 28 gün bekleyemediğimiz için doğrudan FID için optimizasyon yapmak biraz daha zordur. Bu nedenle, bu ölçümler için düşük süreler düşük bir FID ile ilişkilendirileceğinden, bunun yerine bunun için Lab Verilerindeki TTI ve TBT ölçümlerini kullanmalıyız.

Peki bu metrikler için optimizasyonu nasıl yapacağız?

JavaScript'inizi denetleyin

JavaScript tüm şekil ve boyutlarda olabilir ve tek bir video yerleştirme, sohbet aracı, ReCaptcha komut dosyası veya HubSpot entegrasyonunun yüksek FID, TTI ve TBT ölçümlerinin arkasındaki tek neden olması nadir değildir.

Page Speed ​​Insights'taki tanılama panelleri, başlamak için iyi bir yerdir. 'Ana iş parçacığı çalışmasını en aza indir' bölümü size JavaScript'in ne kadar yürütme süresi aldığını söyleyecektir, 'JavaScript yürütme süresini azalt' bölümü hangi dosyaların yüksek ayrıştırma ve yürütme sürelerine sahip olduğunu ve 'Üçüncü tarafların etkisini azaltın' code', yüksek etkili üçüncü taraf komut dosyalarını vurgulayacak ve gruplayacaktır.

Aşağıdaki ekran görüntüsü, 15 saniyelik Etkileşim Süresi metriği ile birkaç ağır komut dosyasına sahip olan bir siteyi göstermektedir. Birçok komut dosyası, HubSpot ve Vimeo dahil olmak üzere üçüncü taraflara aittir.

Bu komut dosyalarının sayfa yüklemesini nasıl etkilediğine ilişkin daha derin bir analiz ve görselleştirme için, Chrome'un Performans İzleme aracı, hangi komut dosyalarının ve işlevlerin başlatıldığını, bu komut dosyalarının göreli etkisini ve bunları sayfanın hangi noktasında yüklediğini derinlemesine incelemenin harika bir yolu olabilir. uzun komut dosyaları yürütülüyor.

Aşağıdaki örnek aynı sitedendir ve sarı, pembe ve turuncu çubuklarla temsil edilen JavaScript'i gösterir ve daha uzun çubuklar daha uzun yürütme görevlerini gösterir. Bu daha uzun görevlere tıkladığımızda, vurgulanan komut dosyalarının yukarıda PSI tarafından vurgulanan büyük komut dosyalarıyla ilişkili olduğunu görebiliriz.

Hangi komut dosyalarının performansı etkilediğine dair daha iyi bir resme sahip olduğumuzda, aşağıda özetlendiği gibi etkilerini en aza indirmek için kullanabileceğimiz birkaç teknik vardır.

Komut Dosyalarını eşzamansız olarak yükleyin

JavaScript varsayılan olarak sırayla yürütülür. Başkalarının yüklenmesine bağlı olmayan herhangi bir komut dosyası varsa, bu komut dosyaları, diğer komut dosyalarının ayrıştırılmasını ve yürütülmesini engellememeleri için 'async' özniteliği ile yüklenmelidir.

JavaScript'i koşullu olarak yükle

Birçok sitede gördüğümüz yaygın bir sorun, ağır komut dosyalarının genel olarak veya gerekmediğinde sayfalara yüklenmesidir. Örneğin, form gönderimlerinde spam'i durdurmaya yardımcı olması için ReCaptcha'yı kullanmanız gerekiyorsa, yalnızca form içeren sayfalara komut dosyaları yüklediğinizden emin olun.

JavaScript paketlerini kolaylaştırın

jQuery UI veya Bootstrap gibi JavaScript kitaplıkları genellikle ek JavaScript özellikleri ve işlevleri sağlamak için kullanılır. Bir paket kullanıyorsanız, gereksiz JavaScript'in indirilmesini ve ayrıştırılmasını önlemek için pakete yalnızca ilgili özellikleri eklediğinizden emin olun.

Gerektiğinde tembel yükleme komut dosyaları

JavaScript yalnızca gerekli olduğu sayfalara yüklense bile, komut dosyasının sayfa yükleme veya pencere yükleme olayı sırasında ayrıştırılması ve yürütülmesi gerekmez. JavaScript'i yalnızca gerçekten ihtiyaç duyulduğunda yüklemek, TTI, TBT ve FID ölçümlerinde büyük bir fark yaratabilir. İşte bazı örnekler:

1. YouTube ve Vimeo gibi video yerleştirmeleri genellikle yüksek etkiye sahiptir. Bunun yerine yalnızca bir video küçük resmine tıklarken bu komut dosyalarını yüklemeyi düşünün.
2. HubSpot gibi üçüncü taraf form entegrasyonları yoğun olabilir. Form bir modda veya bir sayfanın altında görünüyorsa, gerekli komut dosyasını sayfa yükleme yerine kaydırma veya modsal etkinleştirme sırasında yüklemeyi veya enjekte etmeyi düşünün.
3. Canlı sohbet widget'ları, genel hız puanlarını %35'e kadar etkileyebilir. Canlı sohbet pencere aracını, küresel 'canlı sohbet' CTA'sını destekleyen özel bir iletişim sayfasına taşımayı veya canlı sohbet komut dosyasını yalnızca 'bizimle sohbet' düğmesine tıklandığında enjekte etmeyi düşünün.
4. Gömülü iFrame tabanlı içeriğe 'loading=”lazy” özniteliğini eklemek yardımcı olabilir, ancak bu yeni bir tarayıcı özelliğidir ve kullanılan iFrame yerleştirmesine bağlı olarak test edilmesi gerekir.

İş zekası araçlarını değerlendirin

Kullanıcı davranışını Hotjar gibi araçlarla veya VWO gibi A/B Test yazılımlarıyla analiz etmek iş zekası için gerçekten önemlidir ve çoğu durumda faydaları site hızı üzerindeki etkisinden daha ağır basacaktır.

Bununla birlikte, verilerin ne sıklıkla analiz edildiğine bağlı olarak bu araçları 7/24 çalıştırmanın önemini değerlendirmeye değer. Örneğin, hiçbir etkin test çalışmıyorsa ve yeterli veri toplanıp işlendikten sonra Hotjar gibi davranış analizi araçları devre dışı bırakılabilirse A/B testi kapatılmalıdır.

Kümülatif Düzen Kaydırma optimizasyonu için ipuçları

Kümülatif Mizanpaj Kayması (CLS), toplam hız puanlarının yalnızca %5'ini oluşturabilir, ancak yine de genel resmin önemli bir parçasıdır, özellikle sayfa yüklendiğinde yüksek miktarda değişen öğe kullanıcı için sarsıcı bir deneyim olabilir.

CLS öğesini belirle

Bazen hangi öğenin veya öğelerin içerikte bir kaymaya neden olduğu açık görünebilir, ancak bunu her zaman aşağıda gösterildiği gibi PSI'daki Düzen Kaydırma panelinden doğrulamaya değer.

CLS metriği 0,1'in altında olmalıdır, ancak yukarıdaki örnekte bu, %400'den fazla aşılmıştır ve puanlarda %5'lik bir düşüşe neden olacaktır. Bu küresel bir sorunsa, her sayfada %5'tir.

Değişen unsurlar, etki sırasına göre tanımlanmalı ve ele alınmalıdır ve ekranın üst ve alt kısımlarını içerebilir. Aşağıda, düzen değiştirmenin en yaygın nedenlerinden ve çözümlerinden bazılarını vurguladık.

Animasyona dikkat edin

İçeriğin kullanıcıya sunulma şeklini değiştirmek için belirli animasyon tekniklerinin kullanılması oldukça yaygındır; örneğin, kullanıcı bir sayfayı aşağı kaydırırken resimlerde, metinlerde veya içerik panellerinde solma veya kayma yoluyla. Bunlar estetik açıdan hoş görünse de (kime sorduğunuza bağlı olarak), bu tekniklerin sayfa yükleme sırasında herhangi bir içeriği değiştirmemesi önemlidir.

İçeriği kullanıcıya gizlemeniz ve ardından soldurmanız gerekiyorsa, içerik yüklenirken kapsayıcı boyutunun veya toplam sayfa yüksekliğinin değişmediğinden emin olun. İçerik, görüntülemek yerine CSS görünürlük kuralları kullanılarak (gerekirse) gizlenebilir: yok; bu, ihtiyaç duyduğu temel alan miktarını koruyacaktır.

Görüntü boyutlarını belirtin

<img> etiketinin genişlik ve yükseklik özniteliği ayarlanmamışsa veya görüntünün boyutlarını veya oranını ayarlamak için CSS kullanılmıyorsa, tarayıcıların ihtiyaç duyduğu piksel alanını belirlemeden önce görüntüyü indirmesi gerekir. Bu, görüntü yüklendikçe görüntünün altında oluşturulan herhangi bir içeriğin kaymasına neden olabilir.

Görüntü indirilmeden önce görüntünün genişliğini ve yüksekliğini belirtmek veya görüntünün (veya ana kapsayıcının) boyutlarını veya oranını CSS içinde ayarlamak, tarayıcıların görüntünün görüntülenmesi gereken alanı bilmesini ve olası yerleşimden kaçınmasını sağlayacaktır. vardiya.

Afişler

Bir başlıkta önemli bilgileri görüntülemek için kullanılan reklamlar, çerez yasası çubukları veya diğer bilgiler, muhtemelen yüksek CLS'nin en yaygın nedenlerinden biridir.

Banner içeriğinin harici bir veri kaynağından veya aynı siteden JavaScript aracılığıyla yüklenmesi yaygındır; bu, içerik yüklenene kadar başlık kabının boyutunun hesaplanmasının mümkün olmayabileceği anlamına gelir. Bu olduğunda, banner içeriği yüklenip kullanıcıya gösterildiğinde, başlığın altındaki içerik aşağı kayar.

Bununla ilgili birkaç karar var:

1. Tarayıcının bir yer tutucuyu etkili bir şekilde oluşturabilmesi için CSS'de başlık veya başlık kabı için minimum bir yükseklik ayarlayın. İçeriğin miktarı dinamik ve bilinmiyorsa bu sorunlu olabilir.
2. Afişin ekranın üst veya alt kısmındaki konumunu kesinlikle veya sabitleyin. Kapatılabilen veya kapatılabilen afişler için bu, sabit öğeler diğer öğelerin konumlarını etkilemeyeceğinden iyi bir değerlendirmedir.
3. Mümkünse banner içeriğinin sunucu tarafında görüntülenmesine bakın, bu da içerik ve banner boyutlarının kullanıcıya ulaşmadan önceden yüklenebileceği anlamına gelir.

Özet

Umarım, yukarıda vurgulanan tekniklerden bazılarını, Google'ın yeni Önemli Web Verileri ile ilgili performans sorunlarını teşhis etmede ve gidermede faydalı bulursunuz. Hallam'da geçtiğimiz birkaç ay boyunca, hem hız denetimlerimiz hem de geliştirme ekibimiz tarafından yapılan doğrudan iyileştirmeler açısından bir dizi müşterinin web sitelerinin performansını iyileştirmesine yardımcı olduk.

Bu makaleyi yararlı bulduysanız, bir web sitesi oluşturan veya yöneten herkesin yararlanabileceği sayfa hızıyla ilgili daha genel önerilerin bazılarına daha derin bir dalış yapan web sitesi performansı e-Kitabımıza da göz atmak isteyebilirsiniz.