Son 20 yılda web, birkaç stil ve resim içeren statik belgelerden karmaşık, dinamik uygulamalara doğru önemli ölçüde gelişti. Ancak, bir şey büyük ölçüde değişmeden kaldı: sitelerimizi oluşturma ve JavaScript’imizi çalıştırma işini yapmak için tarayıcı sekmesi başına yalnızca bir dizimiz var (bazı istisnalar dışında).
Sonuç olarak, ana iş parçacığı inanılmaz derecede fazla çalıştı. Ve web uygulamalarının karmaşıklığı arttıkça, ana iş parçacığı performans için önemli bir darboğaz haline gelir. Daha da kötüsü, belirli bir kullanıcı için ana iş parçacığında kod çalıştırmak için geçen süre neredeyse tamamen tahmin edilemez çünkü cihaz yeteneklerinin performans üzerinde büyük etkisi vardır. Bu öngörülemezlik, yalnızca kullanıcılar web’e hiper-kısıtlı özellikli telefonlardan yüksek güçlü, yüksek yenileme hızlı amiral gemisi makinelere kadar giderek artan çeşitlilikte bir dizi cihazdan eriştikçe artacaktır.
Sofistike web uygulamalarının, insan algısı ve psikolojisi hakkındaki ampirik verilere dayanan Core Web Vitals gibi performans yönergelerini güvenilir bir şekilde karşılamasını istiyorsak, kodumuzu yürütmenin yollarına ihtiyacımız var. ana iş parçacığından (OMT).
Neden web çalışanları? #
JavaScript, varsayılan olarak, ana iş parçacığında görevleri çalıştıran tek iş parçacıklı bir dildir. Bununla birlikte, web çalışanları, geliştiricilerin ana iş parçacığından işi halletmek için ayrı iş parçacıkları döndürmesine izin vererek ana iş parçacığından bir tür kaçış yolu sağlar. Web çalışanlarının kapsamı sınırlı olsa ve DOM’a doğrudan erişim sunmasa da, aksi takdirde ana iş parçacığını bunaltacak yapılması gereken önemli işler varsa, bunlar çok faydalı olabilir.
Önemli Web Verileri söz konusu olduğunda, işi ana iş parçacığından yürütmek faydalı olabilir. Özellikle, işi ana iş parçacığından web çalışanlarına boşaltmak, ana iş parçacığı için çekişmeyi azaltabilir ve bu da Sonraki Boyama Etkileşimi (INP) ve İlk Giriş Gecikmesi (FID) gibi önemli yanıt verebilirlik ölçümlerini iyileştirebilir. Ana iş parçacığının işleyecek daha az işi olduğunda, kullanıcı etkileşimlerine daha hızlı yanıt verebilir.
Özellikle başlatma sırasında daha az ana iş parçacığı çalışması, uzun görevleri azaltarak En Büyük İçerikli Boyama (LCP) için potansiyel bir fayda da sağlar. Bir LCP öğesinin oluşturulması, ana iş parçacığı zamanı gerektirir (sık ve yaygın LCP öğeleri olan metin veya resimlerin oluşturulması için) ve genel olarak ana iş parçacığı çalışmasını azaltarak, sayfanızın LCP öğesinin, bunun yerine bir web çalışanının kaldırabileceği pahalı işlerle engellenme olasılığını azaltabilirsiniz.
Web çalışanları ile iş parçacığı oluşturma #
Diğer platformlar tipik olarak, bir iş parçacığına programınızın geri kalanıyla paralel çalışan bir işlev vermenize izin vererek paralel çalışmayı destekler. Aynı değişkenlere her iki thread’den de erişebilirsiniz ve bu paylaşımlı kaynaklara erişim mutex’ler ve semaforlar ile senkronize edilerek yarış durumlarının önüne geçilebilir.
JavaScript’te, 2007’den beri var olan ve 2012’den beri tüm büyük tarayıcılarda desteklenen web çalışanlarından kabaca benzer işlevler elde edebiliyoruz. Web çalışanları, ana iş parçacığıyla paralel olarak çalışır, ancak işletim sistemi iş parçacığından farklı olarak değişkenleri paylaşamazlar.
Bir web çalışanı oluşturmak için, bu dosyayı ayrı bir iş parçacığında çalıştırmaya başlayan çalışan oluşturucuya bir dosya iletin:
const worker = new Worker("./worker.js");
aracılığıyla mesajlar göndererek web çalışanı ile iletişim kurun. postMessage API. Mesaj değerini parametre olarak iletin. postMessage arayın ve ardından çalışana bir mesaj olay dinleyicisi ekleyin:
main.js #
const worker = new Worker("./worker.js");
worker.postMessage([40, 2]);
worker.js #
addEventListener("message", event => {
const [a, b] = event.data;
// Do stuff with the message
});
Ana konuya geri mesaj göndermek için aynısını kullanın. postMessage API’yi web çalışanına yükleyin ve ana iş parçacığında bir olay dinleyicisi ayarlayın:
main.js #
const worker = new Worker("./worker.js");
worker.postMessage([40, 2]);
worker.addEventListener("message", event => {
console.log(event.data);
});
worker.js #
addEventListener("message", event => {
const [a, b] = event.data;
// Do stuff with the message
postMessage(a+b);
});
Kuşkusuz, bu yaklaşım biraz sınırlıdır. Tarihsel olarak, web işçileri esas olarak tek bir ağır işi ana iş parçacığından çıkarmak için kullanılmıştır. Birden çok işlemi tek bir web çalışanıyla halletmeye çalışmak hızla hantal hale gelir: yalnızca parametreleri değil, aynı zamanda mesajdaki işlemi de kodlamanız ve yanıtları isteklerle eşleştirmek için defter tutmanız gerekir. Bu karmaşıklık, muhtemelen web çalışanlarının daha yaygın olarak benimsenmemesinin nedenidir.
Ancak ana iş parçacığı ile web çalışanları arasındaki iletişim güçlüğünün bir kısmını ortadan kaldırabilirsek, bu model birçok kullanım durumu için çok uygun olabilir. Ve şans eseri, tam da bunu yapan bir kitaplık var!
Comlink: web çalışanlarının daha az çalışmasını sağlıyor #
İletişim amacı, ayrıntıları düşünmek zorunda kalmadan web çalışanlarını kullanmanıza izin vermek olan bir kitaplıktır. postMessage. Comlink, neredeyse iş parçacığını destekleyen diğer programlama dilleri gibi, web çalışanları ve ana iş parçacığı arasında değişkenleri paylaşmanıza izin verir.
Comlink’i bir web çalışanına aktararak ve ana iş parçacığına maruz kalacak bir dizi işlev tanımlayarak kurarsınız. Daha sonra Comlink’i ana iş parçacığına aktarır, çalışanı sarar ve açığa çıkan işlevlere erişim elde edersiniz:
worker.js #
import {expose} from "comlink";const api = {
someMethod() { /* … */ }
}
expose(api);
main.js #
import {wrap} from "comlink";const worker = new Worker("./worker.js");
const api = wrap(worker);
bu api ana iş parçacığındaki değişken, web çalışanındakiyle aynı şekilde davranır, tek fark, her işlevin değerin kendisi yerine bir değer için söz vermesidir.
Bir web çalışanına hangi kodu taşımalısınız? #
Web çalışanlarının DOM’a ve bunun gibi birçok API’ye erişimi yoktur. WebUSB, WebRTCveya İnternet Sesi, bu nedenle, uygulamanızın bu tür erişime dayanan parçalarını bir çalışana koyamazsınız. Yine de, bir işçiye taşınan her küçük kod parçası, ana iş parçacığında daha fazla boşluk payı satın alır. sahip olmak orada olmak—kullanıcı arayüzünü güncellemek gibi.
Web geliştiricileri için bir sorun, çoğu web uygulamasının, uygulamadaki her şeyi düzenlemek için Vue veya React gibi bir UI çerçevesine güvenmesidir; her şey çerçevenin bir bileşenidir ve bu nedenle doğası gereği DOM’a bağlıdır. Bu, bir OMT mimarisine geçişi zorlaştırıyor gibi görünüyor.
Bununla birlikte, UI endişelerinin durum yönetimi gibi diğer endişelerden ayrıldığı bir modele geçersek, web çalışanları çerçeve tabanlı uygulamalarda bile oldukça yararlı olabilir. PROXX ile alınan yaklaşım tam olarak budur.
PROXX: Bir OMT vaka çalışması #
Google Chrome ekibi, PROXX’i bir Mayın Tarlası klonu olarak geliştirdi. Aşamalı Web Uygulaması çevrimdışı çalışma ve ilgi çekici bir kullanıcı deneyimi dahil olmak üzere gereksinimler. Ne yazık ki, oyunun ilk sürümleri özellikli telefonlar gibi kısıtlı cihazlarda düşük performans gösterdi ve bu da ekibin ana iş parçacığının bir darboğaz olduğunu fark etmesine yol açtı.
Ekip, oyunun görsel durumunu mantığından ayırmak için web çalışanlarını kullanmaya karar verdi:
- Ana iş parçacığı, animasyonların ve geçişlerin oluşturulmasını yönetir.
- Bir web çalışanı, tamamen hesaplamaya dayalı olan oyun mantığını yönetir.
OMT’nin PROXX özellikli telefon performansı üzerinde ilginç etkileri oldu. OMT olmayan sürümde, kullanıcı arabirimi, kullanıcı etkileşimde bulunduktan sonra altı saniye süreyle dondurulur. Geri bildirim yok ve kullanıcının başka bir şey yapabilmesi için altı saniyenin tamamını beklemesi gerekiyor.
Ancak OMT versiyonunda oyun on iki UI güncellemesini tamamlamak için saniye. Bu bir performans kaybı gibi görünse de, aslında kullanıcıya daha fazla geri bildirimde bulunulmasına yol açar. Yavaşlama, uygulamanın hiç kare göndermeyen OMT olmayan sürümden daha fazla kare göndermesinden kaynaklanır. Kullanıcı bu nedenle bir şeyler olduğunu bilir ve kullanıcı arabirimi güncellendikçe oynamaya devam edebilir, bu da oyunu önemli ölçüde daha iyi hissettirir.
Bu bilinçli bir değiş tokuştur: Kısıtlı cihazların kullanıcılarına, hissediyor ileri teknoloji cihazların kullanıcılarını cezalandırmadan daha iyi.
Bir OMT mimarisinin sonuçları #
PROXX örneğinin gösterdiği gibi OMT, uygulamanızın daha geniş bir cihaz yelpazesinde güvenilir bir şekilde çalışmasını sağlar, ancak uygulamanızı daha hızlı yapmaz:
- Sadece ana iş parçacığından işi taşıyorsunuz, işi azaltmıyorsunuz.
- Web çalışanı ile ana iş parçacığı arasındaki ek iletişim yükü bazen işleri çok az yavaşlatabilir.
Ödevleri göz önünde bulundurarak #
Ana iş parçacığı, JavaScript çalışırken kaydırma gibi kullanıcı etkileşimlerini işlemek için ücretsiz olduğundan, toplam bekleme süresi marjinal olarak daha uzun olsa da atlanan çerçeve sayısı daha azdır. Kullanıcıyı biraz bekletmek, bir çerçeveyi bırakmaktansa tercih edilir, çünkü bırakılan çerçeveler için hata payı daha küçüktür: bir çerçeveyi bırakmak milisaniyeler içinde gerçekleşir, oysa siz yüzlerce Bir kullanıcı bekleme süresini algılamadan önceki milisaniye.
Cihazlar arasındaki performansın öngörülemezliği nedeniyle, OMT mimarisinin amacı gerçekten riski azaltmak— uygulamanızı oldukça değişken çalışma zamanı koşullarında daha sağlam hale getirme — paralelleştirmenin performans avantajlarıyla ilgili değil. Dirençteki artış ve UX’teki iyileştirmeler, hızdaki herhangi bir küçük ödün vermeye değer.
Takımlama hakkında bir not #
Web çalışanları henüz ana akım değildir, bu nedenle çoğu modül aracı—örneğin Web Paketi Ve Toplama— onları kutunun dışında desteklemeyin. (Parsel Neyse ki, web çalışanları yapmak için eklentiler var. iş WebPack ve Toplama ile:
Özetliyor #
Özellikle giderek küreselleşen bir pazarda uygulamalarımızın mümkün olduğunca güvenilir ve erişilebilir olduğundan emin olmak için kısıtlı cihazları desteklememiz gerekiyor; dünya çapında çoğu kullanıcının web’e erişme şekli bunlardır. OMT, ileri teknoloji cihazların kullanıcılarını olumsuz etkilemeden bu tür cihazlarda performansı artırmanın umut verici bir yolunu sunar.
Ayrıca, OMT’nin ikincil faydaları vardır:
Web çalışanlarının korkutucu olması gerekmez. Comlink gibi araçlar, çalışanların işini alıyor ve onları çok çeşitli web uygulamaları için uygun bir seçenek haline getiriyor.
Gönderen kahraman resmi Unsplashile James tavus kuşu.