Web Sitesi Performansını ve Kritik Oluşturma Yolunu Optimize Etme

Web sayfanızın işleme performansı günümüz standartlarını karşılıyor mu? Oluşturma, bir kullanıcı bir web sitesini ziyaret ettiğinde, bir sunucunun yanıtını tarayıcının "boyadığı" resme çevirme işlemidir. Kötü bir oluşturma performansı, nispeten yüksek bir hemen çıkma oranına dönüşebilir.

Bir sayfanın oluşturulup oluşturulmayacağını belirleyen farklı sunucu yanıtları vardır. Bu makalede, HTML'nin ayrıştırılmasıyla başlayan web sayfasının ilk oluşturulmasına odaklanacağız (tarayıcının sunucu yanıtı olarak HTML'yi başarıyla alması şartıyla). Yüksek işleme sürelerine yol açabilecek şeyleri ve bunların nasıl düzeltileceğini keşfedeceğiz.

Kritik İşleme Yolu

Kritik işleme yolu (CRP), tarayıcınızın kodu ekranınızda görüntülenebilir piksellere dönüştürmek için geçtiği süreçtir. Zaman kazanmak için bazıları paralel olarak gerçekleştirilebilen birkaç aşaması vardır, ancak bazı bölümlerin sonuç olarak yapılması gerekir. İşte görselleştirildi:

Her şeyden önce, tarayıcı yanıtı aldığında, onu ayrıştırmaya başlar. Bir bağımlılıkla karşılaştığında onu indirmeye çalışır.

Bu bir stil sayfası dosyasıysa, tarayıcının sayfayı oluşturmadan önce dosyayı tamamen ayrıştırması gerekir ve bu nedenle CSS'nin oluşturma engelleme olduğu söylenir .

Bu bir komut dosyasıysa, tarayıcının şunları yapması gerekir: ayrıştırmayı durdurun, komut dosyasını indirin ve çalıştırın. JavaScript programları bir web sayfasının (özellikle HTML) içeriğini değiştirebildiğinden, ancak bundan sonra ayrıştırmaya devam edebilir. Ve bu yüzden JS'ye ayrıştırıcı engelleme denir .

Tüm ayrıştırma işlemi tamamlandıktan sonra, tarayıcıda yerleşik Belge Nesne Modeli (DOM) ve Basamaklı Stil Sayfaları Nesne Modeli (CSSOM) bulunur. Bunları birleştirmek, Render Ağacı'nı verir. Sayfanın görüntülenmeyen kısımları, yalnızca sayfayı çizmek için gerekli verileri içerdiğinden İşleme Ağacına girmez.

Sondan bir önceki adım, Render Tree'yi Layout'a çevirmektir. Bu aşama aynı zamanda Reflow olarak da adlandırılır. Her İşleme Ağacı düğümünün her konumu ve boyutunun hesaplandığı yer burasıdır.

Son olarak, son adım Paint'tir. Tarayıcının önceki aşamalarda hesapladığı verilere göre pikselleri tam anlamıyla renklendirmeyi içerir.

Optimizasyonla İlgili Sonuçlar

Tahmin edebileceğiniz gibi, web sitesi performans optimizasyonu süreci, web sitesinde aşağıdakileri azaltan değişiklikleri içerir:

• Aktarılması gereken veri miktarı
• Tarayıcının indirmesi gereken kaynak sayısı (özellikle engelleyenler)
• CRP'nin uzunluğu

Ayrıca, nasıl yapıldığının ayrıntılarına da gireceğiz, ancak önce uyulması gereken önemli bir kural var.

Performans Nasıl Ölçülür?

Optimizasyonun önemli bir kuralı şudur: Önce ölçün, gerektiği gibi optimize edin . Çoğu tarayıcının geliştirici aracının Performans adlı bir sekmesi vardır ve ölçümler burada gerçekleşir. En hızlı ilk (ilk) işleme için optimizasyon yaparken, bakılması gereken en önemli şey aşağıdaki olayların zamanıdır:

• İlk Boya
• İlk İçerikli Boya
• İlk Anlamlı Boya

Burada “Paint”, kritik oluşturma yolundaki son aşama olan bir sayfanın başarılı bir şekilde oluşturulması anlamına gelir. Tarayıcılar en kısa sürede bir şeyler görüntülemeye ve daha sonra güncellemeye çalıştığından, birkaç görüntü birbiri ardına gerçekleşebilir.

Oluşturma süresinin yanı sıra, dikkate alınması gereken başka şeyler de vardır; en önemlisi, kaç tane engelleme kaynağının kullanıldığı ve bunların indirilmesinin ne kadar sürdüğü. Bu bilgi, ölçümler yapıldıktan sonra Performans sekmesinde bulunur.

Performans Optimizasyon Stratejileri

Yukarıda öğrendiklerimize göre, web sitesi performans optimizasyonu için üç ana strateji vardır:

1. Tel üzerinden aktarılacak veri miktarının en aza indirilmesi,
2. Tel üzerinden aktarılacak toplam kaynak sayısının azaltılması ve
3. Kritik işleme yolunu kısaltma

1. Aktarılacak Veri Miktarını En Aza İndirin

Her şeyden önce, JavaScript'teki erişilemeyen işlevler, hiçbir zaman hiçbir öğeyle eşleşmeyen seçicilere sahip stiller ve CSS ile sonsuza kadar gizlenen HTML etiketleri gibi kullanılmayan tüm parçaları kaldırın. İkinci olarak, tüm kopyaları kaldırın.

Ardından, otomatik bir küçültme sürecini devreye sokmanızı öneririm. Örneğin, arka ucunuzun sunduğu tüm yorumları (ancak kaynak kodu değil) ve ek bilgi içermeyen her karakteri (JS'deki boşluk karakterleri gibi) kaldırmalıdır.

Bu yapıldıktan sonra bize kalanlar metin olarak olabilir. Bu, GZIP (çoğu tarayıcının anladığı) gibi bir sıkıştırma algoritmasını güvenle uygulayabileceğimiz anlamına gelir.

Son olarak, önbelleğe alma var. Bir tarayıcı sayfayı ilk kez oluşturduğunda yardımcı olmaz, ancak sonraki ziyaretlerde çok tasarruf sağlar. Yine de iki şeyi akılda tutmak çok önemlidir:

• Bir CDN kullanıyorsanız, önbelleğe almanın desteklendiğinden ve orada doğru şekilde ayarlandığından emin olun.
• Kaynakların sona erme tarihinin gelmesini beklemek yerine, sizin tarafınızdan daha erken güncellemenin bir yolunu bulmak isteyebilirsiniz. Yerel önbelleği geçersiz kılmak için dosyaların "parmak izlerini" URL'lerine gömün.

Tabii ki, önbelleğe alma politikaları kaynak başına tanımlanmalıdır. Bazıları nadiren değişebilir veya hiç değişmeyebilir. Diğerleri daha hızlı değişiyor. Bazıları hassas bilgiler içerirken, diğerleri herkese açık olarak kabul edilebilir. CDN'lerin özel verileri önbelleğe almasını önlemek için "özel" yönergeyi kullanın.

Web görüntülerini optimize etmek de yapılabilir, ancak görüntü istekleri ayrıştırmayı veya oluşturmayı engellemez.

2. Toplam Kritik Kaynak Sayısını Azaltın

"Kritik", yalnızca web sayfasının düzgün bir şekilde oluşturulması için gereken kaynakları ifade eder. Bu nedenle, doğrudan sürece dahil olmayan tüm stilleri atlayabiliriz. Ve tüm senaryolar da.

Stil sayfaları

Tarayıcıya belirli CSS dosyalarının gerekli olmadığını söylemek için, stil sayfalarına atıfta bulunan tüm bağlantılara media öznitelikleri ayarlamalıyız. Bu yaklaşımla, tarayıcı yalnızca geçerli media (aygıt türü, ekran boyutu) eşleşen kaynakları gerektiği gibi ele alırken, diğer tüm stil sayfalarının önceliğini düşürür (yine de işlenirler, ancak kritik oluşturma işleminin bir parçası olarak değiller). yol). Örneğin, sayfayı yazdırma stillerine başvuran style etiketine media="print" özniteliğini eklerseniz, bu stiller medya print (örn. tarayıcıda sayfa).

Süreci daha da iyileştirmek için bazı stilleri satır içi yapabilirsiniz. Bu bize, aksi takdirde stil sayfasını almak için gerekli olacak olan sunucuya en az bir gidiş dönüş kurtarır.

Kodlar

Yukarıda bahsedildiği gibi, komut dosyaları DOM ve CSSOM'yi değiştirebildikleri için ayrıştırıcı engellemedir. Bu nedenle, onları değiştirmeyen scriptler blok ayrıştırma yapmamalı , bu da bize zaman kazandırmalıdır.

Bunu uygulamak için, tüm komut dosyası etiketlerinin özniteliklerle ( async veya defer ) işaretlenmesi gerekir.

async olarak işaretlenen komut dosyaları, CSSOM oluşturulmadan önce yürütülebildikleri için DOM yapısını veya CSSOM'u engellemez. Yine de, satır içi komut dosyalarının, siz onları CSS'nin üzerine koymadığınız sürece CSSOM'u engelleyeceğini unutmayın.

Buna karşılık, defer ile işaretlenen komut dosyaları, sayfa yüklemesinin sonunda değerlendirilecektir. Bu nedenle, belgeyi etkilememelidirler (aksi takdirde yeniden oluşturmayı tetikleyecektir).

Başka bir deyişle, defer ile komut dosyası, sayfa yükleme olayı tetiklenene kadar yürütülmez, oysa async , belge ayrıştırılırken komut dosyasının arka planda çalışmasına izin verir.

3. Kritik Oluşturma Yolu Uzunluğunu Kısaltın

Son olarak, CRP uzunluğu mümkün olan minimuma kısaltılmalıdır. Kısmen, yukarıda açıklanan yaklaşımlar bunu yapacaktır.

Stil etiketleri için öznitelik olarak medya sorguları, indirilmesi gereken toplam kaynak sayısını azaltacaktır. Komut dosyası etiketi öznitelikleri defer ve zaman async , karşılık gelen komut dosyalarının ayrıştırmayı engellemesini engeller.

GZIP ile kaynakları küçültme, sıkıştırma ve arşivleme, aktarılan verilerin boyutunu küçültür (böylece veri aktarım süresini de azaltır).

Bazı stilleri ve komut dosyalarını satır içine almak, tarayıcı ile sunucu arasındaki gidiş dönüş sayısını azaltabilir.

Henüz tartışmadığımız şey, kodu dosyalar arasında yeniden düzenleme seçeneğidir. En son en iyi performans fikrine göre, bir web sitesinin en hızlı yapması gereken ilk şey ATF içeriğini görüntülemektir. ATF, ekranın üst kısmı anlamına gelir. Bu, kaydırmadan hemen görülebilen alandır. Bu nedenle, işlemeyle ilgili her şeyi, önce gerekli stiller ve komut dosyaları yüklenecek ve diğer her şey duracak şekilde yeniden düzenlemek en iyisidir - ne ayrıştırma ne de oluşturma. Ve her zaman değişikliği yapmadan önce ve sonra ölçmeyi unutmayın.

Sonuç: Optimizasyon Tüm Yığınınızı Kapsar

Özetle, web sitesi performans optimizasyonu, önbelleğe alma, CDN kurma, yeniden düzenleme, kaynak optimizasyonu ve diğerleri gibi site yanıtınızın tüm yönlerini içerir, ancak bunların tümü kademeli olarak yapılabilir. Bir web geliştiricisi olarak, bu makaleyi referans olarak kullanmalı ve her zaman deneylerinizden önce ve sonra performansı ölçmeyi unutmamalısınız.

Tarayıcı geliştiricileri, ziyaret ettiğiniz her sayfa için web sitesi performansını optimize etmek için ellerinden gelenin en iyisini yaparlar, bu nedenle tarayıcılar genellikle "ön yükleyici" denilen şeyi uygular. Programların bu bölümü, aynı anda birden çok istekte bulunmak ve bunların paralel olarak çalışmasını sağlamak için HTML'de talep ettiğiniz bir kaynağın önüne geçer. Bu nedenle, stil etiketlerini HTML'de (satır bazında) ve ayrıca komut dosyası etiketlerinde birbirine yakın tutmak daha iyidir.

Ayrıca, yalnızca DOM veya CSSOM'deki bir değişiklikle değil, aynı zamanda bir cihaz yönü değişikliği ve pencere yeniden boyutlandırmasıyla tetiklenen birden çok düzen olayını önlemek için güncellemeleri HTML'ye toplu olarak eklemeye çalışın.

Yararlı kaynaklar ve daha fazla okuma:

• Sayfa Hızı Analizleri
• Önbelleğe Alma Kontrol Listesi
• Web siteniz için GZIP'in etkinleştirilip etkinleştirilmediğini test etmenin bir yolu
• Yüksek Performanslı Tarayıcı Ağı: Ilya Grigorik'in bir kitabı