Scheduler.yield() ile tanışın: Chrome'un INP'yi Optimize Etmeye Yönelik En Yeni API'si

Google'ın 2023'te tamamen yanıt verme odaklı olduğuna şüphe yok.

Şu ana kadar:

• Etkileşim deneysel durumdan beklemede durumuna taşındı;
• Mart 2024'te yanıt verme hızına ilişkin yeni Temel Web Vital ölçümü olarak İlk Giriş Gecikmesi'nin yerini INP'nin alacağını duyurdu;
• Search Console'da INP sorunlarını işaretlemeye ve iyi yanıt verme eşiğini kaçıran web sitelerine e-posta göndermeye başladık.

Şimdi, Chrome Ekibi şu anda yeni bir zamanlayıcı API'si olan Scheduler.yield() için bir başlangıç ​​denemesi yürüttüklerini duyurdu.

Scheduler.yield()'ın geliştiricilere, kontrolü ana iş parçacığına geri vermeleri için daha kolay ve daha iyi bir yol sunarak sitelerinin yanıt verme hızını artırmalarına yardımcı olması bekleniyor.

Yeni API ve bunu web sitenizde nasıl deneyeceğiniz hakkında daha fazla bilgi edinmek için okumaya devam edin.

Uzun Görevler ve Ana Konu Üzerine Kısa Bir Özet

Uzun görevlerin ve ana konunun ne olduğunu iyi biliyorsanız, bu kısmı atlamaktan çekinmeyin. Değilse, bu kısa özeti okumanızı öneririz çünkü bu , Scheduler.yield() yöntemini ve nasıl uygulanacağını anlamak için temel önemdedir.

Tarayıcının iş olarak yaptığı her şey bir görev olarak kabul edilir. Bu, oluşturmayı, HTML ve CSS'yi ayrıştırmayı, yazdığınız JavaScript kodunu çalıştırmayı ve üzerinde doğrudan kontrol sahibi olamayacağınız diğer şeyleri içerir.

Ana iş parçacığı, tarayıcının işin çoğunu yaptığı yerdir.

Maalesef ana iş parçacığıaynı anda yalnızca bir görevi işleyebilir .Bir görevin yürütülmesi 50 ms'den uzun sürüyorsa uzun bir görev olarak kabul edilir.

Uzun bir görevle karşılaşmak, tarayıcının görevi tamamlamak için gerektiği kadar çalıştıracağı anlamına gelir. Tamamlandığında, kontrol ana iş parçacığına geri döner ve tarayıcının kuyruktaki bir sonraki görevi işlemesine olanak tanır.

Uzun görevler, tarayıcının kullanıcı girişine yanıt verme yeteneğini geciktirdiğinden, sayfa yanıt hızının zayıf olmasının ana kaynağıdır . Ayrıca, tamamlamaya kadar çalıştırma modeliyle JavaScript, ana iş parçacığının engellenmesi söz konusu olduğunda ana suçludur.

Bu nedenle, oluşturmayı engelleyen bir kaynak olarak kabul edilir; tarayıcı bununla karşılaştığında, başka bir şey yapmadan önce onu indirmeli, ayrıştırmalı ve çalıştırmalıdır.

İyi haber şu ki, kodunuzun tarayıcıda bir görevi başlatması, kontrolün ana iş parçacığına geri dönmesinden önce o görevin bitmesini beklemeniz gerektiği anlamına gelmez.

Bir görevde açıkça yer vererek uzun görevleri bölebilirsiniz.

Daha basit bir ifadeyle, görev verimi, tarayıcının tek bir göreve kapılıp diğer önemli görevlere veya kullanıcı etkileşimlerine yanıt vermeyi kaçırmamasını veya geciktirmemesini sağlar.

Ne yazık ki mevcut getiri stratejileri mükemmel değil…

Neden Scheduler.yield(): Mevcut Getiri Stratejileriyle İlgili Sorun

Ana konuya geçmek yeni bir kavram değil. Geliştiriciler uzun süredir uzun görevleri bölmek için farklı getiri stratejileri kullanıyor:

1.setTimeout()

setTimeout(), bir görevi belirli bir gecikmeden sonra veya düzenli aralıklarla çalışacak şekilde zamanlamanıza olanak tanır. Bu, zaman aşımı değerini 0 olarak belirtseniz bile geri aramanın yürütülmesini ayrı bir göreve erteler. Bu yöntem, birbiri ardına çalışması gereken birden fazla işleviniz olduğunda etkilidir.

Dezavantajı: Kesinlik garanti edilmez. Kuyruktaki diğer görevler nedeniyle geri arama, belirtilen gecikmeden tam olarak sonra çalışmayabilir. Ayrıca, çok büyük bir veri kümesini bir döngü içinde işliyorsanız, özellikle milyonlarca giriş söz konusu olduğunda bu görev zaman alıcı hale gelebilir.

2. requestIdleCallback()

requestIdleCallback(), bir görevi tarayıcının boşta kaldığı süre boyunca çalışacak şekilde zamanlamanıza olanak tanır. Kullanıcı deneyimini etkilemeden acil olmayan görevleri gerçekleştirmek için kullanışlıdır.

Dezavantajı: requestIdleCallback(), görevleri mümkün olan en düşük öncelikte zamanlar; yani ana iş parçacığı tıkalıysa, zamanlanmış görevler hiçbir zaman çalıştırılamayabilir.

3. isInputPending()

isInputPending(), bir kullanıcının sayfadaki bir öğeyle etkileşim kurmaya çalışıp çalışmadığını kontrol etmek için herhangi bir zamanda çalıştırılabilir. Eğer öyleyse, işlevtrue değerinidöndürür; değilsefalsedeğerini döndürür.

Yürütmeniz gereken bir dizi göreviniz olduğunu ancak kullanıcı etkileşimlerini kesintiye uğratmak istemediğinizi hayal edin. Kullanıcı girişinin sayfayla etkileşimde bulunurken gecikmemesini sağlamak için isInputPending() ve verimToMain() işlevini kullanabilirsiniz.

Dezavantajı: isInputPending() her zaman kullanıcı girişinden hemen sonra true değerini döndürmeyebilir. Bunun nedeni, işletim sisteminin tarayıcıya etkileşimin oluştuğunu söylemesinin zaman almasıdır. Bu, başka kodun zaten yürütülmeye başlanmış olabileceği anlamına gelir.

Bunlar ana konuya geri dönmenin popüler yollarından bazılarıdır. Gördüğünüz gibi her birinin kendine göre dezavantajları var.

Ancak en önemli dezavantajı şudur:

Kodu sonraki bir görevde çalıştırmak üzere erteleyerek ana iş parçacığına geçtiğinizde, bu kod görev kuyruğunun en sonuna eklenir.

Bu neden bir sorun?

Üç katlı bir cevap:

• Mantık hatası olasılığının artması: Ertelenen kod, görev kuyruğunun sonuna yerleştirildiğinden, ertelenen göreve geri dönmeden önce tarayıcının yürüttüğü başka görevler olabilir. Bu, işlevlerin yürütülme sırasını etkileyebilir ve potansiyel olarak mantık hatalarına veya beklenmeyen davranışlara neden olabilir.
  
• Yürütmede gecikme : Kuyrukta çok sayıda görev varsa, tarayıcının ertelenen koda ulaşıp yürütmesi önemli miktarda zaman alabilir.
  
• Öngörülemezlik: Ertelenen görevin ne zaman çalışacağını tam olarak tahmin etmek zordur çünkü bu, halihazırda kuyrukta bulunan görevlerin sayısına ve niteliğine bağlıdır. Bu öngörülemezlik, hata ayıklamayı ve performans optimizasyonunu zorlaştırabilir.

Özetle, ana iş parçacığına ulaşmak için mevcut stratejilerin kullanılması, duyarlı bir kullanıcı arayüzünün korunmasına yardımcı olabilirken, aynı zamanda kodun zamanında ve düzenli bir şekilde yürütülmesini sağlamada zorluklara da yol açabilir.

Scheduler.yield() ile tanışın

Chrome'un, Scheduler.yield() için bir başlangıç ​​denemesi çalıştırmasıyla ilgili heyecan, bunun, diğer getiri stratejilerinin tüm dezavantajlarını ele alan bir planlayıcı API'si olmasından kaynaklanmaktadır.

Üstelik bu, hem geliştiricilerin hem de sahiplerin, kodun geri kalanını sorunsuz bir şekilde çalıştırırken duyarlı web siteleri ve iyi INP puanları elde etmelerini sağlayacak bir çözümdür.

Peki, Scheduler.yield()ile ilgili tüm heyecan nedir?

Yeni başlayanlar için, Scheduler.yield() özel bir verim işlevidir. Örneğin setTimeout(), uzun görevleri bölmek ve ana iş parçacığına yol açmak için kullanılır, ancak bu, varsayılan bir seçenekten çok, bir işlevin yan etkisidir.

İkinci olarak, Scheduler.yield() kalan işi kuyruğun önüne gönderir. Bu, verim alındıktan hemen sonra devam etmek istediğiniz işin, diğer kaynaklardan gelen görevlerin gerisinde kalmayacağı anlamına gelir.

Basitçe söylemek gerekirse:

Scheduler.yield() size her iki dünyanın da en iyisini sunar; sitenizin yanıt verebilirliğini ve INP puanını iyileştirmek için verim alabilirsiniz ve sonuç verdikten sonra bitirmek istediğiniz işin gecikmediğinden emin olabilirsiniz.

Yeni Zamanlayıcı API'si Nasıl Denenir?

Chrome 115'ten başlayarak, Scheduler.yield'i kendi başınıza test edebilirsiniz.

Yeni API'yi denemek için Google'ın talimatlarını uygulamanız yeterlidir:

1. Scheduler.yield ile yerel olarak denemeler yapmak istiyorsanız Chrome'un adres çubuğuna chrome://flags yazıp girin ve Deneysel Web Platformu Özellikleri bölümündeki açılır menüden Etkinleştir'i seçin. Bu, Scheduler.yield'in (ve diğer deneysel özelliklerin) yalnızca Chrome örneğinizde kullanılabilir olmasını sağlayacaktır.
   
2. Herkese açık bir kaynakta Scheduler.yield'ı gerçek Chromium kullanıcıları için etkinleştirmek istiyorsanız, Scheduler.yield Origin denemesine kaydolmanız gerekir. Bu, belirli bir süre boyunca önerilen özellikleri güvenli bir şekilde denemenize olanak tanır ve Chrome Ekibine bu özelliklerin sahada nasıl kullanıldığına ilişkin değerli bilgiler sağlar. Köken denemelerinin nasıl çalıştığı hakkında daha fazla bilgi için bu kılavuzu okuyun.

Test ettikten sonra, nasıl geliştirilebileceğine dair geri bildirim de sağlayabilirsiniz.

Güvenli test!

NitroPack Ana Konunun Engelinin Kaldırılmasına Nasıl Yardımcı Olabilir?

Uzun görevleri daha küçük parçalara bölmek, kullanıcılara hızlı bir deneyim sunmak için çok önemlidir.

Ancak ağır JavaScript'in bir kısmını önleyici olarak optimize edebilseydiniz daha iyi olmaz mıydı?

NitroPack'in devreye girdiği yer burasıdır.

35'ten fazla gelişmiş web performansı özelliğiyle NitroPack, dünya çapında 180.000'den fazla web sitesinin mükemmel bir kullanıcı deneyimi, Önemli Web Verileri ve dönüşüm oranları elde etmesine yardımcı olur.

NitroPack'in en önemli avantajlarından biri, JavaScript yürütme biçimidir.

NitroPack kurulumunun ardından hizmetimiz, kullanıcı etkileşimi tespit edilene kadar kritik olmayan kaynakların yüklenmesini geciktirir.

Ayrıca, tescilli kaynak yükleme mekanizmamız sayesinde NitroPack, kaynakların ana iş parçacığına nasıl besleneceğini yeniden düzenleyebilir. Bunu, görevleri ana iş parçacığından uzağa aktararak modern CPU'nun çok çekirdekli yapısından yararlanmak için yapıyoruz.

Bu şekilde, ana ileti dizinizin engellenmeden kalacağını ve kullanıcı etkileşimlerini yönetmeye hazır kalacağını garanti edebiliriz.

Sitenizin yanıt verme hızını anında artırın. NitroPack'i ÜCRETSİZ edinin →