Kullanıcılar, hızlı yüklenen ve sorunsuz etkileşim sunan içeriklere sahip web deneyimleri istiyor. Bu nedenle, bir geliştirici bu iki hedefi gerçekleştirmek için çaba göstermelidir.

Performansı ve algılanan performansı iyileştirmenin nasıl olduğunu anlamak için tarayıcının nasıl çalıştığını anlamak faydalı olur.

Genel Bakış

Hızlı siteler, daha iyi kullanıcı deneyimleri sunar. Kullanıcılar, hızlı bir şekilde yüklenen ve sorunsuz etkileşim sağlayan içeriğe sahip web deneyimleri istiyor ve bekliyor.

Web performansındaki iki temel sorun, gecikme ile ilgili sorunlar ve tarayıcıların büyük çoğunluğunun tek iş parçacıklı (single-threaded) olmasıyla ilgili sorunlardır.

Gecikme, hızlı yüklenen bir sayfa sağlama yeteneğimizi en çok tehdit eden unsurdur. Geliştiricilerin amacı, siteyi mümkün olduğunca hızlı bir şekilde yüklemek veya en azından hızlı yükleniyor gibi göstermek, böylece kullanıcının istenen bilgilere mümkün olan en kısa sürede ulaşmasını sağlamaktır. Ağ gecikmesi, verilerin kablosuz olarak bilgisayarlara iletilmesi için harcanan süredir. Web performansı, sayfanın mümkün olan en hızlı şekilde yüklenmesi için yapmamız gereken işlemleri ifade eder.

Büyük çoğunlukla, tarayıcılar tek iş parçacıklı olarak kabul edilir. Yani, bir görevi baştan sona kadar tamamlamadan diğer bir göreve geçmezler. Sorunsuz etkileşimler için, geliştiricinin amacı, akıcı kaydırmadan dokunmaya duyarlı olmaya kadar, performanslı site etkileşimlerini sağlamaktır. Render süresi önemlidir ve ana iş parçacığının tüm atılan işleri tamamlayabilmesini ve her zaman kullanıcı etkileşimlerini yönetmek için kullanılabilir olmasını sağlamak önemlidir. Web performansı, tarayıcının tek iş parçacıklı yapısını anlayarak ve uygun olduğunda ana iş parçacığının sorumluluklarını mümkün olduğunca azaltarak, renderlemenin akıcı olmasını ve etkileşimlere hızlı yanıt verilmesini sağlayarak iyileştirilebilir.

Navigasyon

Navigasyon, bir web sayfasının yüklenmesinin ilk adımıdır. Kullanıcı bir URL’yi adres çubuğuna girerek, bir bağlantıya tıklayarak, bir formu göndererek veya diğer eylemleri gerçekleştirerek bir sayfa istediğinde gerçekleşir.

Web performansının hedeflerinden biri, bir navigasyonun tamamlanması için harcanan süreyi en aza indirmektir. İdeal koşullarda, bu genellikle çok uzun sürmez, ancak gecikme ve bant genişliği gecikmelere neden olabilen düşmanlardır.

DNS Sorgulama

Bir web sayfasına yönlendirilirken ilk adım, sayfanın varlıklarının nerede bulunduğunu bulmaktır. Örneğin, https://ornek.com yönlendirirseniz, HTML sayfası 93.184.216.34 IP adresine sahip sunucuda bulunur. Bu siteyi daha önce ziyaret etmediyseniz, bir DNS sorgulaması gerçekleşmelidir.

Tarayıcınız bir DNS sorgulaması yapar, bu sorgulama nihayetinde bir isim sunucusu tarafından karşılanır ve bir IP adresiyle yanıt verir. Bu ilk isteğin ardından IP adresi muhtemelen bir süre boyunca önbelleğe alınır, bu da IP adresini tekrar bir isim sunucusuna başvurmak yerine önbellekten alarak sonraki istekleri hızlandırır.

DNS sorgulamaları genellikle sayfa yüklenmesi için bir hostname için bir kez yapılır. Ancak, istenen sayfanın başvurduğu her benzersiz hostname için DNS sorgulaması yapılması gerekmektedir. Yazı tipleriniz, resimleriniz, betikleriniz, reklamlarınız ve metrikleriniz farklı hostname’lere sahipse, her biri için bir DNS sorgulaması yapılması gerekecektir.

Bu durum, özellikle mobil ağlarda performans açısından sorun oluşturabilir. Bir kullanıcı mobil bir ağda olduğunda, her DNS sorgulamasının telefon, baz istasyonu ve yetkili bir DNS sunucusuna ulaşmak için hücresel kule üzerinden gitmesi gerekir. Telefon, baz istasyonu ve isim sunucusu arasındaki mesafe önemli bir gecikme ekleyebilir.

TCP El Sıkışması

IP adresi belirlendikten sonra, tarayıcı TCP üç yönlü bir el sıkışma (handshake) kullanarak sunucuyla bağlantı kurar. Bu mekanizma, iletişim kurmaya çalışan iki tarafın -bu durumda tarayıcı ve web sunucusu- veri iletiminden önce ağ TCP soketi bağlantısının parametrelerini müzakere edebilmeleri için tasarlanmıştır, genellikle HTTPS üzerinden.

TCP’nin üç yönlü el sıkışma tekniği genellikle “SYN-SYN-ACK” veya daha doğru bir şekilde “SYN, SYN-ACK, ACK” olarak adlandırılır çünkü TCP tarafından iki bilgisayar arasında bir TCP oturumunu müzakere etmek ve başlatmak için üç mesaj iletimi gerçekleştirilir. Evet, bu, her sunucu arasında üç mesaj daha alışverişi yapılacağı anlamına gelir ve istek henüz yapılmamıştır.

TLS Müzakeresi

HTTPS üzerinden kurulan güvenli bağlantılar için başka bir “el sıkışma” gereklidir. Bu el sıkışma, ya da daha doğru bir ifadeyle TLS müzakeresi, iletişimi şifrelemek için hangi şifreleme yönteminin kullanılacağını belirler, sunucuyu doğrular ve veri aktarımına başlamadan önce güvenli bir bağlantının kurulduğunu sağlar. Bu, içeriğin isteği gerçekten gönderilmeden önce sunucuyla üç ekstra tur daha yapılmasını gerektirir.

Bağlantıyı güvence altına almak, sayfa yüklenmesine zaman eklerken, tarayıcı ve web sunucusu arasında iletilen verilerin üçüncü bir tarafça deşifre edilememesi için güvenli bir bağlantı sağlamak, gecikme maliyetine değer.

8 tur dönüşün ardından, tarayıcı nihayet isteği gerçekleştirebilir.

Yanıt

Bir web sunucusuna kurulan bağlantıdan sonra, tarayıcı kullanıcı adına başlangıçta genellikle bir HTML dosyası olan bir HTTP GET isteği gönderir. Sunucu isteği aldıktan sonra ilgili yanıt başlıkları ve HTML içeriği ile yanıt verir.

<!DOCTYPE html>
<html lang="en-US">
  <head>
    <meta charset="UTF-8" />
    <title>My simple page</title>
    <link rel="stylesheet" href="styles.css" />
    <script src="myscript.js"></script>
  </head>
  <body>
    <h1 class="heading">My Page</h1>
    <p>A paragraph with a <a href="https://example.com/about">link</a></p>
    <div>
      <img src="myimage.jpg" alt="image description" />
    </div>
    <script src="anotherscript.js"></script>
  </body>
</html>

Bu ilk istek için gelen yanıt, alınan verilerin ilk baytını içerir. İlk Bayt Zamanı (TTFB), kullanıcının isteği yapma zamanı -örneğin bir bağlantıya tıklayarak- ve bu ilk HTML paketinin alınması arasındaki süreyi ifade eder. İlk içerik parçası genellikle 14KB veri içerir.

Yukarıdaki örneğimizde, istek kesinlikle 14KB’dan daha azdır, ancak bağlantılı kaynaklar, tarayıcı aşağıda açıklanan ayrıştırma sırasında bağlantıları karşılaştığında istenmez.

TCP Yavaş Başlatma / 14KB Kuralı

İlk yanıt paketi 14KB olacaktır. Bu, ağ bağlantısının hızını dengeleyen bir algoritma olan TCP yavaş başlatma (slow start) kısmının bir parçasıdır. Yavaş başlatma, ağın maksimum bant genişliği belirlenebilene kadar iletilen veri miktarını giderek artırır.

TCP yavaş başlatma sırasında, ilk paketin alınmasından sonra, sunucu bir sonraki paketin boyutunu yaklaşık 28KB’ye kadar iki katına çıkarır. Ardışık paketler, belirlenmiş bir eşik değeri veya tıkanıklık yaşanana kadar boyut olarak artar.

Eğer daha önce ilk sayfa yüklemesi için 14KB kuralını duymuşsanız, TCP yavaş başlatma, ilk yanıtın neden 14KB olduğu ve web performans optimizasyonunun bu ilk 14KB yanıt üzerinde odaklanmayı gerektirdiği nedenleridir. TCP yavaş başlatma, tıkanıklığı önlemek için ağın kapasitesine uygun iletim hızını aşamalı olarak oluşturur.

Tıkanıklık Kontrolü

Sunucu TCP paketleriyle veri gönderdiğinde, kullanıcının istemcisi bu iletimin doğrulamasını geri dönerek ACK (acknowledgement) mesajları ile yapar. Bağlantının, donanım ve ağ koşullarına bağlı olarak sınırlı bir kapasitesi vardır. Eğer sunucu çok hızlı bir şekilde çok fazla paket gönderirse, paketler düşürülür ve bir doğrulama (acknowledgement) alınmaz. Sunucu bu durumu eksik ACK’ler olarak kaydeder. Tıkanıklık kontrol algoritmaları, gönderilen paketlerin ve ACK’lerin akışını kullanarak bir gönderim hızı belirler.

Ayrıştırma

Tarayıcı ilk veri parçasını aldıktan sonra, aldığı bilgileri ayrıştırmaya başlayabilir. Ayrıştırma, tarayıcının ağ üzerinden aldığı verileri DOM (Belge Nesnesi Modeli) ve CSSOM’a dönüştürmek için yaptığı adımdır. Bu dönüştürme işlemi, renderlayıcı tarafından sayfayı ekrana çizmek için kullanılır.

DOM, tarayıcı için işaretleme dilinin dahili temsilidir. DOM aynı zamanda dışarıya açıktır ve JavaScript’teki çeşitli API’ler aracılığıyla manipüle edilebilir.

İstenen sayfanın HTML’i, başlangıçtaki 14KB paketten daha büyük olsa bile, tarayıcı aldığı verilere dayanarak ayrıştırmaya ve bir deneyim oluşturmaya başlar. Bu nedenle, tarayıcının bir sayfayı renderlamaya başlamak için gereken her şeyin veya en azından bir sayfa şablonunun – ilk render için gereken CSS ve HTML’in – ilk 14 kilobaytte bulunması web performans optimizasyonu için önemlidir. Ancak ekrana bir şey çizilmeden önce, HTML, CSS ve JavaScript ayrıştırılmalıdır.

DOM Ağacının Oluşturulması

Kritik render yolunda beş adım tanımlarız.

İlk adım, HTML işaretlemesinin işlenmesi ve DOM ağacının oluşturulmasıdır. HTML ayrıştırma işlemi, belirteçleme ve ağaç oluşturmayı içerir. HTML belirteçleri, başlangıç ve bitiş etiketlerini, ayrıca öznitelik adlarını ve değerlerini içerir. Belge düzgün biçimlendirilmişse, ayrıştırma işlemi basit ve daha hızlıdır. Ayrıştırıcı, belirteçlendirilmiş girdiyi belgeye dönüştürerek, belge ağacını oluşturur.

DOM ağacı, belgenin içeriğini tanımlar. <html> etiketi, belge ağacının ilk etiketi ve kök düğümüdür. Ağaç, farklı etiketler arasındaki ilişkileri ve hiyerarşileri yansıtır. Başka etiketlerin içine yerleştirilen etiketler, çocuk düğümlerdir. DOM düğüm sayısı ne kadar fazlaysa, DOM ağacının oluşturulması o kadar uzun sürer.

Ayrıştırıcı, bir görüntü gibi engellemeyen kaynakları bulduğunda, tarayıcı bu kaynakları isteyip ayrıştırmaya devam eder. CSS dosyasıyla karşılaşıldığında ayrıştırma devam edebilir, ancak <script> etiketleri – özellikle async veya defer niteliği olmayanlar – renderlamayı engeller ve HTML ayrıştırmasını duraklatır. Tarayıcının ön yükleme tarayıcısı bu süreci hızlandırsa da, aşırı sayıda script hala önemli bir darboğaz olabilir.

Ön Yükleme Tarayıcısı

Tarayıcı DOM ağacını oluştururken, bu işlem ana iş parçacığını işgal eder. Bu sırada, ön yükleme tarayıcısı mevcut içeriği tarayarak CSS, JavaScript ve web fontları gibi yüksek öncelikli kaynakları isteyebilir. Ön yükleme tarayıcısı sayesinde, harici bir kaynağa atıfta bulunulana kadar beklememiz gerekmez. Kaynakları arka planda alır, böylece ana HTML ayrıştırıcısı istenen varlıklara ulaştığında, bu kaynaklar zaten yolda olabilir veya indirilmiş olabilir. Ön yükleme tarayıcısı sağladığı optimizasyonlar, tıkanıklıkları azaltır.

<link rel="stylesheet" href="styles.css" />
<script src="myscript.js" async></script>
<img src="myimage.jpg" alt="image description" />
<script src="anotherscript.js" async></script>

Bu örnekte, ana iş parçacığı HTML ve CSS’yi ayrıştırırken, ön yükleme tarayıcısı script ve görüntüyü bulacak ve onları indirmeye başlayacaktır. Script’in süreci engellemediğinden emin olmak için async niteliğini ekleyin veya JavaScript’in ayrıştırma ve yürütme sırası önemliyse defer niteliğini ekleyin.

CSS beklemek, HTML ayrıştırmasını veya indirmeyi engellemez, ancak JavaScript’i engeller çünkü JavaScript genellikle CSS özelliklerinin öğeler üzerindeki etkisini sorgulamak için kullanılır.

CSSOM Oluşturma

Kritik renderleme yolundaki ikinci adım, CSS’nin işlenmesi ve CSSOM ağacının oluşturulmasıdır. CSS nesne modeli, DOM’a benzer. DOM ve CSSOM ikisi de ağaçlardır. Bağımsız veri yapılarıdır. Tarayıcı, CSS kurallarını anlayabileceği ve çalışabileceği bir stil haritasına dönüştürür. Tarayıcı, CSS’deki her kural kümesini geçer ve CSS seçicilere dayalı olarak ebeveyn, çocuk ve kardeş ilişkilerine sahip düğümlerin bir ağacını oluşturur.

HTML gibi, tarayıcının aldığı CSS kurallarını kullanabileceği bir şeye dönüştürmesi gerekiyor. Bu nedenle, HTML’de olduğu gibi, CSS için de HTML-nesne işlemi tekrarlanır.

CSSOM ağacı, kullanıcı ajanı stil sayfasındaki stilleri içerir. Tarayıcı, bir düğüme uygulanabilen en genel kural ile başlar ve daha spesifik kurallar uygulayarak hesaplanmış stilleri recursive olarak iyileştirir. Başka bir deyişle, özellik değerlerini kademeli olarak uygular.

CSSOM oluşturmak çok çok hızlıdır ve mevcut geliştirici araçlarında benzersiz bir renkte görüntülenmez. Geliştirici araçlarda “Stili Yeniden Hesapla” toplamda CSS’i ayrıştırma, CSSOM ağacını oluşturma ve hesaplanmış stilleri recursive olarak hesaplama süresini gösterir. Web performans optimizasyonu açısından, bir DNS sorgusunun alınmasından daha az sürede CSSOM oluşturulur.

Diğer Süreçler

JavaScript Derleme

CSS ayrıştırılırken ve CSSOM oluşturulurken, preload tarayıcının diğer kaynakları, JavaScript dosyalarını da içeren, indirir. JavaScript yorumlanır, derlenir, ayrıştırılır ve yürütülür. Betikler soyut sözdizim ağaçlarına ayrıştırılır. Bazı tarayıcı motorları Soyut Sözdizim Ağacını bir yorumlayıcıya aktararak, baytlara dönüştürüp ana iş parçacığında yürütülmesini sağlar. Buna JavaScript derlemesi denir.

Erişilebilirlik Ağacının Oluşturulması

Tarayıcı ayrıca, yardımcı cihazların içeriği çözümlemek ve yorumlamak için kullandığı bir erişilebilirlik ağacı oluşturur. Erişilebilirlik nesne modeli (AOM), DOM’un semantik bir versiyonu gibidir. Tarayıcı, DOM güncellendiğinde erişilebilirlik ağacını da günceller. Erişilebilirlik ağacı, yardımcı teknolojiler tarafından değiştirilemez.

Erişilebilirlik ağacı oluşturulana kadar içerik ekran okuyucuları tarafından erişilemez.

Görüntüleme

Görüntüleme adımları stil, düzen, boyama ve bazı durumlarda kompozisyonu içerir. Ayrıştırma adımında oluşturulan CSSOM ve DOM ağaçları, birleştirilerek render ağacı oluşturulur. Bu render ağacı, her görünür öğenin düzenini hesaplamak için kullanılır ve ardından ekrana boyanır. Bazı durumlarda, içerik kendi katmanlarına terfi ettirilerek ve kompozit yapılır, böylece ekranın bazı bölümleri CPU yerine GPU üzerinde boyanır ve ana iş parçacığı serbest bırakılır.

Stil

Kritik render yolundaki üçüncü adım, DOM ve CSSOM’u birleştirerek render ağacını oluşturmaktır. Hesaplanmış stil ağacı veya render ağacı, DOM ağacının kökünden başlayarak her görünür düğümü dolaşarak oluşturulur.<head> ve çocukları gibi görüntülenmeyecek etiketler ve kullanıcı arayüzü stillerinde bulunan display: none gibi düğümler render ağacına dahil edilmez çünkü render çıktısında görünmeyecektir. visibility: hidden uygulanmış düğümler, alan kapladıkları için render ağacında yer alır. Yukarıdaki örnek kodumuzda kullanıcı arayüzü varsayılanını geçersiz kılmak için herhangi bir yönerge vermediğimiz için script düğümü render ağacına dahil edilmeyecektir.

Her görünür düğümün CSSOM kuralları ona uygulanır. Render ağacı, içeriği olan ve hesaplanmış stilleri içeren tüm görünür düğmeleri tutar – DOM ağacındaki her görünür düğmeyle ilgili tüm ilgili stilleri eşleştirir ve CSS kaskadına dayanarak her düğüm için hesaplanmış stilleri belirler.

Düzen

Kritik render yolundaki dördüncü adım, render ağacında düzeni çalıştırarak her düğümün geometrisini hesaplamaktır. Düzen, render ağacındaki tüm düğümlerin genişlik, yükseklik ve konumunu belirleme işlemidir, ayrıca sayfadaki her nesnenin boyutunu ve konumunu belirler. Reflow, sayfanın herhangi bir bölümünün veya tüm belgenin daha sonraki boyut ve konum belirlemesidir.

Render ağacı oluşturulduktan sonra düzenleme işlemi başlar. Render ağacı, hangi düğümlerin görüntülendiğini (görünmez olsalar bile) ve hesaplanmış stillerini belirler, ancak her düğümün boyutunu veya konumunu belirlemez. Her nesnenin tam boyutunu ve konumunu belirlemek için tarayıcı, render ağacının kökünden başlayarak onu dolaşır.

Web sayfasında neredeyse her şey bir kutudur. Farklı cihazlar ve farklı masaüstü tercihleri, sınırsız sayıda farklı görünüm boyutu anlamına gelir. Bu aşamada, görünüm boyutunu dikkate alarak tarayıcı, farklı kutuların ekran üzerinde nasıl boyutlandırılacağını belirler. Görünüm alanını temel alarak düzenleme genellikle body ile başlar, tüm body’nin alt öğelerinin boyutlarını düzenler ve her öğenin kutu modeli özellikleri ile bilinmeyen boyutlara sahip yerine geçen öğelere yer tutucu alan sağlar, örneğin resmimiz gibi.

Düğümlerin boyutu ve konumu ilk kez belirlendiğinde buna düzenleme denir. Daha sonraki düğüm boyutu ve konumu hesaplamalarına ise reflow denir. Örneğimizde, resmin döndürülmesinden önce ilk düzenleme gerçekleştiğini varsayalım. Resmin boyutunu belirtmediğimiz için, resmin boyutu bilindiğinde bir reflow olacaktır.

Boyama

Kritik render yolundaki son adım, bireysel düğümleri ekrana boyamaktır ve bunun ilk meşru boyaması olarak adlandırılır. Boyama veya rastgeleştirme aşamasında, tarayıcı düzenleme aşamasında hesaplanan her kutuyu gerçek piksellere dönüştürür. Boyama, her elementin ekrana metin, renkler, kenarlıklar, gölgeler ve düğmeler ve resimler gibi yerine geçen öğeler gibi her görsel kısmını çizmeyi içerir. Tarayıcının bunu son derece hızlı bir şekilde yapması gerekmektedir.

üzere ana iş parçacığını kullanan her şeyin tarayıcıya 16.67 ms’den daha az sürede tamamlanması gerekmektedir. 2048 x 1536 piksel çözünürlüğe sahip bir iPad’in ekrana çizilmesi gereken 3.145.000’den fazla piksel bulunmaktadır. Bu çok hızlı bir şekilde boyanması gereken çok sayıda piksel demektir. İlk boyamadan daha hızlı bir şekilde yeniden boyama yapılabilmesini sağlamak için, ekran üzerine çizim genellikle birkaç katmana ayrılır. Bu durum gerçekleşirse, kompozisyon gereklidir.

Boyama, düzen ağacındaki öğeleri katmanlara bölebilir. İçeriği GPU’da (CPU’daki ana iş parçacığı yerine) katmanlara taşımak, boyama ve yeniden boyama performansını artırır. Katmanı oluşturan belirli özellikler ve öğeler vardır, bunlar arasında <video> ve <canvas> etiketleri ile opacity, 3D dönüşüm, will-change gibi CSS özelliklerine sahip olanlar bulunur. Bu düğümler, yukarıda belirtilen nedenlerden biri (veya daha fazlası) için bir alt öğeye ait kendi katmanına sahip olmadıkça, kendi katmanlarına ait olan alt öğeleriyle birlikte kendi katmanlarına boyanır.

Katmanlar performansı artırırken, bellek yönetimi açısından maliyetlidir, bu nedenle web performans optimizasyon stratejilerinin bir parçası olarak aşırı kullanılmamalıdır.

Kompozisyon

Belgenin farklı katmanlarda çizilen ve birbirinin üzerine binen bölümleri olduğunda, bunların doğru sırayla ekrana çizilmesini ve içeriğin doğru şekilde render edilmesini sağlamak için kompozisyon gereklidir.

Sayfa varlıkları yüklenmeye devam ettikçe, reflowlar meydana gelebilir (geç gelen örnek görüntümüzü hatırlayın). Bir reflow, bir yeniden boyama ve bir yeniden kompozisyonu tetikler. Eğer görüntümüzün boyutunu belirtseydik, reflow gerekli olmazdı ve sadece yeniden boyanması gereken katman yeniden boyanır ve gerektiğinde kompozitlenirdi. Ancak görüntü boyutunu belirtmedik! Görüntü sunucudan alındığında, renderleme süreci tekrar düzenleme adımlarına döner ve oradan yeniden başlar.

Etkileşim

Ana iş parçacığı sayfayı boyadıktan sonra, “her şey hazır” olduğunu düşünebilirsiniz. Ancak durum her zaman böyle değildir. Eğer yük, doğru bir şekilde ertelenmiş ve onload olayı tetiklendikten sonra yürütülen JavaScript içeriyorsa, ana iş parçacığı meşgul olabilir ve kaydırma, dokunma ve diğer etkileşimler için kullanılabilir olmayabilir.

Etkileşimli hale gelme süresi (Time to Interactive, TTI), DNS araması ve SSL bağlantısına yol açan ilk istekten, sayfanın etkileşimli hale gelmesine kadar geçen süreyi ölçer. Etkileşimli hale gelme, İlk Anlamlı Boyama (First Contentful Paint) sonrasında sayfanın kullanıcı etkileşimlerine 50ms içinde yanıt verdiği noktadır. Eğer ana iş parçacığı, JavaScript’i ayrıştırma, derleme ve yürütme işlemleriyle meşgulse, uygun bir şekilde kullanılamaz ve dolayısıyla kullanıcı etkileşimlerine zamanında (50ms’den daha az bir sürede) yanıt veremez.

Örneğimizde, görüntü hızlı bir şekilde yüklendi, ancak belki de anotherscript.js dosyası 2MB boyutunda ve kullanıcının ağ bağlantısı yavaş. Bu durumda kullanıcı sayfayı süper hızlı bir şekilde görebilir, ancak betik indirilene, ayrıştırılana ve yürütülene kadar akıcı bir şekilde kaydırma yapamaz. Bu iyi bir kullanıcı deneyimi değildir. Bu WebPageTest örneğinde gösterildiği gibi, ana iş parçacığını meşgul etmekten kaçının.

Bu örnekte, JavaScript yürütmesi 1.5 saniyeden daha uzun sürdü ve ana iş parçacığı bu süre boyunca tamamen meşguldü, tıklama olaylarına veya ekran dokunuşlarına yanıt vermedi.