Core Web Vitals'ı iyileştirmenin en etkili yolları

Yıllar içinde web topluluğu, web performansı optimizasyonu konusunda oldukça bilgi sahibidir. Her bir optimizasyon birçok sitenin performansını artırabilir ancak bunların hepsini aynı anda uygulamak çok zor olabilir ve gerçekte bunların yalnızca bazıları belirli bir site için uygulanabilir.

Web performansı tam zamanlı işiniz değilse siteniz için en etkili optimizasyonların hangileri olacağı muhtemelen net değildir. Bunların hepsini uygulamak için zamanınız olmayabilir. Bu nedenle, kendinize kullanıcılarınızın performansını artırmak için seçebileceğiniz en etkili optimizasyonlar neler? sorusunu sormanız önemlidir.

Performans optimizasyonlarıyla ilgili gerçek şudur: Bu optimizasyonları yalnızca teknik özelliklerine göre değerlendiremezsiniz. Ayrıca, belirli bir optimizasyonu uygulama olasılığınızı etkileyen insan ve kuruluş faktörlerini de göz önünde bulundurmanız gerekir. Bazı performans iyileştirmeleri teoride çok etkili olabilir ancak gerçekte bunları uygulamak için zaman veya kaynaklara sahip olan geliştirici sayısı azdır. Öte yandan, neredeyse herkesin halihazırda takip ettiği, çok etkili performans en iyi uygulamaları olabilir. Bu kılavuzda, aşağıdakileri sağlayan web performansı optimizasyonları açıklanmaktadır:

• Gerçek dünyada en büyük etkiye sahip olmalıdır.
• Çoğu site için alakalı ve geçerlidir.
• Çoğu geliştiricinin uygulamaya koyması gerçekçidir.

Birlikte ele alındığında bunlar, Core Web Vitals metriklerinizi iyileştirmenin en gerçekçi ve etkili yollarıdır. Web performansı konusunda yeniyseniz veya size en büyük yatırım getirisini neyin sağlayacağına henüz karar vermediyseniz en iyi başlangıç noktası budur.

Interaction to Next Paint (INP)

En yeni Core Web Vitals metriği olan Interaction to Next Paint (INP), en büyük iyileştirme fırsatlarından bazılarını sunar. Ancak desteği sonlandırılan önceki sürümüne kıyasla "iyi" deneyimler için eşikten daha az sayıda site geçtiğinden, etkileşim yanıt verimini ilk kez nasıl optimize edeceğinizi öğrenen çok sayıda geliştirici arasında olabilirsiniz. INP'yi artırmanın en etkili yolları için bu bilinmesi gereken tekniklerden başlayın.

1. Uzun görevleri parçalara ayırmak için sık sık teslim yapın

Görevler, oluşturma, düzen, ayrıştırma, derleme veya komut dosyalarını yürütme dahil olmak üzere tarayıcının yaptığı ayrı bir çalışma parçasıdır. 50 milisaniyeyi aşan görevler uzun görev haline gelir. Uzun görevler, ana ileti dizisinin kullanıcı etkileşimlerine hızlı yanıt vermesini engelleyebileceğinden sorunludur.

JavaScript'te her zaman mümkün olduğunca az işlem yapmaya çalışmalısınız. Bununla birlikte, uzun görevleri bölerek ana ileti dizisine yardımcı olabilirsiniz. Ana iş parçacığına sık sık vererek bunu yapabilirsiniz. Böylece oluşturma güncellemeleri ve diğer kullanıcı etkileşimleri daha erken gerçekleşebilir.

Scheduler API, öncelik sistemi kullanarak işleri sıraya almanıza olanak tanır. Daha açık belirtmek gerekirse scheduler.yield() API'si, uzun görevleri bölerken etkileşimlerin görev kuyruğundaki yerlerinden vazgeçmeden işlenebildiğinden emin olur.

Uzun görevleri bölerek tarayıcıya, kullanıcının erişimini engelleyen kritik işlemleri gerçekleştirmesi için daha fazla fırsat vermiş olursunuz.

2. Gereksiz JavaScript'ten kaçının

Web siteleri her zamankinden daha fazla JavaScript gönderimi yapıyor ve bu trend değişmiyor. Ç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 de önemli olan ilk açılış döneminde web sitenizin duyarlılığını etkileyebilir.

Ancak bu çözülemez bir sorun değildir ve aşağıdaki seçeneklerden yararlanabilirsiniz:

• Gereksiz, JavaScript tabanlı uygulamalar yerine Temel yaygın olarak kullanılabilen web platformu özelliklerini kullanın.
• Komut dosyalarınızda kullanılmayan kodu bulmak için Chrome Geliştirici Araçları'ndaki kapsam aracını kullanın. Başlatma sırasında gereken kaynakların boyutunu küçülterek sayfaların kod ayrıştırma ve derlemeye daha az zaman harcamasını sağlayabilir, böylece daha sorunsuz bir ilk kullanıcı deneyimi sağlayabilirsiniz.
• İlk oluşturma işlemi için gerekli olmayan ancak daha sonra kullanılacak olan ayrı bir kod grubu oluşturmak için kod bölme işlevini kullanın.
• Bir etiket yöneticisi kullanıyorsanız düzenli olarak etiketlerinizi optimize edin. Etiket Yöneticisi'nizin JavaScript ayak izini azaltmak için kullanılmayan kod içeren eski etiketler kaldırılabilir.

3. Büyük çaplı oluşturma güncellemelerini önleme

JavaScript'in yürütülmesi, web sitenizin duyarlılığını etkileyen faktörlerden yalnızca biridir. Oluşturma işlemi, başlı başına pahalı bir işlemdir. Büyük oluşturma güncellemeleri sırasında web siteniz kullanıcı etkileşimlerine daha da yavaş yanıt verebilir.

Oluşturma işlemini optimize etmek basit bir süreç değildir ve ne elde etmeye çalıştığınıza bağlıdır. Yine de oluşturma görevlerinin uzun görevlere dönüşmesini önlemek için şunları yapabilirsiniz:

• Zorunlu düzen ve düzen karmaşası sorunlarını önlemek için JavaScript kodunuzdaki DOM okuma ve yazma işlemlerini yeniden düzenleyin.
• DOM boyutlarını küçük tutun. DOM boyutu ve düzen çalışmasının yoğunluğu arasında bir ilişki vardır. Oluşturucunun çok büyük bir DOM'un düzenini güncellemesi gerektiğinde, düzenini yeniden hesaplamak için gereken çalışma önemli ölçüde artabilir.
• Ekran dışındaki DOM içeriklerini üşengeç şekilde oluşturmak için CSS kapsayıcıyı kullanın. Bu her zaman kolay olmasa da karmaşık düzenler içeren alanları izole ederek gereksiz düzen ve oluşturma işlerinden kaçınabilirsiniz.

Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP), geliştiricilerin en çok zorlandıkları Core Web Vitals'dır. Chrome Kullanıcı Deneyimi Raporu'ndaki sitelerin %40'ı, iyi kullanıcı deneyimi için önerilen LCP eşiğini karşılamıyor. Chrome Ekibi, LCP'yi iyileştirmenin en etkili yolları olarak aşağıdaki teknikleri önerir.

1. LCP kaynağının HTML kaynağından bulunabilir ve öncelikli olduğundan emin olun

Chrome ekibi, web'deki LCP ile ilgili olarak aşağıdakileri fark etti:

• HTTP Archive'nin 2022 Web Almanağı'na göre, mobil sayfaların %72'sinde LCP öğesi olarak bir resim bulunuyor.
• Chrome'daki gerçek kullanıcı verilerinin analizine göre, LCP'si düşük olan kaynakların çoğu, p75 LCP sürelerinin %10'undan azını LCP resmini indirmek için harcıyor.
• LCP'si düşük olan sayfalarda, LCP resimlerinin yüklenmesi istemcide 75. yüzdelik dilimde 1.290 milisaniye gecikiyor. Bu, hızlı bir deneyim için ayrılan bütçenin yarısından fazlası.
• LCP öğesinin resim olduğu sayfaların bu resimlerin% 39'unda, ilk HTML yanıtında bulunamayan kaynak URL'ler (<img src="..."> veya <link rel="preload" href="..."> gibi) vardı. Bu URL'ler, tarayıcının önceden yükleme tarayıcısının bunları en kısa sürede keşfetmesine olanak tanıdı.
• Web Almanağı'na göre, uygun sayfaların yalnızca %0,03'ü, bir sayfanın LCP'sini nispeten az çabayla iyileştirebilecekleri kaynaklar da dahil olmak üzere kaynaklara daha yüksek öncelik vermek için fetchpriority HTML özelliğinden yararlanıyordu.

Bu istatistikler, geliştiricilerin LCP resimleri için hem kaynak yükleme gecikmesini hem de kaynak yükleme süresini azaltma konusunda büyük bir fırsata sahip olduğunu göstermektedir.

Sorunun kaynak yükleme gecikmesi olduğu durumlarda, bir sayfanın resimlerin yüklenmeye başlaması için CSS veya JavaScript'in tamamen yüklenmesini beklemesi gerekiyorsa iyi bir LCP elde etmek için çok geç olabileceğini unutmayın. Ayrıca, LCP resminin kaynak yükleme süresi, fetchpriority HTML özelliği kullanılarak yeniden önceliklendirilerek daha fazla bant genişliği almasını ve dolayısıyla daha hızlı yüklenmesini sağlayabilir.

LCP öğeniz bir resimse resim URL'sinin, kaynak yükleme gecikmesini azaltmak için HTML yanıtında bulunabilir olması gerekir. Bunu yapmanıza yardımcı olacak bazı ipuçları:

• src veya srcset özelliğine sahip bir <img> öğesi kullanarak resmi yükleyin. Oluşturmak için JavaScript gerektiren data-src gibi standart olmayan özellikleri kullanmayın. Bunlar her zaman daha yavaş olur. Sayfaların %9'unda LCP resmi data-src öğesinin arkasına gizleniyor.
• SSR, sayfa işaretlemesinin tamamının (resim dahil) HTML kaynağında bulunduğu anlamına geldiğinden istemci tarafı oluşturma (CSR) yerine sunucu tarafı oluşturmayı (SSR) tercih edin. Görüntünün keşfedilebilmesi için CSR çözümlerinin JavaScript'in çalışması gerekir.
• Resminize harici bir CSS veya JS dosyasından referans verilmesi gerekiyorsa resmi yine bir <link rel="preload"> etiketi kullanarak HTML kaynağına ekleyebilirsiniz. Satır içi stillerin referans verdiği resimlerin, tarayıcının önyükleme tarayıcısı tarafından bulunamayacağını unutmayın. Bu nedenle, HTML kaynağında bulunsalar bile diğer kaynakların yüklenmesi sırasında keşfedilmeleri engellenebilir. Bu gibi durumlarda önyükleme yardımcı olabilir.

Ayrıca, LCP kaynağının erken ve yüksek öncelikli olarak yüklenmesini sağlayarak bir kaynağın yükleme süresini kısaltabilirsiniz:

• LCP resminizin <img> veya <link rel="preload"> etiketine fetchpriority="high" özelliğini ekleyin. Bu işlem, resim kaynağının önceliğini artırarak daha erken yüklenmeye başlamasını sağlar.
• LCP resminizin <img> etiketinden loading="lazy" özelliğini kaldırın. Bu, resmin görüntü alanının içinde veya yakınında göründüğünün onaylanmasından kaynaklanan yükleme gecikmesini önler.
• Mümkün olduğunda kritik olmayan kaynakları erteleyin. Bu kaynakları belgenizin sonuna taşımak, resim veya iFrame'leri gecikmeli olarak yüklemek ya da JavaScript kullanarak eşzamansız olarak yüklemek, LCP resmi gibi daha önemli kaynakların daha hızlı yüklenmesini sağlar.

2. Anında gezinmeyi hedefleyin

İdeal kullanıcı deneyimi, sayfanın yüklenmesini beklemek zorunda kalmamaktır. Kaynak bulunabilirliği ve önceliklendirme gibi LCP optimizasyonları, kullanıcının LCP öğesinin yüklenmesi ve oluşturulması için bekleme süresini azaltmada etkilidir. Ancak bu baytların ağ üzerinden ne kadar hızlı yükleneceği ve bir sayfada oluşturulacağı konusunda fiziksel bir sınır vardır. Bu sınıra ulaşmadan çok önce, yalnızca birkaç milisaniye daha kazanmak için çok fazla çaba sarf etmeniz gerekir. Bu nedenle, anında gezinme sağlamak için tamamen farklı bir yaklaşım benimsememiz gerekiyor.

Anında gezinmeler, kullanıcı sayfaya gitmeye başlamadan önce sayfayı yükleyip oluşturmaya çalışır. Bu sayede, önceden oluşturulmuş sayfa sıfıra yakın bir LCP ile hemen gösterilebilir. Restorasyon ve spekülasyonlar bunu yapmanın iki yoludur. Kullanıcı daha önce ziyaret ettiği bir sayfaya geri veya ileri gittiğinde, sayfa bellek içi önbellekten hızlı bir şekilde geri yüklenerek kullanıcının bıraktığı haliyle gösterilebilir. Alternatif olarak, web uygulamaları kullanıcının bir sonraki gideceği yeri tahmin etmeye çalışabilir. Tahmin doğru olduğunda, kullanıcı ilgili sayfaya gittiğinde sayfa zaten yüklenmiş ve oluşturulmuş olur.

Daha önce ziyaret edilen sayfaların geri yüklenmesi geri-ileri önbellek (bfcache) ile mümkün olur. Bu özelliği kullanmak için sayfalarınızın bfcache uygunluk ölçütlerini karşıladığından emin olmanız gerekir. Sayfaların bfcache için uygun olmamasının yaygın nedenlerinden biri, no-store önbelleğe alma yönergeleriyle yayınlanmaları veya unload etkinlik dinleyicileri içermeleridir.

Tamamen oluşturulmuş sayfaları geri yüklemek yalnızca yükleme performansını değil, düzen kararlılığını da artırır. Sayfaların bfcache için uygun olduğundan emin olma bölümünde bfcache ve CLS'yi iyileştirmedeki etkinliği hakkında daha fazla bilgi edinebilirsiniz.

Kullanıcının ziyaret edeceği bir sonraki sayfayı önceden oluşturmak, LCP performansını önemli ölçüde iyileştirmenin etkili bir başka yoludur ve Spekülasyon Kuralları API ile mümkündür. Ancak bu avantajlardan yararlanmak için doğru sayfaların önceden oluşturulduğundan emin olun. Yanlış tahminler hem sunucuda hem de istemcide kaynakları boşa harcar ve performansı düşürebilir. Bu nedenle, bir sonraki sayfanın ne olacağı konusunda ne kadar emin değilseniz ön oluşturma işlemini o kadar dikkatli yapmanız gerekir. Kararsız kaldığınızda analiz verileriniz, bir sonraki ziyaret olasılığı en yüksek olan sayfaları daha hevesli bir şekilde önceden oluşturmanız için size güven verebilir.

3. TTFB'yi optimize etmek için CDN kullanın

Önceki öneri, kullanıcılara mümkün olan en iyi deneyimi sunan anında gezinmelere odaklanıyordu. Ancak bfcache ve spekülatif yükleme tekniklerinin uygulanamadığı durumlar olabilir. İlk HTML dokümanı yanıtının LCP'yi etkili bir şekilde engellediği, sitenize giden kaynakta farklı bir kaynak bağlantısını takip eden bir kullanıcıyı düşünün. Tarayıcı, yanıtın ilk baytını alana kadar herhangi bir alt kaynağı yüklemeye başlayamaz. Bu süreç ne kadar erken tamamlanırsa diğer işlemler de o kadar erken başlayabilir.

Bu süre, İlk Bayt Zamanı (TTFB) olarak bilinir. TTFB'yi azaltmanın en iyi yolları şunlardır:

• İçeriğinizi, kullanıcılarınıza coğrafi olarak olabildiğince yakın bir konumda sunun.
• Yakın gelecekte tekrar istenirse hızlıca sunulabilmesi için bu 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ındaki uç sunuculara dağıtarak bu kaynakların kablo üzerinden kullanıcılara ulaşması gereken mesafeyi sınırlandırır. CDN'ler ayrıca, genellikle sitenizin ihtiyaçlarına göre düzenlenebilecek ayrıntılı önbelleğe alma denetimlerine de sahiptir.

CDN'ler HTML dokümanlarını da yayınlayıp önbelleğe alabilir ancak Web Almanağı'na göre HTML dokümanı isteklerinin yalnızca %29'u CDN'den yayınlandı. Bu, sitelerin ek tasarruf elde etmek için önemli bir fırsata sahip olduğu anlamına gelir.

CDN'leri yapılandırmayla ilgili bazı ipuçları:

• Statik HTML dokümanlarını kısa bir süre için bile önbelleğe alın. Örneğin, içeriğin her zaman güncel olması önemli mi? Yoksa birkaç dakika gecikmiş olabilir mi?
• Kaynak sunucunuzda çalışan dinamik mantığı, çoğu modern CDN'nin bir özelliği olan ucuna taşıyıp taşıyamayacağınızı öğrenin.

Doğrudan uçta içerik yayınlayıp kaynak sunucuya gitmeyi önlediğinizde performans kazancı elde edersiniz. Yolculuğu kaynağa kadar tamamlamanız gerektiği durumlarda bile, CDN'ler genellikle bunu daha hızlı yapmak için optimize edilir. Dolayısıyla her iki durumda da avantajlı olur.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift (CLS), bir web sayfasının görsel kararlılığını ölçer. CLS, çoğu sitenin iyi performans gösterdiği bir metrik olsa da yaklaşık dörtte biri hâlâ önerilen eşiği karşılamıyor. Bu nedenle, birçok sitenin kullanıcı deneyimini iyileştirmek için yararlanabileceği büyük bir fırsat var.

1. Sayfadan yüklenen tüm içeriklerde net boyutlar ayarlama

Düzen kaymaları genellikle diğer içerikler yüklendikten sonra mevcut içerikler taşındığında gerçekleşir. CLS'yi iyileştirmenin birincil yolu, gerekli alanı mümkün olduğunca önceden ayırmaktır.

Boyutlandırılmamış resimlerden kaynaklanan düzen kaymalarını düzeltmenin en iyi yolu, width ve height özelliklerini veya eşdeğer CSS özelliklerini açıkça ayarlamaktır. Sayfaların %72'sinde en az bir boyutlandırılmamış resim var. Belirli bir boyutu olmayan bu resimlerin başlangıç yüksekliği 0px'tür. Bu, resimler yüklendiğinde ve tarayıcı boyutlarını keşfettiğinde düzen kaymalarına neden olabilir. Bu, kolektif web için büyük bir fırsattır ve bu fırsat, bu kılavuzda önerilen diğer önerilerden bazılarına kıyasla daha az çaba gerektirir.

CLS'ye katkıda bulunan tek öğe resimler değildir. Düzen kaymalarına, genellikle sayfa ilk oluşturulduktan sonra yüklenen diğer içerikler (ör. üçüncü taraf reklamlar veya yerleştirilmiş videolar) neden olabilir. aspect-ratio mülkü bu konuda yardımcı olabilir. Yaygın olarak kullanıma sunulan temel bir CSS özelliğidir. Bu özellik, geliştiricilerin hem resimlerde hem de resim olmayan öğelerde açıkça en boy oranı ayarlamasına olanak tanır. Bu sayede dinamik bir width (ör. ekran boyutuna göre) ayarlayabilir ve tarayıcıya, boyutları olan resimlerde olduğu gibi uygun yüksekliği otomatik olarak hesaplamasını sağlayabilirsiniz.

Ancak, dinamik içeriğin tam boyutunu bilmek her zaman mümkün değildir. Tam boyutu bilmeseniz bile sayfa düzeni değişikliklerinin önemini azaltabilirsiniz. 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 da genellikle basit bir çözümdür. Gerektiğinde kapsayıcının son içeriğin yüksekliğine kadar büyümesini sağlar. Bu büyümenin miktarı daha az tolere edilebilir bir düzeye indirilmiştir.

2. Sayfaların bfcache için uygun olduğundan emin olma

Bu kılavuzda daha önce belirtildiği gibi, geri-ileri önbellek (bfcache), bir sayfayı bellek anlık görüntüsünden anlık olarak ve tarayıcı geçmişinde daha önce veya daha sonra yükler. Bfcache, LCP'yi iyileştiren tarayıcı düzeyinde önemli bir performans optimizasyonudur ancak düzen kaymalarını da tamamen ortadan kaldırır. Aslında 2022'de bfcache'in kullanıma sunulması, o yıl CLS'de gördüğümüz en büyük iyileşmeden sorumluydu.

Buna rağmen, bazı web siteleri bfcache için uygun olmadığından bu ücretsiz web performansı avantajından yararlanamıyorlar. Sayfanız bellekten geri yüklenmesini istemediğiniz hassas bilgiler yüklenmiyorsa sayfalarınızın bfcache için uygun olduğundan emin olun.

Site sahipleri, sayfaların bfcache için uygun olup olmadığını kontrol etmeli ve uygun olmama nedenlerini düzeltmelidir. Chrome'da Geliştirici Araçları'nda bir bfcache test cihazı vardır. Ayrıca, alandaki uygunluk koşullarını karşılamama nedenlerini tespit etmek için Not Restored Reasons API'yi de kullanabilirsiniz.

3. Yerleşim oluşturan CSS özelliklerini kullanan animasyonlardan ve geçişlerden kaçının

Düzen hareketlerinin sık karşılaşılan bir diğer nedeni de öğelerin animasyonlu olmasıdır. Örneğin, yukarıdan veya alttan kayan çerez banner'ları veya diğer bildirim banner'ları genellikle CLS'ye katkıda bulunur. Bu durum, özellikle de bu banner'lar diğer içeriği engellediğinde sorun teşkil eder. Ancak engellemediğinde bile animasyonlu olmaları CLS'yi etkileyebilir.

HTTP Archive verileri, animasyonlarla sayfa düzeni değişiklikleri arasında kesin bir bağlantı kuramaz. Ancak veriler, sayfa düzenini etkileyebilecek CSS özelliklerini animasyonlu olarak kullanan sayfaların "iyi" CLS değerine sahip olma olasılığının genel sayfalara kıyasla %15 daha düşük olduğunu gösteriyor. Bazı tesisler diğerlerinden daha kötü CLS ile ilişkilendirilir. Örneğin, margin veya border genişliklerinde animasyon içeren sayfaların CLS değeri, genel olarak sayfaların kötü olarak değerlendirilme oranının neredeyse iki katı kadar "kötü"dür.

Bu durum şaşırtıcı değildir. Çünkü herhangi bir düzene neden olan CSS özelliğinde geçiş yaptığınızda veya animasyon uyguladığınızda düzen kaymalarına neden olursunuz. Bu düzen kaymaları, bir kullanıcı etkileşiminden sonraki 500 milisaniye içinde gerçekleşmezse CLS'yi etkiler.

Bazı geliştiriciler için şaşırtıcı olabilecek bir durum da, öğenin normal belge akışının dışına alındığı durumlarda bile bu durumun geçerli olmasıdır. Örneğin, top veya left öğelerini animasyonlu hale getiren ve mutlak konumlandırılmış öğeler, diğer içerikleri itmese bile sayfa düzeninde kaymalara neden olur. Ancak top veya left animasyonunu uygulamak yerine transform:translateX() veya transform:translateY() animasyonlarını kullanmanız, tarayıcının sayfa düzenini güncellemesine neden olmaz ve düzen kaymalarını önler.

Tarayıcıdaki oluşturucu iş parçacığında güncellenebilen CSS özelliklerinin animasyonu tercih etmek, bu işi ana iş parçacığından GPU'ya taşıdığı için uzun zamandır performansla ilgili en iyi uygulamalardan biri olarak kabul edilmektedir. Bu, genel performansla ilgili en iyi uygulamalardan biri olmasının yanı sıra CLS'yi iyileştirmeye de yardımcı olabilir.

Genel kural olarak, kullanıcının dokunmasına veya tuş basmasına yanıt olarak yapmadığınız sürece (hover olmasa da) tarayıcının sayfa düzenini güncellemesini gerektiren CSS özelliklerini hiçbir zaman animasyonlu hale getirmeyin veya geçiş yapmayın. Mümkün olduğunda, CSS transform mülkünü kullanarak geçişleri ve animasyonları tercih edin.

Birleştirilmemiş animasyonlardan kaçının Lighthouse denetimi, bir sayfa potansiyel olarak yavaş CSS özelliklerini animasyonlu hale getirdiğinde uyarı verir.

Sonuç

Sayfa performansını iyileştirmek, özellikle de web'de dikkate alınması gereken çok sayıda kılavuz olduğu düşünüldüğünde göz korkutucu görünebilir. Ancak en etkili en iyi uygulamaların yer aldığı bu kısa listeye odaklanarak soruna yeni bir odaklanmayla yaklaşabilir ve web sitenizin Core Web Vitals puanını iyileştirebilirsiniz.

Burada listelenen optimizasyonların ötesine geçmek istiyorsanız daha fazla bilgi için şu kılavuzları okuyun:

• INP'yi optimize etme
• LCP'yi optimize etme
• CLS'yi optimize edin

Ek: Değişiklik günlüğü

En iyi önerilerin ne zaman ve neden değiştiğini açıklamaya yardımcı olmak için bu belgedeki önemli değişiklikler burada izlenir.

Ekim 2024

2024 güncellemesi:

• INP
  • INP'nin Core Web Vitals metriği olarak kullanıma sunulmasıyla birlikte bu metriği FID'den INP'ye geçirdik ve listedeki en önemli metrik haline getirdik.
  • Uzun görevleri bölme kapsamında isInputPending API'yi kullanma önerimizi geri çektik. Nedenlerimiz hakkında daha fazla bilgiyi Uzun Görevleri Optimize Etme makalesinde bulabilirsiniz.
• LCP
  • Keşfedilebilirlik ve önceliklendirme önerilerini tek bir öneride birleştirdik.
  • Anında gezinme amacıyla yeni bir öneri ekledik.

Ocak 2023

İlk öneri listesi şu şekildedir:

• LCP
  • LCP kaynağının HTML kaynağından bulunabilir olduğundan emin olun
  • LCP kaynağına öncelik verildiğinden emin olun
  • Doküman ve kaynak TTFB'sini optimize etmek için CDN kullanma
• CLS
  • Sayfadan yüklenen tüm içeriklerde net boyutlar ayarlama
  • Sayfaların bfcache için uygun olduğundan emin olun
  • Düzeni tetikleyen CSS özellikleri kullanan animasyonlardan ve geçişlerden kaçının
• FID
  • Uzun görevlerden kaçının veya uzun görevleri bölün
  • Gereksiz JavaScript'ten kaçının
  • Büyük oluşturma güncellemelerinden kaçının

Video özeti için bu 2023 Google I/O sunumunu da izleyebilirsiniz.