CSS'yi Yeniden Düzenleme: Boyut ve Performansı Optimize Etme (Bölüm 3)

Bu serideki önceki makalelerde, CSS kod tabanı sağlığının denetlenmesini ve artan CSS yeniden düzenleme stratejisini, test edilmesini ve bakımını ele aldık. Yeniden düzenleme işlemi sırasında CSS kod tabanının ne kadar geliştirildiğine ve ne kadar daha sürdürülebilir ve genişletilebilir olduğuna bakılmaksızın, nihai stil sayfasının mümkün olan en iyi performans ve mümkün olan en az dosya boyutu için optimize edilmesi gerekir .

Yeniden düzenlenmiş kod tabanını dağıtmak, daha kötü web sitesi performansına ve daha kötü kullanıcı deneyimine neden olmamalıdır. Sonuçta, kullanıcılar web sitesinin yüklenmesi için sonsuza kadar beklemeyecekler. Ayrıca yönetim, kod kalitesi iyileştirmelerine rağmen optimize edilmemiş kod tabanının neden olduğu azalan trafik ve gelirden memnun olmayacaktır.

Bu makalede, CSS dosya boyutunu, yükleme sürelerini ve işleme performansını optimize edebilen CSS optimizasyon stratejilerini ele alacağız. Bu şekilde, yeniden düzenlenmiş CSS kod tabanı yalnızca daha sürdürülebilir ve genişletilebilir olmakla kalmaz, aynı zamanda performans gösterir ve hem son kullanıcı hem de yönetim için önemli olan tüm kutuları kontrol eder.

Stil Sayfası Dosya Boyutunu Optimize Etme

Dosya boyutunu optimize etmek, gereksiz karakterleri kaldırmak ve bir dosyadaki toplam karakter sayısını azaltmak için CSS kodunu farklı sözdizimi veya steno özelliklerini kullanacak şekilde biçimlendirmek ve optimize etmekle başlar.

Optimizasyon ve Minifikasyon

CSS optimizasyonu ve küçültme , yıllardır var ve ön uç optimizasyonunda temel bir unsur haline geldi. CSS optimizasyonu ve küçültme söz konusu olduğunda cssnano ve clean-css gibi araçlar en sevdiğim araçlar arasındadır. Kodun nasıl optimize edildiğini ve hangi tarayıcıların desteklendiğini daha fazla kontrol etmek için çok çeşitli özelleştirme seçenekleri sunarlar.

Bu araçlar benzer şekilde çalışır. İlk olarak, optimize edilmemiş kod, yapılandırmada belirlenen kurallar izlenerek ayrıştırılır ve aktarılır. Sonuç, daha az karakter kullanan ancak yine de biçimlendirmeyi koruyan koddur (satır sonları ve boşluklar).

 /* Before - original and unoptimized code */ .container { padding: 24px 16px 24px 16px; background: #222222; } /* After - optimized code with formatting */ .container { padding: 24px 16px; background: #222; }

Ve son olarak, aktarılan optimize edilmiş kod, tüm gereksiz metin biçimlendirmeleri kaldırılarak küçültülür . Yapılandırmada ayarlanan kod tabanına ve desteklenen tarayıcılara bağlı olarak, kullanımdan kaldırılmış satıcı öneklerine sahip kodlar da kaldırılabilir.

 /* Before - optimized code with formatting */ .container { padding: 24px 16px; background: #222; } /* After - optimized and minified code */ .container{padding:24px 16px;background:#222}

Bu temel örnekte bile, toplam dosya boyutunu 76 bayttan 55 bayta düşürmeyi başardık ve bu da %23'lük bir azalma sağladı. Kod tabanına ve optimizasyon araçlarına ve yapılandırmaya bağlı olarak, CSS optimizasyonu ve küçültme daha da etkili olabilir.

CSS optimizasyonu ve küçültme, CSS iş akışında sadece birkaç ince ayar ile önemli getirisi nedeniyle kolay bir kazanç olarak kabul edilebilir. Bu nedenle küçültme, minimum performans optimizasyonu ve projedeki tüm stil sayfaları için bir gereklilik olarak ele alınmalıdır.

Medya Sorgularını Optimize Etme

CSS'de medya sorguları yazarken, özellikle birden fazla dosya (PostCSS veya Sass) kullanırken, kodu genellikle tüm proje için tek bir medya sorgusu altına yerleştirmeyiz. İyileştirilmiş sürdürülebilirlik, modülerlik ve kod yapısı için, genellikle birden çok CSS bileşeni için aynı ortam sorgu ifadelerini yazıyoruz.

Aşağıdaki optimize edilmemiş CSS kod tabanı örneğini ele alalım.

 .page { display: grid; grid-gap: 16px; } @media (min-width: 768px) { .page { grid-template-columns: 268px auto; grid-gap: 24px; } } /* ... */ .products-grid { display: grid; grid-template-columns: repeat(2, 1fr); grid-gap: 16px; } @media (min-width: 768px) { .products-grid { grid-template-columns: repeat(3, 1fr); grid-gap: 20px; } }

Gördüğünüz gibi, daha iyi okunabilirlik ve bakım için bileşen başına tekrarlanan @media (min-width: 768px) . Bu kod örneğinde optimizasyon ve küçültmeyi çalıştıralım ve ne elde ettiğimizi görelim.

 .page{display:grid;grid-gap:16px}@media (min-width: 768px){.page{grid-template-columns:268px auto;grid-gap:24px}}.products-grid{display:grid;grid-template-columns:repeat(2,1fr);grid-gap:16px}@media (min-width: 768px){.products-grid{grid-template-columns:repeat(3,1fr);grid-gap:20px}}

Bunu okumak biraz zor olabilir, ancak tek fark etmemiz gereken, tekrarlanan @media (min-width: 768px) medya sorgusu. Bir stil sayfasındaki karakter sayısını azaltmak istediğimize ve birden çok seçiciyi tek bir medya sorgusu altına yerleştirebileceğimize zaten karar verdik, öyleyse küçültücü neden kopyalanan ifadeyi kaldırmadı? Bunun basit bir nedeni var.

CSS'de kural sırası önemlidir, bu nedenle çoğaltılan medya sorgularını birleştirmek için kod bloklarının taşınması gerekir. Bu, stillerde istenmeyen yan etkilere neden olabilecek kural sıralarının değiştirilmesine neden olacaktır.

Ancak, ortam sorgularını birleştirmek, kod tabanına ve yapıya bağlı olarak dosya boyutunu potansiyel olarak daha da küçültebilir. postcss-sort-media-queries gibi araçlar ve paketler, yinelenen medya sorgularını kaldırmamıza ve dosya boyutunu daha da küçültmemize olanak tanır.

Elbette, kural sırasına bağlı olmayan iyi yapılandırılmış bir CSS kod tabanı yapısına sahip olmanın önemli bir uyarısı var. Bu optimizasyon, CSS refactor planlanırken ve temel kurallar belirlenirken dikkate alınmalıdır.

Öncelikle optimizasyon faydasının potansiyel risklerden daha ağır basıp basmadığını kontrol etmenizi öneririm. Bu, bir CSS denetimi çalıştırarak ve medya sorgu istatistiklerini kontrol ederek kolayca yapılabilir. Olursa, daha sonra eklemenizi ve bunun sonucunda oluşabilecek beklenmedik yan etkileri ve hataları yakalamak için otomatik regresyon testi çalıştırmanızı tavsiye ederim.

Kullanılmayan CSS'yi Kaldırma

Yeniden düzenleme işlemi sırasında, tamamen kaldırılmamış bazı kullanılmayan eski stiller veya kullanılmayan bazı yeni eklenen stiller elde etme olasılığınız her zaman vardır. Bu stiller ayrıca genel karakter sayısına ve dosya boyutuna da eklenir. Bununla birlikte, bu kullanılmayan stilleri otomatik araçlar kullanarak ortadan kaldırmak biraz riskli olabilir çünkü araçlar gerçekte hangi stillerin kullanıldığını doğru bir şekilde tahmin edemez.

purgecss gibi araçlar projedeki tüm dosyaları gözden geçirir ve dosyalarda belirtilen tüm sınıfları seçici olarak kullanır, yalnızca dikkatli olmak ve diğer olası durumların yanı sıra dinamik, JavaScript enjekte edilmiş öğeler için seçicileri yanlışlıkla silmemek için. Ancak purgecss, bu olası sorunlar ve riskler için geçici çözümler olarak esnek yapılandırma seçenekleri sunar.

Ancak bu iyileştirme, yalnızca potansiyel faydalar risklerden daha ağır bastığında yapılmalıdır. Ek olarak, bu optimizasyon tekniğinin kurulması, yapılandırılması ve test edilmesi uzun zaman alacaktır ve ileride istenmeyen sorunlara neden olabilir, bu nedenle dikkatli ilerleyin ve kurulumun kurşun geçirmez olduğundan emin olun.

Oluşturmayı Engelleyen CSS'yi Ortadan Kaldırma

Varsayılan olarak CSS, oluşturmayı engelleyen bir kaynaktır, yani web sitesi, bağlantılı tüm stil sayfaları ve bunların bağımlılıkları (örneğin yazı tipleri) tarayıcı tarafından indirilip ayrıştırılıncaya kadar kullanıcıya gösterilmeyecektir .

Stil sayfası dosyasının büyük bir dosya boyutu veya üçüncü taraf sunucularda veya CDN'lerde bulunan birden çok bağımlılığı varsa, ağ hızına ve güvenilirliğine bağlı olarak web sitesi oluşturma önemli ölçüde gecikebilir.

En Büyük İçerikli Boyama (LCP), son birkaç ayda önemli bir ölçüm haline geldi. LCP yalnızca performans için değil aynı zamanda SEO için de önemlidir - daha iyi LCP puanlarına sahip web siteleri daha iyi arama sonuçları sıralamasına sahip olacaktır. CSS gibi oluşturmayı engelleyen kaynakları kaldırmak, LCP puanını iyileştirmenin bir yoludur.

Ancak, stil sayfasının yüklenmesini ve işlenmesini ertelersek, bu Stilsiz İçeriğin Flaşı (FOUC) ile sonuçlanır - içerik kullanıcıya hemen gösterilir ve stiller birkaç dakika sonra yüklenir ve uygulanır. Bu anahtar rahatsız edici görünebilir ve hatta bazı kullanıcıların kafasını karıştırabilir.

Kritik CSS

Critical CSS ile, web sitesinin, ilk oluşturulduğunda sayfada kullanılması garanti edilen minimum sayıda stille yüklenmesini sağlayabiliriz. Bu şekilde, FOUC'u çok daha az fark edilir hale getirebilir veya çoğu durumda ortadan kaldırabiliriz. Örneğin, ana sayfada gezinme özelliğine sahip bir başlık bileşeni ve ekranın üst kısmında bulunan bir ana bileşen varsa, bu, kritik CSS'nin bu bileşenler için gerekli tüm genel ve bileşen stillerini içereceği anlamına gelirken, sayfadaki diğer bileşenler için stiller içerir. ertelenecek.

Bu CSS, bir style etiketi altında HTML'de satır içine alınır, bu nedenle stiller HTML dosyasıyla birlikte yüklenir ve ayrıştırılır. Bu, biraz daha büyük bir HTML dosya boyutuyla sonuçlanacak olsa da (ki bu da küçültülmelidir), diğer tüm kritik olmayan CSS'ler ertelenecek ve hemen yüklenmeyecek ve web sitesi daha hızlı işlenecektir. Sonuç olarak, faydaları HTML dosya boyutundaki artıştan daha ağır basar.

 <head> <style type="text/css"><!-- Minified Critical CSS markup --></style> </head>

Kurulumunuza bağlı olarak, kritik CSS'yi çıkarabilen ve ertelenmiş stil sayfaları oluşturabilen birçok otomatikleştirilmiş araç ve NPM paketi vardır.

Stil Sayfalarını Erteleme

CSS'nin engellenmemesini tam olarak nasıl yaparız? Sayfa HTML'si ilk indirildiğinde, HTML head öğesinde buna başvurulmaması gerektiğini biliyoruz. Demian Renzulli bu yöntemi makalesinde özetlemiştir.

Oluşturmayı engelleyen kaynakların yüklenmesini optimize etmek veya ertelemek için yerel bir HTML yaklaşımı (henüz) yoktur , bu nedenle ilk oluşturmadan sonra kritik olmayan stil sayfasını HTML işaretlemesine eklemek için JavaScript kullanmamız gerekir. Ayrıca, bir kullanıcı sayfayı tarayıcıda JavaScript etkin değilken ziyaret ediyorsa, bu stillerin en uygun olmayan (oluşturmayı engelleyen) şekilde yüklendiğinden emin olmamız gerekir.

 <!-- Deferred stylesheet --> <link rel="preload" as="style" href="path/to/stylesheet.css" onload="this.onload=null;this.rel='stylesheet'"> <!-- Fallback --> <noscript> <link rel="stylesheet" href="path/to/stylesheet.css"> </noscript>

link rel="preload" as="style" , stil sayfası dosyasının eşzamansız olarak istenmesini sağlarken, onload JavaScript işleyicisi, HTML belgesinin yüklenmesi tamamlandıktan sonra dosyanın tarayıcı tarafından yüklenmesini ve işlenmesini sağlar. Biraz temizleme gerekiyor, bu nedenle bu işlevin birden çok kez çalışmasını ve gereksiz yeniden oluşturmalara neden olmasını önlemek için onload null olarak ayarlamamız gerekiyor.

Smashing Magazine, stil sayfalarını tam olarak böyle işler. Her şablonun (ana sayfa, makale kategorileri, makale sayfaları, vb.), head öğesindeki HTML style etiketinin içinde şablona özgü kritik bir CSS'si ve tüm kritik olmayan stilleri içeren ertelenmiş bir main.css stil sayfası vardır.

Ancak, burada rel parametresini değiştirmek yerine, sayfanın yüklenmesi bittiğinde medya sorgusunun otomatik olarak ertelenen düşük öncelikli print ortamından yüksek öncelikli all özniteliğine geçtiğini görebiliriz. Bu, kritik olmayan stil sayfalarının yüklenmesini ertelemek için alternatif, eşit derecede uygulanabilir bir yaklaşımdır.

 <link href="/css/main.css" media="print" onload="this.media='all'" rel="stylesheet">

Stil Sayfalarını Medya Sorgularıyla Bölme ve Koşullu Yükleme

Nihai stil sayfası dosyasının, yukarıda belirtilen optimizasyonlar uygulandıktan sonra bile büyük bir dosya boyutuna sahip olduğu durumlarda , stil sayfalarını medya sorgularına dayalı olarak birden çok dosyaya bölebilir ve bunları koşullu olarak yüklemek için link HTML öğesinde referans verilen stil sayfalarında medya özelliğini kullanabilirsiniz. .

 <link href="print.css" rel="stylesheet" media="print"> <link href="mobile.css" rel="stylesheet" media="all"> <link href="tablet.css" rel="stylesheet" media="screen and (min-width: 768px)"> <link href="desktop.css" rel="stylesheet" media="screen and (min-width: 1366px)">

Bu şekilde, mobil öncelikli bir yaklaşım kullanılırsa, daha büyük ekran boyutlarına yönelik stiller, daha yavaş veya güvenilir olmayan ağlarda çalışabilecek mobil cihazlarda indirilmez veya ayrıştırılmaz.

Yinelemek gerekirse, daha önce bahsedilen optimizasyon yöntemlerinin sonucu, yetersiz dosya boyutuna sahip bir stil sayfasıyla sonuçlanırsa, bu yöntem kullanılmalıdır. Normal durumlarda, bu optimizasyon yöntemi, bireysel stil sayfası boyutuna bağlı olarak o kadar etkili veya etkili olmayacaktır.

Yazı Tipi Dosyalarını ve Stil Sayfalarını Erteleme

Yazı tipi stil sayfalarının (örneğin Google Yazı Tipi dosyaları) ertelenmesi de ilk oluşturma performansı için faydalı olabilir. Stil sayfalarının oluşturmayı engellediği sonucuna vardık, ancak stil sayfasında başvurulan yazı tipi dosyaları da öyle. Yazı tipi dosyaları ayrıca ilk oluşturma performansına biraz ek yük ekler .

Yazı tipi stil sayfalarını ve yazı tipi dosyalarını yüklemek karmaşık bir konudur ve tüm uygulanabilir yaklaşımları açıklamak için tamamen yeni bir makaleye dalmak gerekir. Neyse ki, Zach Leatherman bu harika kapsamlı kılavuzda birçok uygulanabilir stratejiyi özetledi ve her yaklaşımın artılarını ve eksilerini özetledi. Google Fonts kullanıyorsanız, Harry Roberts, Google Fonts'un en hızlı yüklenmesi için bir strateji belirledi.

Yazı tipi stil sayfalarını ertelemeye karar verirseniz, Flash of Styled Text (FOUT) ile karşılaşacaksınız. Sayfa başlangıçta, ertelenmiş yazı tipi dosyaları ve stil sayfaları indirilip ayrıştırılıncaya kadar yedek yazı tipiyle oluşturulacak ve bu noktada yeni stiller uygulanacaktır. Bu değişiklik çok fark edilebilir olabilir ve duruma göre düzen kaymalarına ve kullanıcıların kafasının karışmasına neden olabilir.

Barry Pollard, FOUT ile başa çıkmamıza yardımcı olabilecek bazı stratejileri özetledi ve FOUT ile başa çıkmanın daha kolay ve daha yerel bir yolunu sağlayacak olan boyut ayarlı CSS özelliğinden bahsetti.

Sunucu Tarafı Optimizasyonları

HTTP Sıkıştırma

Küçültme ve dosya boyutu optimizasyonuna ek olarak, HTML, CSS dosyaları, JavaScript dosyaları vb. gibi statik varlıklar. İndirilen dosya boyutunu ek olarak azaltmak için Gzip ve Brotli gibi HTTP sıkıştırma algoritmaları kullanılabilir.

HTTP sıkıştırmasının, teknoloji yığınına ve yapılandırmaya bağlı olarak sunucuda yapılandırılması gerekir. Bununla birlikte, performans avantajları değişebilir ve tarayıcılar sıkıştırılmış dosyaları açmaya devam edeceğinden ve bunları ayrıştırmak zorunda kalacağından standart stil sayfası küçültme ve optimizasyon kadar etkili olmayabilir.

Stil Sayfalarını Önbelleğe Alma

Statik dosyaları önbelleğe almak, kullanışlı bir optimizasyon stratejisidir. Tarayıcılar, ilk yüklemede yine de statik dosyaları sunucudan indirmek zorunda kalacaklar, ancak önbelleğe alındıklarında, sonraki isteklerde doğrudan sunucudan yüklenerek yükleme sürecini hızlandıracaklar.

Önbelleğe alma, sunucu düzeyinde Cache-Control HTTP başlığı aracılığıyla kontrol edilebilir (örneğin, bir Apache sunucusundaki .htaccess dosyası kullanılarak).

max-age ile dosyanın tarayıcıda ne kadar süre (saniye olarak) önbelleğe alınması gerektiğini belirtebiliriz ve public ile dosyanın tarayıcı ve diğer önbellekler tarafından önbelleğe alınabileceğini belirtiyoruz.

 Cache-Control: public, max-age=604800

immutable yapılandırma ile statik varlıklar için daha agresif ve etkili bir önbellek stratejisi elde edilebilir. Bu, tarayıcıya bu belirli dosyanın asla değişmeyeceğini ve herhangi bir yeni güncellemenin bu dosyanın silinmesine neden olacağını ve yerini farklı bir dosya adına sahip yeni bir dosyanın alacağını söyler. Bu, önbellek bozma olarak bilinir.

 Cache-Control: public, max-age=604800, immutable

Uygun bir önbellek bozma stratejisi olmadan, kullanıcının tarayıcısında önbelleğe alınan dosyalar üzerindeki kontrolü kaybetme riski vardır. Yani, dosya değişecekse, tarayıcı güncellenmiş dosyayı indirmesi gerektiğini bilemez ve eski önbelleğe alınmış dosyayı kullanmaz. Ve bu noktadan sonra, bunu düzeltmek için yapabileceğimiz neredeyse hiçbir şey yok ve kullanıcı, süresi dolana kadar eski dosyada kalacak.

Stil sayfaları için bu, HTML dosyalarını yeni içerik ve yeni stil gerektiren bileşenlerle güncellersek, bu stiller görüntülenmeyecektir çünkü eski stil sayfası bir önbellek bozma stratejisi olmadan önbelleğe alındığından ve tarayıcı bunu bilmeyecek demektir. yeni dosyayı indirmesi gerekiyor.

Stil sayfaları veya diğer statik dosyalar için bir önbelleğe alma stratejisi kullanmadan önce, eski statik dosyaların kullanıcının önbelleğinde sıkışmasını önlemek için etkili önbellek bozma mekanizmaları uygulanmalıdır. Önbellek bozma için aşağıdaki sürüm oluşturma mekanizmalarından birini kullanabilirsiniz:

• Dosya adına bir sorgu dizesi ekleme.
  Örneğin, styles.css?v=1.0.1. Ancak, bazı CDN'ler, sorgu dizesini dosya adından tamamen yok sayabilir veya çıkarabilir ve dosyanın kullanıcının önbelleğinde takılıp kalmasına ve hiçbir zaman güncellenmemesine neden olabilir.
• Dosya adını değiştirme veya bir karma ekleme.
  Örneğin, styles.a1bc2.css veya styles.v1.0.1.css. Bu, dosya adına bir sorgu dizesi eklemekten daha güvenilir ve etkilidir.

CDN Veya Kendi Kendine Barındırma?

İçerik Dağıtım Ağı (CDN), resimler, videolar, HTML dosyaları, CSS dosyaları, JavaScript dosyaları vb. statik varlıkların güvenilir ve hızlı teslimi için yaygın olarak kullanılan, coğrafi olarak dağıtılmış bir sunucu grubudur.

CDN'ler, kendi kendini barındıran statik varlıklara harika bir alternatif gibi görünse de, Harry Roberts bu konuda derinlemesine bir araştırma yaptı ve kendi kendini barındıran varlıkların performans için daha faydalı olduğu sonucuna vardı.

“Statik varlıklarınızı başka birinin altyapısında bırakmak için gerçekten çok az neden var. Algılanan faydalar genellikle bir efsanedir ve öyle olmasalar bile, takaslar buna değmez. Varlıkları birden çok kaynaktan yüklemek gözle görülür şekilde daha yavaş."

Bununla birlikte, varsayılan olarak stil sayfalarını (mümkünse yazı tipi stil sayfaları dahil) kendi kendine barındırmanızı ve yalnızca geçerli nedenler veya başka faydalar varsa CDN'ye geçmenizi öneririm.

CSS Dosya Boyutunu ve Performansını Denetleme

WebPageTest ve diğer benzer performans denetleme araçları, web sitesi yükleme süreci, dosya boyutları, oluşturmayı engelleyen kaynaklar vb. hakkında ayrıntılı bir genel bakış elde etmek için kullanılabilir. Bu araçlar, web sitenizin çok çeşitli cihazlarda nasıl yüklendiği konusunda size bir fikir verebilir — yüksek hızlı bir ağda çalışan bir masaüstü bilgisayardan, yavaş ve güvenilmez ağlarda çalışan düşük kaliteli akıllı telefonlara kadar.

Bu dizinin ilk makalesinde bahsedilen bir web sitesinde bir performans denetimi yapalım – 2MB küçültülmüş CSS'ye sahip olan.

İlk olarak, hangi kaynakların en fazla bant genişliğini kapladığını belirlemek için içerik dökümüne göz atacağız. Aşağıdaki çizelgelerden, görüntülerin çoğu isteği aldığını görebiliriz, yani tembel olarak yüklenmeleri gerekir. İkinci grafikten, stil sayfalarının ve JavaScript dosyalarının dosya boyutu açısından en büyük olduğunu görebiliriz. Bu, bu dosyaların küçültülmesi ve optimize edilmesi, yeniden düzenlenmesi veya birden çok dosyaya bölünmesi ve eşzamansız olarak yüklenmesi gerektiğinin iyi bir göstergesidir.

Web Vitals çizelgelerinden daha da fazla sonuç çıkarabiliriz. En Büyük İçerikli Boyama (LCP) tablosuna göz atarak, oluşturmayı engelleyen kaynaklara ve bunların ilk oluşturmayı ne kadar etkilediğine ilişkin ayrıntılı bir genel bakış elde edebiliriz.

Web sitesi stil sayfasının LCP ve yükleme istatistikleri üzerinde en fazla etkiye sahip olacağı sonucuna varabiliriz. Bununla birlikte, aynı zamanda oluşturmayı engelleyen stil sayfalarının içinde başvurulan yazı tipi stil sayfalarını, JavaScript dosyalarını ve resimleri görebiliriz. Oluşturmayı engelleyen kaynakları ortadan kaldırarak LCP süresini azaltmak için yukarıda belirtilen optimizasyon yöntemlerini uygulayabileceğimizi bilmek.

Çözüm

Kod sağlığı ve kalitesi iyileştirildiğinde ve kod temeli zayıflıkları ve sorunları giderildiğinde yeniden düzenleme işlemi tamamlanmaz. Yeniden düzenlenmiş kod tabanı, eski kod tabanına kıyasla aynı veya geliştirilmiş performansla sonuçlanmalıdır.

Son kullanıcılar, yeniden düzenlenmiş kod tabanından performans sorunları veya uzun yükleme süreleri yaşamamalıdır. Neyse ki, basit küçültme ve optimizasyon yöntemlerinden, oluşturmayı engelleyen kaynakları ortadan kaldırma ve kod bölme gibi daha karmaşık yöntemlere kadar, kod tabanlarının hem sağlam hem de performanslı olduğundan emin olmak için birçok yöntem var.

Yükleme süreleri, performans, işlemeyi engelleyen kaynaklar ve diğer faktörler hakkında ayrıntılı bir genel bakış elde etmek için WebPageTest gibi çeşitli performans denetleme araçlarını kullanabiliriz, böylece bu sorunları erken ve etkili bir şekilde çözebiliriz.

Referanslar

• "Render Engelleme CSS," Ilya Grigorik
• “Kritik Olmayan CSS'yi Erteleyin,” Demian Renzulli
• “Yazı Tipi Yükleme Stratejileri İçin Kapsamlı Bir Kılavuz,” Zach Leatherman
• “Yazı Tipi Yükleme Etkisini Azaltmanın Yeni Bir Yolu: CSS Yazı Tipi Tanımlayıcıları,” Barry Pollard
• "Statik Varlıklarınızı Kendiniz Barındırın", Harry Roberts
• "WebFont Yükleme ve Oluşturmayı Optimize Etme", Ilya Grigorik