Chrome DevRel ekibinin, 2023'te Core Web Vitals performansını iyileştirmenin en etkili yolları olduğuna inandığı en iyi uygulamalar koleksiyonu.
Yıllar içinde Google'da, web geliştiricilerine performansı nasıl iyileştirebilecekleri konusunda birçok öneride bulunduk.
Bu önerilerin her biri, tek tek birçok sitenin performansını artırabilir, ancak tüm önerilerin göz korkutucu olduğu kabul edilebilir ve gerçekçi bir şekilde, herhangi bir kişinin veya sitenin hepsini takip etme olanağı yoktur.
Web performansı günlük işiniz olmadığı sürece, hangi önerilerin siteniz üzerinde en büyük olumlu etkiyi yaratacağı büyük olasılıkla belli değildir. Örneğin, kritik CSS uygulamasının yükleme performansını iyileştirebileceğini okumuş ve resimlerinizi optimize etmenin önemli olduğunu da duymuş olabilirsiniz. Ancak, her iki konu üzerinde çalışmak için zamanınız yoksa hangisini seçeceğinize nasıl karar verirsiniz?
Chrome ekibi olarak, geçen yılı şu soruyu yanıtlamaya çalıştık: Geliştiricilerin kullanıcılarının performanslarını iyileştirmelerine yardımcı olmak için geliştiricilere verebileceğimiz en önemli öneriler nelerdir?
Bu soruyu doğru bir şekilde yanıtlamak için belirli bir önerinin yalnızca teknik açıdan değerini değil, geliştiricilerin bu önerileri gerçekten benimseme olasılığını etkileyen insani ve kurumsal faktörleri de göz önünde bulundurmalıyız. Diğer bir deyişle, bazı öneriler teoride son derece etkili olabilir, ancak gerçekte çok az site bunları uygulayacak zamana veya kaynağa sahip değildir. Benzer şekilde, bazı öneriler kritik önem taşır ancak çoğu web sitesi zaten bu uygulamaları izlemektedir.
Kısaca, en iyi web performansı önerilerimizin aşağıdaki noktalara odaklanmasını istedik:
- Gerçek dünyada en büyük etkiyi yaratacağını düşündüğümüz öneriler
- Çoğu site için alakalı ve geçerli olan öneriler
- Çoğu geliştiricinin uygulayabileceği gerçekçi öneriler
Geçtiğimiz yıl boyunca, sunduğumuz performans önerilerinin tamamını denetlemek ve bu önerilerin her birini (hem nitelik hem de nicelik olarak) yukarıdaki üç ölçüte göre değerlendirmek için çok zaman harcadık.
Bu yayında, Core Web Vitals metriklerinin her birinin performansını artırmaya yönelik en iyi önerilerimiz özetlenmektedir. Web performansı konusunda yeniyseniz veya paranızın karşılığını en fazla verenin ne olacağına karar vermeye çalışıyorsanız, bu önerilerin başlangıç için en iyi yer olduğunu düşünüyoruz.
Largest Contentful Paint (LCP)
İlk öneri grubumuz, yükleme performansının ölçüsü olan Largest Contentful Paint (LCP) ile ilgilidir. Üç Core Web Vitals metriği arasından LCP, en çok sayıda sitenin (günümüzde web'deki tüm sitelerin yalnızca yarı kadarı önerilen eşiği karşıladığı) mücadele ettiği metriktir. Bu nedenle, buradan başlayalım.
LCP kaynağının HTML kaynağından bulunabilir olduğundan emin olun
HTTP Arşivi'nden 2022 Web Almanağı'na göre mobil sayfaların %72'sinde LCP öğesi olarak resim yer alıyor. Diğer bir deyişle çoğu sitenin LCP'sini optimize edebilmesi için bu resimlerin hızlı yüklenebilmesi gerekiyor.
Çoğu geliştirici, görsel yükleme süresinin işin sadece bir parçası olduğunu düşünebilir. Bir diğer önemli bölüm ise bir resmin yüklenmeye başlamasından önce geçen süredir. HTTP Arşivi verileri, aslında birçok sitenin kilitlendiği yerde olduğunu göstermektedir.
Aslında LCP öğesinin resim olduğu sayfaların %39'u, HTML doküman kaynağından bulunabilir olmayan kaynak URL'lere sahipti. Başka bir deyişle, bu URL'ler standart HTML özelliklerinde (<img src="..."> veya <link rel="preload" href="..."> gibi) bulunamadı. Bu da tarayıcının bunları hızlı bir şekilde bulup hemen yüklemeye başlamasını sağlayacak.
Resmin yüklenmeye başlayabilmesi için bir sayfanın CSS veya JavaScript dosyalarının tam olarak indirilmesini, ayrıştırılmasını ve işlenmesini beklemesi gerekiyorsa zaten çok geç olabilir.
Genel kural olarak, LCP öğeniz bir resimse resmin URL'si her zaman HTML kaynağından bulunabilir olmalıdır. Bunu mümkün kılacak bazı ipuçları:
srcveyasrcsetözelliğine sahip bir<img>öğesi kullanarak resmi yükleyin. Oluşturmak için JavaScript gerektirendata-srcgibi standart olmayan özellikleri kullanmayın. Bunlar her zaman daha yavaş olur. Sayfaların %9'u,data-srcsayfasının arkasında LCP resimlerinin görünmesini engelliyor.SSR, tam sayfa işaretlemenin (resim dahil) HTML kaynağında mevcut olduğunu belirttiğinden istemci tarafı oluşturma (CSR) yerine sunucu tarafı oluşturmayı (SSR) tercih edin. CSR çözümleri, resmin bulunabilmesi için JavaScript'in çalışmasını gerektirir.
Resminize harici bir CSS veya JS dosyasından referans verilmesi gerekiyorsa resmi yine bir
<link rel="preload">etiketi aracılığıyla HTML kaynağına ekleyebilirsiniz. Satır içi stiller tarafından başvurulan resimlerin, tarayıcının önceden yükleme tarayıcısı tarafından keşfedilemediğini unutmayın. Bu nedenle, HTML kaynağında bulunsalar bile diğer kaynakların yüklenmesi sırasında bu resimlerin keşfedilmesi engellenebilir. Bu nedenle, bu durumlarda önceden yükleme yardımcı olabilir.
LCP resminizde keşfedilebilirlik sorunları olup olmadığını anlamanıza yardımcı olmak için Lighthouse, 10.0 sürümünde (Ocak 2023'te yapılması bekleniyor) yeni bir denetim yayınlayacaktır.
LCP kaynağının HTML kaynağından bulunabilir olmasını sağlamak ölçülebilir iyileşmeler sağlayabilir ve bir sonraki önerimiz olan kaynağa öncelik vermek için ek fırsatların kilidini açar.
LCP kaynağına öncelik verildiğinden emin olun
LCP kaynağının HTML kaynağından keşfedilebildiğinden emin olmak, LCP kaynağının erken yüklenmeye başlamasını sağlamada kritik bir ilk adımdır. Ancak önemli bir adım da söz konusu kaynağın yüklenmesine öncelik verilmesi ve daha az önemli olan başka kaynakların arkasına yüklenmediğinden emin olmaktır.
Örneğin, LCP resminiz standart bir <img> etiketi kullanılarak HTML kaynağında mevcut olsa bile, sayfanızın <head> içinde bu <img> etiketinden önce bir düzine <script> etiketi bulunuyorsa resim kaynağınızın yüklenmeye başlaması biraz zaman alabilir.
Bu sorunu çözmenin en kolay yolu, LCP resminizi yükleyen <img> veya <link> etiketinde yeni fetchpriority="high" özelliğini ayarlayarak tarayıcıya hangi kaynakların en yüksek önceliğe sahip olduğuna dair bir ipucu vermektir. Bu komut, tarayıcıya, bu komut dosyalarının tamamlanmasını beklemek yerine dosyayı daha erken yüklemesini söyler.
Web Almanağı'na göre uygun sayfaların yalnızca %0,03'ü bu yeni API'den yararlanıyor.Bu da web'deki çoğu sitenin LCP'yi çok az çalışmayla iyileştirmesi için bolca fırsat olduğu anlamına geliyor. fetchpriority özelliği şu anda yalnızca Chromium tabanlı tarayıcılarda desteklense de bu API, diğer tarayıcıların göz ardı ettiği progresif bir geliştirmedir. Bu nedenle, geliştiricilerin bu özelliği hemen kullanmalarını önemle tavsiye ederiz.
Chromium olmayan tarayıcılar için, LCP kaynağının diğer kaynaklardan öncelikli olmasını sağlamanın tek yolu, dokümanın önceki bölümlerinde bu kaynağa başvurmaktır. Dokümanın <head> bölümünde çok sayıda <script> etiketi bulunan bir site örneğini tekrar kullanarak, LCP kaynağınızın bu komut dosyası kaynaklarından önce önceliklendirildiğinden emin olmak isterseniz bu komut dosyalarının herhangi birinden <link rel="preload"> etiketi ekleyebilir veya bu komut dosyalarını <body> içinde <img> etiketinin altına taşıyabilirsiniz. Bu yöntem işe yarar olsa da fetchpriority kullanımına kıyasla daha ergonomik olmadığından diğer tarayıcıların da yakında destek ekleyeceğini umuyoruz.
LCP kaynağına öncelik verirken bir diğer önemli nokta da kaynağın önceliğinin düşürülmesine neden olacak herhangi bir işlem yapmamanızdır (ör. loading="lazy" özelliğini eklemek). Günümüzde sayfaların %10'unun LCP resminde loading="lazy" ayarı var. Geç yükleme davranışını ayrım yapmadan tüm resimlere uygulayan resim optimizasyonu çözümlerine dikkat edin. Bu davranışı geçersiz kılmanın bir yolunu sunuyorlarsa LCP resmi için bunu kullandığınızdan emin olun. Hangi resmin LCP olacağından emin değilseniz makul bir aday seçmek için buluşsal yöntemler kullanmayı deneyin.
Kritik olmayan kaynakların ertelenmesi, LCP kaynağının göreceli önceliğini etkili bir şekilde artırmanın başka bir yoludur. Örneğin, kullanıcı arayüzünü desteklemeyen komut dosyaları (analiz komut dosyaları veya sosyal widget'lar gibi), load etkinliği tetiklenene kadar güvenli bir şekilde ertelenebilir. Bu sayede, ağ bant genişliği için diğer kritik kaynaklarla (LCP kaynağı gibi) rekabet etmemeleri sağlanır.
Özetlemek gerekirse LCP kaynağının erken ve yüksek öncelikli olarak yüklendiğinden emin olmak için aşağıdaki en iyi uygulamaları izlemeniz gerekir:
- LCP resminizin
<img>etiketinefetchpriority="high"ekleyin. LCP kaynağı,<link rel="preload">etiketi aracılığıyla yüklenirse üzülmeyin. Zira bu etikettefetchpriority="high"ayarlayabilirsiniz. - LCP resminizin
<img>etiketindeloading="lazy"özelliğini hiçbir zaman ayarlamayın. Bunu yapmak, resminizin önceliğini azaltır ve resmin yüklenmeye başlamasını geciktirir. - Mümkün olduğunda kritik olmayan kaynakları erteleyin. Bunları dokümanınızın sonuna taşıyarak, resimler veya iframe'ler için yerel geç yükleme özelliğini kullanarak veya JavaScript aracılığıyla eşzamansız olarak yükleyerek yapabilirsiniz.
Belge ve kaynak TTFB'yi optimize etmek için CDN kullanın
Önceki iki öneride, LCP kaynağınızın erken keşfedilip yüklenmeye hemen başlanması için bu kaynağa öncelik verilmesine odaklanıldı. Bu yapbozun son parçası, ilk belge yanıtının da mümkün olduğunca hızlı ulaşmasını sağlamaktır.
Tarayıcı, ilk HTML dokümanı yanıtının ilk baytını alana kadar herhangi bir alt kaynağı yüklemeye başlayamaz. Bu durum ne kadar erken gerçekleşirse diğer her şey de o kadar erken gerçekleşmeye başlayabilir.
Bu süre, İlk Bayt Zamanı (TTFB) olarak bilinir ve TTFB'yi azaltmanın en iyi yolu şudur:
- İçeriğinizi, kullanıcılarınıza coğrafi olarak mümkün olduğunca yakın bir yerde sunun
- Yakın zamanda istenen içeriğin hızlıca tekrar sunulabilmesi için ilgili içeriği önbelleğe alın.
Bunların ikisini de yapmanın en iyi yolu CDN kullanmaktır. CDN'ler, kaynaklarınızı dünyanın dört bir yanına dağılmış uç sunuculara dağıtır ve böylece bu kaynakların kullanıcılarınıza kablodan geçmesi gereken mesafeyi sınırlar. CDN'ler ayrıca, genellikle sitenizin ihtiyaçlarına göre özelleştirilebilen ve optimize edilebilen ayrıntılı önbelleğe alma denetimlerine de sahiptir.
Birçok geliştirici, statik öğeleri barındırmak için CDN kullanmaya alışkındır, ancak CDN'ler dinamik olarak oluşturulmuş olsalar bile HTML dokümanlarını sunabilir ve önbelleğe alabilir.
Web Almanağı'na göre, HTML belge isteklerinin yalnızca %29'u bir CDN'den gönderilmiştir. Bu, sitelerin ek tasarruf talebinde bulunmaları için önemli bir fırsat olduğu anlamına gelir.
CDN'lerinizi yapılandırmayla ilgili bazı ipuçları:
- İçeriğin önbelleğe alınan süreyi artırmayı düşünün (örneğin, içeriğin her zaman yeni olması gerçekten kritik mi? Yoksa birkaç dakika eski olabilir mi?).
- Hatta içeriği süresiz olarak önbelleğe almayı ve güncelleme yaptığınızda önbelleği temizlemeyi bile düşünebilirsiniz.
- Kaynak sunucunuzda çalışan dinamik mantığı ucuna (çoğu modern CDN'nin bir özelliğidir) taşıyıp taşıyamayacağınızı öğrenin.
Genel olarak, doğrudan uçtan içerik yayınlayabileceğiniz her zaman (kaynak sunucunuza gidilmesini önleyerek) performans kazancı sağlar. Yolculuğu kaynak sunucunuza kadar geri getirmek zorunda kalsanız bile, CDN'ler genellikle bunu çok daha hızlı yapmak için optimize edilir. Dolayısıyla her iki durumda da avantajlı olur.
Cumulative Layout Shift (CLS)
Sıradaki öneri, web sayfalarında görsel kararlılığın ölçüsü olan Cumulative Layout Shift (CLS) ile ilgilidir. CLS, 2020'den beri web'de çok gelişmiş olsa da web sitelerinin yaklaşık dörtte biri önerilen eşiği henüz karşılamıyor. Bu nedenle, birçok sitenin kullanıcı deneyimini iyileştirmesi için hâlâ büyük bir fırsat var.
Sayfadan yüklenen tüm içeriklerin uygunsuz boyutlarını ayarlayın
Düzen kaymaları genellikle mevcut içerik, diğer içeriğin yüklenmesi bittikten sonra hareket ettiğinde ortaya çıkar. Bu nedenle, sorunun etkilerini azaltmanın birincil yolu, gerekli alanları mümkün olduğunca önceden ayırmaktır.
Boyutlandırılmamış resimlerden kaynaklanan düzen kaymalarını düzeltmenin en doğrudan yolu, width ve height özelliklerini (veya eşdeğer CSS özelliklerini) açık bir şekilde ayarlamaktır. Ancak HTTP Arşivi'ne göre sayfaların %72'sinde en az bir adet boyutlandırılmamış resim bulunuyor. Açık bir boyut olmazsa tarayıcılar, başlangıçta varsayılan yüksekliği 0px olarak ayarlar ve resim son olarak yüklendiğinde ve boyutlar keşfedildiğinde düzende belirgin bir kaymaya neden olabilir. Bu hem kolektif web için büyük bir fırsat teşkil ediyor hem de bu fırsat, bu makalede önerilen diğer önerilerin bazılarına göre çok daha az çaba gerektiriyor.
CLS'ye katkıda bulunan tek şeyin resimler olmadığını unutmamak da önemlidir. Düzen kaymaları, üçüncü taraf reklamları veya yerleştirilmiş videolar dahil olmak üzere genellikle sayfa ilk oluşturulduktan sonra yüklenen diğer içeriklerden kaynaklanabilir. aspect-ratio özelliği bununla mücadeleye yardımcı olabilir. Bu, geliştiricilerin açıkça resimlere ve resim olmayan öğelere en boy oranı sağlamalarına olanak tanıyan nispeten yeni bir CSS özelliğidir. Bu, dinamik bir width ayarlamanıza (örneğin, ekran boyutuna göre) ve tarayıcının uygun yüksekliği, büyük ölçüde büyük boyutlu resimlerde olduğu gibi otomatik olarak hesaplamasını sağlamanıza olanak tanır.
Bazen dinamik bir içerik, doğası gereği dinamik olduğundan tam boyutunu bilmek mümkün olmaz. Bununla birlikte, tam boyutu bilmeseniz bile düzen kaymalarının önem derecesini azaltmak için gerekli adımları uygulayabilirsiniz. Anlamlı bir min-height ayarlamak, tarayıcının boş bir öğe için varsayılan 0px yüksekliğini kullanmasına izin vermekten hemen sonra her zaman daha iyidir. min-height kullanmak, genellikle kapsayıcının gerektiğinde son içerik yüksekliğine kadar büyümesini sağladığı için genellikle kolay bir çözümdür. Tam miktardan bu büyümeyi daha toleranslı bir seviyeye düşürmüştür.
Sayfaların bfcache için uygun olduğundan emin olun
Tarayıcılar, doğrudan bellek anlık görüntüsünden tarayıcı geçmişinde daha önceki veya sonraki bir sayfayı anında yüklemek için geri-ileri önbellek (veya kısaca bfcache) adı verilen bir gezinme mekanizması kullanır.
Bfcache, tarayıcı düzeyinde önemli bir performans optimizasyonudur ve sayfa yükleme sırasında düzen kaymalarını tamamen ortadan kaldırır. Çoğu sitede CLS'nin büyük bir kısmının görüldüğü sayfadır. Bfcache'in kullanıma sunulması, CLS'de 2022'de gördüğümüz en büyük iyileşmeyi sağladı.
Buna rağmen, bazı web siteleri bfcache için uygun olmadığından önemli sayıda gezinmeyle web'de ücretsiz olarak sunulan bu performanstan yararlanamıyorlar. Sayfanız bellekten geri yüklenmesini istemediğiniz hassas bilgiler yüklenmiyorsa sayfalarınızın uygun olduğundan emin olmanız gerekir.
Site sahipleri, sayfalarının bfcache için uygun olup olmadığını kontrol etmeli ve uygun olmama nedenleri üzerinde çalışmalıdır. Chrome'un Geliştirici Araçları'nda zaten bir bfcache test kullanıcısı var. Bu yıl, benzer bir test gerçekleştiren yeni bir Lighthouse denetimi ve bunu sahada ölçen bir API ile araçları geliştirmeyi planlıyoruz.
bfcache'yi CLS bölümüne dahil etmiş olsak da şimdiye kadar en büyük kazanımları gördüğümüz gibi, bfcache genellikle diğer Core Web Vitals'ı da iyileştirecektir. Bu, sayfada gezinmeleri büyük ölçüde iyileştirmek için kullanılabilen birkaç anında gezinme işleminden biridir.
Düzeni tetikleyen CSS özellikleri kullanan animasyonlardan/geçişlerden kaçının
Düzen kaymalarının yaygın bir diğer kaynağı da öğelerin animasyonlu olmasıdır. Örneğin, üstten veya alttan kayan çerez banner'ları veya diğer bildirim banner'ları genellikle CLS'ye katkıda bulunur. Bu, özellikle bu banner'lar diğer içerikleri dışarı ittiğinde sorun yaşanır. Aksi halde, bunların animasyonunun uygulanması CLS'yi etkileyebilir.
HTTP Arşivi verileri animasyonları düzen kaymalarına kesin olarak bağlayamasa da veriler, düzeni etkileyebilecek herhangi bir CSS özelliğini canlandıran sayfaların "iyi" olma ihtimalinin% 15 daha düşük olduğunu gösteriyor. CLS daha fazla. Bazı tesisler diğerlerinden daha kötü CLS ile ilişkilendirilir. Örneğin, margin veya border genişlikleri animasyonlu olan sayfalar "kötü" değerine sahiptir CLS'ye oranı, genel olarak sayfaların kötü olarak değerlendirilme oranıyla neredeyse iki kat daha yüksek.
Bu durum şaşırtıcı olmayabilir çünkü düzeni tetikleyen herhangi bir CSS özelliğine geçiş yaptığınızda veya animasyon eklediğinizde düzen kaymalarına neden olur ve bu düzen kaymaları bir kullanıcı etkileşiminden sonraki 500 milisaniye içinde gerçekleşmezse CLS'yi etkiler.
Bazı geliştiriciler şaşırtıcı olabilir; ancak, öğe normal belge akışının dışına alındığında bile bu durum geçerlidir. Örneğin, top veya left animasyonu içeren kesinlikle konumlandırılmış öğeler başka içerikleri itmeseler bile düzen kaymalarına neden olur. Ancak top veya left animasyonunu uygulamak yerine transform:translateX() veya transform:translateY() animasyonlarını gerçekleştirirseniz bu işlem, tarayıcının sayfa düzenini güncellemesine ve dolayısıyla da düzen kaymasına neden olmaz.
Tarayıcının birleştirici iş parçacığında güncellenebilecek CSS özelliklerinin animasyonlarının tercih edilmesi, GPU'ya ve ana iş parçacığının dışına taşındığı için uzun zamandır performansla ilgili en iyi uygulamalardan biridir. Genel performans en iyi uygulaması olmasının yanı sıra CLS'yi iyileştirmeye de yardımcı olabilir.
Genel bir kural olarak, kullanıcının dokunmasına veya tuşa basmasına yanıt olarak yapmadığınız sürece (hover değil) hiçbir zaman, tarayıcının sayfa düzenini güncellemesini gerektiren CSS mülklerine animasyon eklemeyin veya bu mülklerin geçişini yapmayın. Ayrıca, mümkün olduğunda CSS transform özelliğini kullanarak geçişleri ve animasyonları tercih edin.
Bileşik olmayan animasyonlardan kaçının Lighthouse denetimi, bir sayfa yavaş olabilecek CSS özelliklerine animasyon girdiğinde uyarı verir.
First Input Delay (FID)
Son öneri grubumuz, bir sayfanın kullanıcı etkileşimlerine duyarlılığını ölçen İlk Giriş Gecikmesi (FID) ile ilgilidir. Web'deki çoğu site şu anda İGG metriğiyle ilgili çok iyi puanlar elde ediyor olsa da geçmişte FID metriğindeki eksiklikleri belgeledik ve sitelerin, kullanıcı etkileşimlerine genel olarak yanıt verme durumlarını iyileştirecek pek çok fırsat olduğunu düşünüyoruz.
Yeni Sonraki Boyamayla Etkileşim (INP) metriğimiz, FID'in yerini alacak olası bir metriktir. Aşağıdaki önerilerin tümü, hem FID hem de INP için aynı ölçüde geçerlidir. Sitelerin, özellikle mobil cihazlarda INP'de FID'ye göre daha kötü performans gösterdiği göz önünde bulundurulduğunda, geliştiricilerin "iyi" olsalar da bu yanıt verme önerilerini ciddi bir şekilde dikkate almalarını öneririz. İGG.
Uzun görevlerden kaçınmak veya uzun görevleri bölünmeksizin
Görevler, tarayıcının yaptığı ayrı ayrı çalışmalardır. Görevleri arasında komut dosyalarını oluşturma, düzenleme, ayrıştırma, derleme ve yürütme yer alır. Görevler uzun görevlere (yani 50 milisaniye veya daha uzun) dönüştüğünde, ana iş parçacığının kullanıcı girişlerine hızlı yanıt vermesini engeller.
Web Almanağı'na göre, geliştiricilerin uzun görevleri önlemek veya parçalara ayırmak için daha fazla şey yapabileceklerini gösteren çok sayıda kanıt vardır. Uzun görevleri bölme işlemi, bu makaledeki diğer öneriler kadar çaba gerektirmeyebilir, ancak bu makalede sunulmayan diğer tekniklere göre daha az çaba gerektirdiğini gösterir.
JavaScript'te her zaman mümkün olduğunca az iş yapmaya çalışmalısınız ancak uzun görevleri küçük görevlere ayırarak ana ileti dizisine oldukça yardımcı olabilirsiniz. Oluşturma güncellemelerinin ve diğer kullanıcı etkileşimlerinin daha hızlı gerçekleşmesi için bunu genellikle ana iş parçacığını vererek yapabilirsiniz.
Diğer bir seçenek de isInputPending ve Scheduler API gibi API'leri kullanmaktır. isInputPending, bir kullanıcı girişinin beklemede olup olmadığını gösteren boole değeri döndüren bir işlevdir. true değerini döndürürse bekleyen kullanıcı girişini işleyebilmesi için ana ileti dizisine veri sağlayabilirsiniz.
Scheduler API daha gelişmiş bir yaklaşımdır ve yapılan işin kullanıcı tarafından görülebilir mi yoksa arka planda mı olduğunu dikkate alan bir öncelik sistemine göre çalışma planlamanıza olanak tanır.
Uzun görevleri parçalara ayırarak tarayıcının, etkileşimleri ve sonuçta ortaya çıkan oluşturma güncellemelerini ele alma gibi, kullanıcının görebildiği kritik çalışmalara uyması için daha fazla fırsat yaratmış olursunuz.
Gereksiz JavaScript'ten kaçının
Hiç kuşku yok: Web sitelerinde her zamankinden daha fazla JavaScript gönderimi yapılıyor ve bu trend yakın zamanda değişecek gibi görünmüyor. Çok fazla JavaScript gönderdiğinizde görevlerin ana iş parçacığının dikkatini çekmek için yarıştığı bir ortam oluşturmuş olursunuz. Bu durum, özellikle o önemli başlangıç döneminde web sitenizin duyarlılığını kesinlikle etkileyebilir.
Ancak bu, çözülemez bir sorun değildir. Bazı seçenekleriniz vardır:
- Web sitenizin kaynaklarında kullanılmayan kodları bulmak için Chrome Geliştirici Araçları'ndaki kapsam aracını kullanın. Başlatma sırasında ihtiyaç duyduğunuz kaynakların boyutunu küçülterek web sitenizin kod ayrıştırma ve derlemeye daha az vakit ayırmasını sağlayabilir, böylece daha sorunsuz bir ilk kullanıcı deneyimi sağlayabilirsiniz.
- Bazen kapsam aracını kullanarak bulduğunuz kullanılmayan kod "kullanılmıyor" olarak işaretlenir çünkü başlatma sırasında yürütülmemiştir, ancak gelecekte bazı işlevler için yine de gerekli olacaktır. Bu, kod bölme işlemini kullanarak ayrı bir pakete taşıyabileceğiniz koddur.
- Bir etiket yöneticisi kullanıyorsanız, hâlâ kullanılıyor olsalar bile etiketlerinizi düzenli aralıklarla kontrol ederek optimize edildiğinden emin olun. Kullanılmayan kod içeren eski etiketler, etiket yöneticinizin JavaScript'ini daha küçük ve verimli hale getirmek için silinebilir.
Büyük çaplı oluşturma güncellemelerini önleme
Web sitenizin duyarlılığını etkileyebilecek tek şey JavaScript değildir. Oluşturma işlemi, kendi başına pahalı bir iş olabilir ve büyük oluşturma güncellemeleri gerçekleştiğinde web sitenizin kullanıcı girişlerine yanıt vermesini engelleyebilir.
Oluşturma işlemini optimize etmek basit bir süreç değildir ve genellikle ne elde etmeye çalıştığınıza bağlıdır. Yine de oluşturma güncellemelerinizin makul olduğundan ve uzun görevlere yayılmadığından emin olmak için yapabileceğiniz bazı şeyler vardır:
- Görsel olmayan işler için
requestAnimationFrame()kullanmaktan kaçının.requestAnimationFrame()çağrıları, etkinlik döngüsünün oluşturma aşamasında işlenir ve bu adımda çok fazla iş yapılırsa güncellemelerin oluşturulması gecikebilir.requestAnimationFrame()ile yaptığınız tüm işlerin yalnızca güncelleme oluşturma içeren görevlere ayrılması önemlidir. - DOM boyutunuzu küçük tutun. DOM boyutu ve düzen çalışmasının yoğunluğu orantılıdır. Oluşturucunun düzeni çok büyük bir DOM için güncellemesi gerektiğinde, sayfa düzenini yeniden hesaplamak için gereken iş önemli ölçüde artabilir.
- CSS kapsamını kullanın. CSS kapsamı, tarayıcıya
containözelliğinin ayarlandığı kapsayıcı için düzenin nasıl çalışacağı hakkında talimatlar veren CSScontainözelliğini kullanır. Bu özellik, düzenin kapsamının izole edilmesi ve DOM'deki belirli bir kökle oluşturulması bile buna dahildir. Bu her zaman kolay bir süreç değildir, ancak karmaşık düzenler içeren alanları izole ederek bunlar için gerekli olmayan düzen ve oluşturma işlemlerinden kaçınabilirsiniz.
Sonuç
Özellikle web'de göz önünde bulundurulması gereken çok sayıda yönlendirme olduğu için, sayfa performansını iyileştirmek göz korkutucu bir görev gibi görünebilir. Ancak bu önerilere odaklanarak soruna belirli bir odak ve amaç doğrultusunda yaklaşabilir ve web sitenizin Core Web Vitals performansını artırmasını umut edebilirsiniz.
Burada listelenen öneriler kesinlikle kapsamlı olmasa da web'in durumu hakkında dikkatli bir analize dayanarak bu önerilerin, sitelerin 2023'te Core Web Vitals performanslarını iyileştirmek için en etkili yollar olduğuna inanıyoruz.
Burada sıralanan önerilerin ötesine geçmek isterseniz daha fazla bilgi için şu optimizasyon kılavuzlarını inceleyebilirsiniz:
Herkes için daha hızlı bir web ve yeni bir yıla merhaba deyin. Sitelerinizin kullanıcılarınız için en önemli konularda hızlı olmasını sağlayın.
Fotoğrafçı: Devin Avery