Chrome DevRel ekibinin, 2023'te Core Web Vitals performansını iyileştirmenin en etkili yollarının olduğuna inandığı en iyi uygulamalardan oluşan bir koleksiyon.
Yıllar içinde, Google'da web geliştiricilerine performansın nasıl artırılacağı konusunda birçok öneride bulunduk.
Bu önerilerin her biri ayrı ayrı birçok sitenin performansını artırabilir. Ancak önerilerin tümü oldukça boğucudur ve gerçekçidir ki tek bir kişinin veya sitenin tümünü izlemesi mümkün değildir.
Web performansı sizin günlük işiniz değilse, büyük olasılıkla hangi önerilerin siteniz üzerinde en büyük olumlu etkiye sahip olacağı belirgin değildir. Örneğin, kritik CSS'yi uygulamanın yükleme performansını iyileştirebileceğini okumuş ve resimlerinizi optimize etmenin önemli olduğunu duymuş olabilirsiniz. Ancak her iki konuda da çalışmaya 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: Kullanıcıların performanslarını iyileştirmelerine yardımcı olmak için geliştiricilere sunabileceğimiz en önemli öneriler nelerdir?
Bu soruyu uygun bir şekilde yanıtlamak için herhangi bir önerinin yalnızca teknik açıdan özelliklerini değil, geliştiricilerin bu önerileri fiilen benimseme olasılığını etkileyen insani ve kurumsal faktörleri de dikkate almalıyız. Diğer bir deyişle, bazı öneriler teoride çok etkili olabilir, ancak gerçekte bunları uygulamak için gereken zamana veya kaynağa sahip site sayısı çok azdır. Benzer şekilde, bazı öneriler kritik önem taşır ancak web sitelerinin çoğu bu uygulamaları hâlihazırda izlemektedir.
Kısacası, en iyi web performansı önerileri listemizde şunlara odaklanmak istedik:
- Gerçek dünyada en büyük etkiyi sağlayacağına inandığımız önerilerin
- Çoğu siteyle alakalı ve geçerli olan öneriler
- Çoğu geliştiricinin uygulaması için gerçekçi olan öneriler
Geçtiğimiz yıl boyunca, sunduğumuz performans önerileri grubunun tamamını denetlemek ve bunların her birini (nitel ve nicel olarak) yukarıdaki üç ölçüte göre değerlendirmek için oldukça fazla zaman harcadık.
Bu yayında, Önemli Web Verileri 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 iyi şekilde nasıl alabileceğinize karar vermeye çalışıyorsanız bu önerilerin başlangıç için en iyi yer olduğunu düşünüyoruz.
Largest Contentful Paint (LCP)
İlk önerimiz, yük performansının bir ölçümü olan Largest Contentful Paint (LCP) içindir. LCP, üç Core Web Vitals metriği içinde en fazla sayıda sitenin zorlandığı metriktir. Günümüzde web'deki tüm sitelerin yalnızca yaklaşık yarısı önerilen eşiği karşılamaktadır. Bu nedenle başlayalım.
LCP kaynağının HTML kaynağından bulunabilir olduğundan emin olma
HTTP Arşivi'nin 2022 Web Almanağı'na göre mobil sayfaların %72'sinde LCP öğesi olarak resim bulunuyor. Bu nedenle çoğu sitenin LCP'sini optimize edebilmesi için bu resimlerin hızlı bir şekilde yüklenebilmesi gerekir.
Çoğu geliştirici, bir resmi yükleme süresinin zorlukların yalnızca bir kısmı olduğunu düşünmeyebilir. Bir diğer önemli kısım ise bir resmin yüklenmeye başlamasından önce geçen süredir. HTTP Arşivi verileri ise aslında birçok sitenin bu noktada takılıp kaldığına işaret etmektedir.
Öyle ki, LCP öğesinin resim olduğu sayfaların %39'u, HTML dokümanı kaynağından bulunamayan kaynak URL'leri içeriyordu. Diğer bir deyişle, bu URL'ler standart HTML özelliklerinde (<img src="..."> veya <link rel="preload" href="..."> gibi) bulunmamıştır. Bu da tarayıcının URL'leri hızlı bir şekilde bulup hemen yüklemeye başlamasını sağlar.
Bir sayfanın, resim yüklenmeye başlamadan önce CSS veya JavaScript dosyalarının tamamen indirilmesini, ayrıştırılmasını ve işlenmesini beklemesi gerekiyorsa ç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ılmak için bazı ipuçları:
Resmi,
srcveyasrcsetözelliğine sahip bir<img>öğesi kullanarak yükleyin. Oluşturmak için JavaScript gerektirendata-srcgibi standart olmayan özellikleri kullanmayın. Bu özellikler her zaman daha yavaştır. Sayfaların %9'udata-srcarkasındaki LCP resimlerini belirsizleştiriyor.SSR, HTML kaynağında tam sayfa işaretlemenin (resim dahil) bulunduğ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.
Resminizin harici bir CSS veya JS dosyasından referans alması gerekiyorsa
<link rel="preload">etiketi aracılığıyla resminizi HTML kaynağına ekleyebilirsiniz. Satır içi stiller tarafından başvurulan resimlerin, tarayıcının ön yükleme tarayıcısı tarafından bulunamayacağını unutmayın. Bu nedenle, HTML kaynağında bulunsalar bile bu resimlerin keşfedilmesi, diğer kaynakların yüklenmesinde engellenebileceğinden önceden yükleme bu durumlarda yardımcı olabilir.
LCP görüntünüzde bulunabilirlik sorunları olup olmadığını anlamanıza yardımcı olmak için Lighthouse, 10.0 sürümünde (Ocak 2023'te beklenen) yeni bir denetim yayınlayacaktır.
LCP kaynağının HTML kaynağından bulunabilir olmasını sağlamak ölçülebilir iyileştirmeler sağlayabilir ve aynı zamanda kaynağa öncelik vermek için ek fırsatlar da sunar. Bu öneri, bir sonraki önerimizdir.
LCP kaynağına öncelik verildiğinden emin olun
LCP kaynağının HTML kaynağından bulunabilmesini sağlamak, LCP kaynağının erken yüklenmeye başlayabilmesini sağlamak için atılacak kritik bir ilk adımdır. Ancak bir diğer önemli adım da bu kaynağın yüklenmesine öncelik verilmesini ve daha az önemli başka kaynakların arkasında sıraya alınmamasını sağlamaktır.
Örneğin, LCP resminiz standart bir <img> etiketi kullanılarak HTML kaynağında mevcut olsa bile sayfanızda bu <img> etiketinden önce dokümanınızın <head> bölümünde 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ğu hakkında ipucu vermektir. Böylece tarayıcıya, ilgili komut dosyalarının tamamlanmasını beklemek yerine söz konusu dosyayı daha erken yüklemesini söyleyebilirsiniz.
Web Almanağı'na göre, uygun sayfaların yalnızca %0,03'ü bu yeni API'den yararlanıyor.Diğer bir deyişle, web'deki çoğu site çok az işlemle LCP'yi iyileştirme fırsatına sahip. fetchpriority özelliği şu anda yalnızca Chromium tabanlı tarayıcılarda desteklense de bu API, diğer tarayıcıların görmezden geldiği progresif bir geliştirmedir. Bu nedenle geliştiricilerin bu özelliği hemen kullanmasını önemle tavsiye ederiz.
Chromium harici tarayıcılar için, LCP kaynağının diğer kaynaklardan öncelikli olmasını sağlamanın tek yolu, bu kaynağa dokümanın önceki kısmında başvurmaktır. Belgenin <head> kısmında çok sayıda <script> etiketi olan bir site örneğini tekrar kullanarak LCP kaynağınıza bu komut dosyası kaynaklarından önce öncelik verilmesini sağlamak isterseniz bu komut dosyalarının herhangi birinden önce bir <link rel="preload"> etiketi ekleyebilir veya bu komut dosyalarını <body> içinde daha sonra <img> etiketinin altına taşıyabilirsiniz. Bu yöntem işe yarar ancak fetchpriority uygulamasını kullanmaktan daha az ergonomiktir. Bu yüzden diğer tarayıcıların yakında destek ekleyeceğini umuyoruz.
LCP kaynağına öncelik verilmesinin bir diğer kritik yönü de önceliğini kaybetmesine yol açan herhangi bir işlem (loading="lazy" özelliği eklemek gibi) yapmamanızdır. Günümüzde sayfaların %10'u aslında LCP resminde loading="lazy" ayarını yapıyor. Tüm resimlere dikkatsiz bir şekilde geç yükleme davranışı uygulayan resim optimizasyonu çözümlerine dikkat edin. Bu davranışı geçersiz kılma yöntemi sunuyorsa 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öntemleri kullanmayı deneyin.
Kritik olmayan kaynakları ertelemek, LCP kaynağının göreli önceliğini etkili bir şekilde artırmanın başka bir yoludur. Örneğin, kullanıcı arayüzüne güç sağlamayan komut dosyaları (analiz komut dosyaları veya sosyal widget'lar gibi), load etkinliği tetiklenene kadar güvenli bir şekilde ertelenebilir. Böylece, ağ bant genişliği için diğer kritik kaynaklarla (LCP kaynağı gibi) rekabet etmezler.
Özetlemek gerekirse, LCP kaynağının erken ve yüksek öncelikli olarak yüklenmesini sağlamak için aşağıdaki en iyi uygulamaları izlemelisiniz:
- LCP resminizin
<img>etiketinefetchpriority="high"ekleyin. LCP kaynağı bir<link rel="preload">etiketi aracılığıyla yüklenirse üzülmeyin. Bunun içinfetchpriority="high"özelliğini de ayarlayabilirsiniz. - LCP resminizin
<img>etiketinde hiçbir zamanloading="lazy"özelliğini ayarlamayın. Bu işlem, resminizin önceliğini düşürür ve 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.
Belge ve kaynak TTFB'sini optimize etmek için CDN kullanma
Önceki iki öneri, LCP kaynağınızın erken keşfedilmesini ve hemen yüklenmeye başlaması için önceliklendirilmesini sağlamaya odaklanmıştır. Bu yapbozun son aşaması, alınan ilk yanıtı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 işlem ne kadar erken olursa geri kalan her şey de o kadar erken başlamaya başlar.
Bu süre İlk Bayt Süresi (TTFB) olarak bilinir ve TTFB'yi azaltmanın en iyi yolu şöyledir:
- İçeriğinizi kullanıcılarınıza mümkün olduğunca yakın coğrafi olarak sunun
- Yakın zamanda istediğiniz içeriğin hızlı bir şekilde tekrar sunulabilmesi için ö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. Böylece bu kaynakların kablo üzerinden kullanıcılarınıza ileteceği mesafeyi sınırlar. CDN'ler genellikle sitenizin ihtiyaçlarına göre özelleştirilebilen ve optimize edilebilecek 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ş olanlar dahil olmak üzere HTML dokümanlarını da sunabilir ve önbelleğe alabilir.
Web Almanac'a göre, HTML belgesi isteklerinin yalnızca %29'u bir CDN'den sunuldu. Bu, sitelerin ek tasarruf talep etmeleri için önemli bir fırsat olduğu anlamına gelir.
CDN'lerinizi yapılandırmayla ilgili bazı ipuçları aşağıda verilmiştir:
- İçeriğin önbelleğe ne kadar süre saklanacağını artırma seçeneğini değerlendirin (örneğin, içeriğin her zaman yeni olması gerçekten kritik öneme sahip mi? Veya birkaç dakikalık eski bir içerik olabilir mi?).
- Hatta içeriği süresiz olarak önbelleğe almayı ve ardından güncelleme yaptığınızda/yaptığınızda önbelleği temizlemeyi bile düşünebilirsiniz.
- Kaynak sunucunuzda şu anda çalışan dinamik mantığı uç uca (çoğu modern CDN'nin bir özelliği) taşıyıp taşıyamayacağınızı keşfedin.
Genel olarak, içeriği doğrudan uçtan sunabiliyorsanız (kaynak sunucunuza gitmek zorunda kalmadan) bu bir performans kazancıdır. Ayrıca, kaynak sunucunuza dönüş yolculuğunu tamamlamanız gerektiği durumlarda bile CDN'ler genellikle bunu çok daha hızlı yapacak şekilde optimize edilir. Bu nedenle, bu her iki durumda da sizin için bir avantajdır.
Cumulative Layout Shift (CLS)
Bir sonraki öneri grubu, web sayfalarındaki görsel kararlılığın bir ölçüsü olan Cumulative Layout Shift (CLS) ile ilgilidir. CLS, web'de 2020'den bu yana çok gelişse de web sitelerinin yaklaşık dörtte biri hâlâ önerilen eşiği karşılamıyor. Bu nedenle birçok site için kullanıcı deneyimini iyileştirme konusunda büyük bir fırsat var.
Sayfadan yüklenen içerikler için uygunsuz boyutlar ayarlayın
Düzen kaymaları genellikle diğer içeriğin yüklenmesi bittikten sonra mevcut içerik taşındığında ortaya çıkar. Bu nedenle, bu sorunu azaltmanın birincil yöntemi, gereken her alanı mümkün olduğunca önceden ayırmaktır.
Boyutlandırılmamış resimlerden kaynaklanan düzen kaymalarını düzeltmenin en basit yolu, width ve height özelliklerini (veya eşdeğer CSS özelliklerini) açıkça ayarlamaktır. Bununla birlikte, HTTP Arşivi'ne göre sayfaların %72'sinde en az bir tane boyutlandırılmamış resim bulunuyor. Açık bir boyut olmadan, 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 belirgin bir düzen kaymasına neden olabilir. Bu durum hem toplu web için büyük bir fırsatı temsil ediyor hem de bu fırsatın, bu makalede önerilen diğer önerilerin bazılarına kıyasla çok daha az çaba gerektirdiği anlamına geliyor.
CLS'ye katkıda bulunan tek şeyin resimler olmadığını unutmamak da önemlidir. Düzen kaymaları, genellikle sayfa oluşturulduktan sonra yüklenen diğer içeriklerden (üçüncü taraf reklamları veya yerleşik videolar dahil) kaynaklanabilir. aspect-ratio özelliği bununla mücadele etmeye yardımcı olabilir. Bu, geliştiricilerin resim dışı öğelerin yanı sıra resimlere en boy oranını da açıkça sunmaları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 boyut içeren resimlerde yaptığı gibi otomatik olarak hesaplamasını sağlamanıza olanak tanır.
Dinamik içerik, doğası gereği dinamik olduğundan bazen dinamik içeriğin tam boyutunu bilmek mümkün değildir. Ancak boyutu tam olarak bilmeseniz bile düzen kaymalarının önem derecesini azaltmak için adımlar atabilirsiniz. Makul bir min-height ayarlamak, tarayıcının boş bir öğe için varsayılan 0px yüksekliğini kullanmasına izin vermekten hemen her zaman daha iyidir. min-height kullanılması, kapsayıcının gerektiğinde kapsayıcının son içerik yüksekliğine kadar büyümesine olanak tanıdığından, genellikle kolay bir düzeltme sağlayan bir çözümdür. Bu büyüme miktarı, tam miktardan ancak daha tolere edilebilir bir düzeye indirilmiştir.
Sayfaların bfcache için uygun olduğundan emin olun
Tarayıcılar, tarayıcı geçmişindeki önceki veya sonraki bir sayfayı doğrudan bellek anlık görüntüsünden 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 gerçekleşen düzen kaymalarını tamamen ortadan kaldırır. Bu, birçok site için CLS'nin büyük kısmının gerçekleştiği yerdir. Bfcache'in kullanıma sunulması, 2022'de elde ettiğimiz CLS'deki en büyük iyileşmeyi sağladı.
Buna rağmen, önemli sayıda web sitesi bfcache için uygun olmadığı için önemli sayıda gezinme karşılığında bu ücretsiz web performansı kazanma fırsatını kaçırıyorlar. Sayfanız, bellekten geri yüklenmesini istemediğiniz hassas bilgiler yüklemiyorsa, sayfalarınızın uygun olduğundan emin olmak istersiniz.
Site sahipleri, sayfalarının bfcache için uygun olup olmadığını kontrol etmeli ve uygun olmamalarının nedenleri üzerinde çalışmalıdır. Chrome'un DevTools'da bir bfcache test kullanıcısı var. Bu yıl benzer bir test gerçekleştiren yeni bir Lighthouse denetimi ve alanda bunu ölçmek için kullanılacak bir API ile buradaki araçları geliştirmeyi planlıyoruz.
bfcache'i CLS bölümüne eklemiş olsak da şimdiye kadar en büyük kazanımları gördüğümüz için bfcache genellikle diğer Core Web Vitals'ları da iyileştirecektir. Sayfa gezinmelerini önemli ölçüde iyileştirmek için kullanılabilen bir dizi anında gezinme özelliğinden biridir.
Düzene neden olan CSS özelliklerini kullanan animasyonlardan/geçişlerden kaçının
Düzen kaymalarının bir başka yaygın kaynağı da öğelerin animasyonlu olmasıdır. Örneğin, yukarıdan veya alttan içeri kayan çerez banner'ları veya diğer bildirim banner'ları genellikle CLS'ye katkıda bulunur. Bu, özellikle bu banner'lar diğer içeriği dışarı ittiğinde sorun teşkil eder. Ancak bunu yapmasalar bile animasyon eklemek CLS'yi etkileyebilir.
HTTP Arşivi verileri, animasyonları düzen kaymalarına kesin olarak bağlayamasa da veriler, düzeni etkileyebilecek CSS özelliklerini canlandıran sayfaların, genel olarak "iyi " CLS'ye sahip olma olasılığının% 15 daha düşük olduğunu göstermektedir. Bazı tesisler, diğerlerine göre daha kötü CLS değerleriyle ilişkilendirilmiş. Örneğin, margin veya border genişlikleri animasyonlu sayfaların "düşük" CLS oranı, tüm sayfaların kötü olarak değerlendirildiği orana göre neredeyse iki kat daha fazladır.
Bu, belki de çok şaşırtıcı değildir. Çünkü düzen oluşturan herhangi bir CSS mülkünde geçiş yaptığınızda veya CSS mülklerine animasyon eklediğinizde düzen kaymaları ortaya çıkar ve bu düzen kaymaları kullanıcı etkileşiminden sonraki 500 milisaniye içinde olmazsa CLS'yi etkiler.
Bazı geliştiriciler, öğenin normal belge akışının dışına çıkarıldığı durumlarda bile bu durumun geçerli olmasında şaşırabilir. Örneğin, top veya left animasyonunu gösteren, kesinlikle konumlandırılmış öğeler başka içerik itmese bile düzen kaymalarına neden olur. Ancak, top veya left canlandırması yerine transform:translateX() ya da transform:translateY() canlandırmalarını yaparsanız tarayıcının sayfa düzenini güncellemesine neden olmaz ve dolayısıyla herhangi bir düzen kayması oluşturmaz.
Tarayıcının birleştirici iş parçacığında güncellenebilen CSS özelliklerinin animasyonunu tercih etmek, uzun süredir performansla ilgili en iyi uygulamalardan biri olmuştur. Çünkü bu animasyonlar GPU'ya ve ana iş parçacığının dışına taşınmıştır. Genel performans en iyi uygulaması olmasının yanı sıra CLS'nin iyileştirilmesine de yardımcı olabilir.
Genel bir kural olarak, bir kullanıcının dokunduğu veya tuşuna bastığınızda (hover değil) hareket etmiyorsanız tarayıcının sayfa düzenini güncellemesini gerektiren CSS mülklerine animasyon eklemeyin veya geçiş yapmayın. Ayrıca, mümkün olduğunda CSS transform özelliğini kullanarak geçişleri ve animasyonları tercih edin.
Birleştirilmiş olmayan animasyonlardan kaçının Lighthouse denetimi, bir sayfada yavaş olabilecek CSS özellikleri canlandırıldığında uyarı verir.
First Input Delay (FID)
Son önerimiz ise, bir sayfanın kullanıcı etkileşimlerine duyarlılığını ölçen First Input Delay (FID) (İlk Giriş Gecikmesi) özelliğine yöneliktir. Web'deki çoğu site FID metriğinde şu anda çok iyi bir performans sergilemiş olsa da geçmişte FID metriğiyle ilgili eksiklikleri belgelemiştik ve sitelerin kullanıcı etkileşimlerine genel duyarlılıklarını iyileştirmeleri için hâlâ çok sayıda fırsat olduğuna inanıyoruz.
Yeni Sonraki Boyamayla Etkileşim (INP) metriğimiz, FID'nin yerini alabilir. Aşağıdaki önerilerin tümü, hem FID hem de INP için eşit derecede etkilidir. Sitelerin INP'de, özellikle de mobilde INP'ye göre daha kötü performans gösterdiği göz önünde bulundurulduğunda, geliştiricilerin "iyi" FID değerine sahip olsalar da bu yanıt hızı önerilerini ciddiyetle değerlendirmelerini öneririz.
Uzun görevlerden kaçınma veya bunları bölme
Görevler, tarayıcının yaptığı tek tek iş parçalarıdır. Görevler; komut dosyalarını oluşturma, düzen, ayrıştırma, derleme ve yürütme işlemlerini kapsar. Görevler uzun görevlere (50 milisaniye veya daha uzun) dönüştüğünde, ana ileti dizisinin kullanıcı girişlerine hızlı yanıt vermesi engellenir.
Web Almanağı'na göre, geliştiricilerin uzun görevlerden kaçınmak veya bunları bölmek için daha fazla şey yapabileceğine dair çok sayıda kanıt var. Uzun görevleri bölmek, bu makaledeki diğer öneriler kadar kolay olmasa da bu makalede sunulmayan diğer tekniklere kıyasla daha az çaba gerektirir.
JavaScript'te her zaman mümkün olduğunca az iş yapmaya çalışmalısınız. Ancak uzun görevleri daha küçük görevlere ayırarak ana iş parçacığına epey yardımcı olabilirsiniz. Güncellemelerin ve diğer kullanıcı etkileşimlerinin daha hızlı bir şekilde oluşturulması için, bunu genellikle ana iş parçacığına geri vererek gerçekleştirebilirsiniz.
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 sonucunu döndürürse bekleyen kullanıcı girişini işleyebilmesi için ana iş parçacığına geri dönebilirsiniz.
Scheduler API, yapılan işin kullanıcılar tarafından görülebilir mi yoksa arka planda mı olduğunu dikkate alan bir öncelik sistemine göre çalışma planlamanızı sağlayan daha gelişmiş bir yaklaşımdır.
Uzun görevleri bölerek tarayıcıya, kullanıcıların görebileceği kritik işlere (ör. etkileşimler ve sonuçta ortaya çıkan oluşturma güncellemeleri) sığması için daha fazla fırsat vermiş olursunuz.
Gereksiz JavaScript kodlarından kaçının
Bu konuda hiç şüphe yok: Web siteleri her zamankinden daha fazla JavaScript gönderiyor ve bu trend, yakın zamanda değişmiyor gibi görünüyor. Çok fazla JavaScript gönderirseniz görevlerin ana iş parçacığının dikkatini çekmek için yarıştığı bir ortam oluşturmuş olursunuz. Bu, özellikle de çok önemli başlangıç döneminde web sitenizin yanıt verme gücünü kesinlikle etkileyebilir.
Ancak bu çözülemeyecek bir sorun değil. Bu konuda bazı seçenekleriniz bulunmaktadır:
- Web sitenizin kaynaklarındaki 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 azaltarak web sitenizin kod ayrıştırma ve derleme için daha az zaman harcamasını sağlayabilir ve böylece daha sorunsuz bir ilk kullanıcı deneyimi sunabilirsiniz.
- Bazen kapsam aracını kullanırken bulduğunuz kullanılmayan kod, başlatma sırasında yürütülmediği ancak ileride bazı işlevler için yine de gerekli olacağı için "kullanılmadı" olarak işaretlenir. Bu kodu, kod bölme aracılığıyla ayrı bir pakete taşıyabilirsiniz.
- Bir etiket yöneticisi kullanıyorsanız etiketlerinizin optimize edildiğinden emin olmak için veya etiketler hâlâ kullanılıyor olsa bile belirli aralıklarla kontrol ettiğinizden emin olun. Etiket yöneticinizin JavaScript'ini daha küçük ve daha verimli hale getirmek için, kullanılmayan koda sahip eski etiketler temizlenebilir.
Büyük oluşturma güncellemelerinden kaçının
Web sitenizin duyarlılığını etkileyebilecek tek şey JavaScript değildir. Oluşturma işlemi başlı başına pahalı bir iş türü olabilir ve büyük oluşturma güncellemeleri gerçekleştiğinde web sitenizin kullanıcı girişlerine yanıt verme yeteneğini etkileyebilir.
Oluşturma işini optimize etmek kolay bir süreç değildir ve genellikle ne yapmaya çalıştığınıza bağlıdır. Yine de, oluşturma güncellemelerinizin makul olduğundan ve uzun görevlere yayılmayacağından emin olmak için yapabileceğiniz bazı şeyler vardır:
requestAnimationFrame()aracını görsel olmayan çalışmalar için 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ılması durumunda güncellemelerin oluşturulması gecikebilir.requestAnimationFrame()ile yaptığınız tüm çalışmaların yalnızca güncellemeleri oluşturmayı içeren görevlere ayrılması önemlidir.- DOM boyutunuzu küçük tutun. DOM boyutu ve düzen çalışmasının yoğunluğu birbiriyle ilişkilidir. Oluşturucu, çok büyük bir DOM için düzeni güncellemesi gerektiğinde, düzeninin yeniden hesaplanması için gereken çalışma önemli ölçüde artabilir.
- CSS kapsama özelliğini kullanın. CSS kapsama alanı, CSS
containözelliğini temel alır. Bu özellik, tarayıcıya, düzenin kapsamının izole edilmesi ve DOM'deki belirli bir köke oluşturulması dahil olmak üzere,containözelliğinin yer aldığı kapsayıcı için düzen çalışmasının nasıl yapılacağı konusunda talimatlar verir. Bu her zaman kolay bir işlem değildir, ancak karmaşık düzenler içeren alanları izole ederek, bunlar için gerekli olmayan düzen ve oluşturma işleri yapmaktan kaçınabilirsiniz.
Sonuç
Özellikle web'de dikkate alınması gereken çok sayıda yönlendirme olduğu düşünüldüğünde, sayfa performansını iyileştirmek göz korkutucu bir iş gibi görünebilir. Ancak bu önerilere odaklandığınızda soruna odaklanıp belirli bir amaç doğrultusunda yaklaşabilir ve web sitenizin Core Web Vitals metriklerini artırabilirsiniz.
Burada listelenen öneriler her ne kadar kapsamlı olmasa da web'in durumunun dikkatli bir şekilde analizini temel alarak bu önerilerin, sitelerin 2023'te Core Web Vitals performanslarını iyileştirmede en etkili yöntemler olduğuna inanıyoruz.
Burada listelenen önerilerin ötesine geçmek isterseniz, daha fazla bilgi için şu optimizasyon kılavuzlarını inceleyebilirsiniz:
Herkes için daha hızlı web'de yeni yıla merhaba deyin. Siteleriniz, en önemli konularda kullanıcılarınız için hızlı olmasını sağlayabilir.
Fotoğraf: Devin Avery