WordPress Temel Web Verileri Performans Stratejileri SSS

Google, Önemli Web Verilerini yıllık olarak güncellemeyi planladığını söylüyor. Bu sıklık, kullanıcı deneyimindeki en son ve en büyük gelişmelere ayak uydurmak ile web sitesi sahiplerine ve işletmelere plan yapmak için yeterli alan sağlamak arasında iyi bir denge kurar.

Saha verileri veya Gerçek Kullanıcı Metrik (RUM) verileri, site sahipleri için daha anlayışlı ve değerli verilerdir. Gerçek kullanıcıların sitenizi nasıl deneyimlediğini söyler.

Bu, kullanıcılarınızın çoğunluğunun nerede olduğu, kullanıcılarınızın sitenize günün hangi saatinde eriştiği, hafta sonları ziyaret edip etmedikleri ve çok daha fazlasından etkilenebilir. Site sahipleri, test ortamlarında dikkate almadıkları faktörlere sıklıkla şaşırırlar. Sitenizi nasıl oluşturacağınız, sitenin gerçek kullanıcılar tarafından gerçekte nasıl deneyimlendiğine göre belirlenmelidir.

TTFB, tüm metriklerin ilki ve en temelidir. TTFB'niz yavaşsa, Önemli Web Verileri dahil olmak üzere diğer ölçümleri iyileştirerek telafi etmeniz gerekir.

TTFB'nin iyileştirilmesi, platform veya ana bilgisayar düzeyinde yapılır. İçeriği kullanıcılarınıza mümkün olduğunca yakın sunmak en iyisidir ve bunu yalnızca küresel veri merkezi ağlarına sahip ana bilgisayarlar yapabilir.

Ek olarak, performansı göz önünde bulunduran güvenilir bir WordPress uygulamasına sahip olmak isteyeceksiniz. Örneğin, sayfa ve nesneyi önbelleğe almaktan yararlanmak, karmaşık isteklerin hızlı hissetmesine neden olabilir.

Önemli Web Verileri metrikleri sitenizin sahip olduğu gerçek kullanıcılar için ölçüldüğünden, dünya çapında iyi bir performansa sahip olmak önemlidir. Dünya çapında ziyaretçileriniz varsa, dünya çapında ölçülürsünüz; bazı merkezi performans testi konumlarında değil. Bu verilere Google Page Speed ​​Insights'taki Alan Verileri'nde ve Google Arama Konsolu'ndaki Önemli Web Verileri'nde bakın.

Google'ın TTFB için en son önerileri şunlardır:

• İyi: < 500 ms
• İyileştirme gerekiyor: 500 – 1500 ms
• Kötü: > 1500ms

Gerçek Kullanıcı Metrikleri (RUM), Önemli Web Verileri performansı için önemli olduğundan, web siteniz trafik artışlarını yönetmiyorsa, puanınızda büyük olasılıkla bir düşüş göreceksiniz. Bu nedenle, tüm site ziyaretçilerine sürekli olarak iyi bir deneyim sağlamak önemlidir.

En iyi trafik gününüzde bile iyi performans gösterecek şekilde otomatik olarak ölçeklenen bir web sitesi platformu arayın.

İlk olarak, sitenizde neyin LCP olarak kabul edildiğini belirleyin. Bir kahraman resmi, kaydırıcı, büyük metin parçası, video veya animasyon olabilir. Şaşırtıcı bir şekilde, suçlu beklenmedik bir şey olabilir – bir çerez bildirimi açılır penceresi veya reklamlar. LCP dağıtımını iyileştirmek için doğru öğe üzerinde çalıştığınızdan emin olun.

LCP'nizin bir kahraman resmi olması durumunda, işte ipuçları:

• Üçüncü taraflarca tembel yüklenmediğinden veya yerleşik tarayıcı gecikmeli yükleme olmadığından emin olun (bunun yerine istekli yüklemeyi kullanın).

• Ön yüklemeyi uygulayın—böylece tarayıcı tarafından daha önce keşfedilir.

• Meta görüntü alanı bildiriminin onu başına getirdiğinden emin olun. Piksel yoğunluğu, maksimum genişlik ve maksimum cihaz genişliği nedeniyle yanlış bir CSS kahraman görüntüsü sayfada ilk olarak tanımlanmayabilir.

• 200 KB'ın altında tutun—uygun boyutları ve yeni nesil biçimleri kullanın.

• Kritik yolun diğer öğelerini araştırın. Kahraman imajıyla rekabet ederek bant genişliğini paylaşırlar. Çoğu zaman, ekranın üst kısmındaki içerik için bant genişliğini boşaltmak için neler yapabileceğinizi görmek mantıklıdır. Örneğin, büyük bir CSS dosyası ikiye bölünebilir veya yazı tipleri kritik yoldan çıkarılabilir.

LCP, en büyük öğenin ekranda ne zaman oluşturulduğuna bağlıdır, bu nedenle neredeyse tamamen boyuta bağlıdır. Son zamanlarda, gövde öğesinin arka planı olarak ayarlanan tam genişlikteki görüntüleri yok sayarak bir önem tahminini dikkate almaya başladı.

Performans bir zihniyettir: Bunu, küçük kararları birbirine karşı dengelediğiniz tek seferlik bir proje olarak değil, uzun vadeli bir hedef olarak görmelisiniz. Zayıf sayfa performansına başka nelerin katkıda bulunabileceğinin tam resmini anlamalısınız. Katkıda bulunan tüm faktörleri tanımlayamazsanız, yaratıcı ihtiyaçlar için performansı nerede feda edeceğinize dair veriye dayalı kararlar alamazsınız.

Yazı tipleri için gümüş kurşun yoktur – Google'ın yazı tipleri için en iyi uygulamalarıyla başlayın. Ayrıca diğer birçok yükleme stratejisine de başvurabilirsiniz.

İşte başlamak için birkaç teknik:

• Basit bir soruyla başlayın: Kullanıyor muyuz? Hiçbir yerde kullanılmayan yazı tiplerini yüklemediğinizden emin olun. Bu aynı zamanda resimler, videolar, stil sayfaları, komut dosyaları için de geçerlidir; kullanmadığınız her şeyden kurtulun.

• Hangi yazı tiplerinin kritik yükleme yolunun parçası olduğunu öğrenin—bunları mümkün olduğunca erken yükleyin (ön yüklemeyi kullanın) ve diğerlerinin yüklenmesini geciktirin.

• Tüm yazı tiplerini yerel olarak barındırmayı hedefleyin (örneğin, kendi alanınızdan).

• Yazı tipi gösterimini kullandığınızdan emin olun: takas; Uzak yazı tipleri yüklenirken metnin görünür kalması için özel/üçüncü taraf yazı tipleri yüklenmeden önce yerel sistem yazı tiplerini yükleme özelliği. Özel yazı tipiniz olarak karakter aralığı, boşluk ve diğer öğelere yakın bir sistem yazı tipi elde etmek için yazı tipi stili eşleştirici gibi bir araç kullanmanızı öneririz. Ayrıca fontfaceobserver.js'yi, fontlarınızı yüklerken kaldıraç vaatlerine yardımcı olması için kullanabilirsiniz.

• Simge yazı tipleri için duruma bağlıdır: yazı tipi görüntüleme değeri olarak bloğu kullanın, yalnızca kullanılan simgeleri yüklemek için bir alt küme yazı tipi yapın, hatta SVG olarak “çevrimiçi” yapın.

Kümülatif Düzen Kayması, sayfanın ömrü boyunca meydana gelen tüm beklenmedik düzen kaymalarının en büyük patlamasının toplamını ölçer.

Resimler, reklamlar, yazı tipleri, yerleştirmeler ve daha fazlası, sayfanızın düzenini yüklenirken ayarlayabilir. Geliştiricilerin, editoryal içeriğin parçası olmayan alanlara genişlik ve yükseklik eklemeyi kaçırmadıklarından emin olmaları gerekir.

CLS metriği güncellendi. Şimdi, en büyük kaymayı düzelttiğinizde, metriğin puanlaması bir sonraki en büyük patlamanın değerine gider. Bu, bir öncekine oldukça yakın olabilir, bu nedenle, tüm büyük atlamaları düzeltene kadar puanlarda önemli bir gelişme görmeyeceksiniz.

İyi bir Lighthouse puanı, genellikle hedeflerinize giden yolun büyük bir bölümünde olduğunuz anlamına gelir – belirli koşullar verilen bir laboratuvar açısından, belirli bir puana kadar ölçüm yapar.

Ancak, belirttiğimiz gibi, bir laboratuvar testi sırasında ölçülemeyen bazı yönler vardır. Bunların örnekleri, kullanıcının etkileşimi sırasındaki FID ve CLS'dir. Ek olarak, ağ gecikmesi, cihaz donanımı ve yüklemedeki karmaşıklık gibi diğer faktörler, gerçek kullanıcılarınızın ideal sitenizden daha yavaş olabileceği anlamına gelir.

Hata ayıklama verilerini analizlere göndermenize yardımcı olacak API'ler vardır ve bunlar daha sonra bir Web Önemli Raporunda görüntülenebilir. Bu, GSC ve Lighthouse arasındaki eşitsizliğe hangi sorunların neden olduğunu bulmanıza yardımcı olacaktır.

Google, GSC içinde ve PageSpeed ​​Insights (PSI) üzerinde Chrome Kullanıcı Deneyimi Raporu (CrUX) verilerini kullanır. Tüm kullanıcılarınızın yüzde 75'i için "iyi" puanlar almayı hedeflemelisiniz.

Varyasyonlar göz önüne alındığında, kullanıcılarınızın laboratuvar koşullarından daha yavaş (veya daha hızlı) deneyimleyebileceği koşullar vardır ve bunları dağıttıktan sonra çabalarınızın etkili olmasını sağlamak için gerçek kullanıcı ölçümleri (RUM) verilerini kullanmanız gerekir.

jQuery, web'e gelişmiş özellikler getirmede çok önemliydi. Ancak, LCP, TTI ve FID üzerinde (ne zaman yüklendiğine ve sayfada başka neler olduğuna bağlı olarak) genellikle büyük performans etkileri olan büyük bir kitaplıktır. Web ve WordPress ekosisteminde kullanımını azaltmak için devam eden çabalar vardır. yeni temaların onu bir bağımlılık olarak kullanmamasını sağlamak ve Jetpack gibi sık kullanılan WordPress eklentilerinden kaldırmak gibi.

Sürüm oluşturma bu bağlamda pek önemli değildir, ancak performans açısından asıl mesele jQuery'yi hangi belirli sürüm olduğu değil, kritik yola yüklemektir.

Kontrol ettiğiniz şeyi düzeltin. Bu, üçüncü taraf eklentilerin kazanılan değere karşı alınan cezaya göre değerlendirilmesini içerebilir.

Chrome DevTools'da performans profili oluşturma arkadaşınızdır. Yüklemelerini düşük CPU kullanımı dönemlerine erteleyerek, komut dosyası yoğun üçüncü tarafların etkisini en aza indirin.

CPU, 15 farklı görev yaparak bunaltılmazsa, eklentinin web sitesi etkileşimi üzerindeki etkisi en aza indirilebilir.

Analytics komut dosyaları genellikle web sitesi sayfa hızını önemli ölçüde etkilemez, ancak yine de bunları optimize etmekten yararlanabilirsiniz. Temel olarak, daha önce değil, gerektiğinde ekleyin.

Bu kalıbı takip edin:
1. GTM komut dosyasını HTML'nizin başına değil sonuna yerleştirin.

2. HTML işlendikten sonra indirin ve ayrıştırın (komut dosyasını erteleyin).

3. Belge Nesne Modeli (DOM) yüklendikten sonra 1-3 saniye içinde yürütün.

Bu şekilde, GTM veya başka herhangi bir analiz komut dosyası engelleyici olmayacak ve yine de gerekli verileri toplayabileceksiniz.

Hâlâ önemli bir performans artışı alıyorsanız, GTM'nin ötesine geçin – belki de bu etiket yöneticisinin hatası değil, kullanım şeklidir. Bu konuşmada iyi stratejiler var: Üçüncü taraf performansına derinlemesine dalın. Örneğin, kritik komut dosyalarını GTM'den çıkarabilir ve yüklenmesini şelalenin sonlarına kadar erteleyebilirsiniz.

Bu seçim, site hızı ve geliri dengelemek kadar zor görünebilir, ancak olmamalı.

Buradaki amaç, reklamları kesintiye uğratmak yerine kullanıcı deneyiminin bir parçası haline getirmenin yaratıcı yollarını bulmaktır. O zaman gelir ve performans arasında seçim yapmanız gerekmez.

İşte öneriler:

• Beklenen içerik her zaman önce gelmelidir.

• Reklam bölümlerinin (ve görünme biçimlerinin) organik görünmesini sağlayın.

• Reklamların sayfanın ortasında aniden belirerek düzenin değişmesine ve kullanıcı etkileşiminin kesintiye uğramasına neden olmadığından emin olun. JavaScript'i kullanarak ve sarmalayıcılara minimum yüksekliği ayarlayarak onlar için önceden yer ayırın.

• Aynı anda çok fazla şey yüklemeyin. Ana iş parçacığı fazla çalışıyor ve düşük ücret alıyor ve daha küçük parçalar halinde sunuluyorsa daha hızlı çalışabilir. İki yaklaşım öneriyoruz: Tarayıcıların içinde yerleşik requestIdleCallback yönteminin yaratıcı kullanımı ve daha fazla öğe yüklemeden önce DOM'nin yüklemeyi tamamlamasını beklemek.

• Bir kullanıcı bir sayfa ile etkileşime girdikten sonra reklamları yüklemek pek mantıklı değil; etkileşimde bulundukları için cezalandırılıyorlarmış gibi geliyor ki bu harika bir kullanıcı deneyimi değil. Reklamlar yükleniyor içerik, tarayıcıların tek iş parçacıklı olduğu gerçeğine saygı duyarak sunulur.

Geçici çözümler bulmak yerine, kullanıcıyı her zaman hesaba katan sağlam bir strateji uygulamak, yanıt verme metrikleri gelişse bile sizi uzun vadede ayakta tutacaktır.

Önemli Web Verileri, örneğin bir CI/CD sisteminde laboratuvar testleri için pek uygun değildir. Bir laboratuvar ortamının gerçek kullanıcıların karşılaştığı koşulları yeniden oluşturması zordur ve bu ölçümler oldukça durumsaldır.

Bununla birlikte, elinizden geleni kullanmalısınız, bu durumda Deniz Feneri. GitHub Actions ile entegrasyon için halihazırda oluşturulmuş ve kullanıma hazır birkaç popüler mekanizma vardır. Onları Eylem pazarında bulun.

Bir kontrol listesine sahip olmak bir yaklaşımdır. Başka bir yaklaşım, bunu otomatik hale getirmektir. WordPress'e özgü bazı platformlar, medyayı yükleme hızı için otomatik olarak optimize eden ve bu QA görevini yayınlama iş akışından kaldıran Adaptive Media özellikleri içerir.