CSS ve JavaScript iyileştirme
CSS ve JavaScript iyileştirmek üç iştir ve değerleri bu sıradadır: gereksizi silin, hemen gerekmeyeni sonraya bırakın, kalanı küçültün. Bu sitede ana stil sayfasını küçültmek telde 16,3 KB kazandırdı ve yazmadığımız tek bir analitik dosyası 171,1 KB tutuyor.
- Ders 7 / 10
- Orta
- Ücretsiz, kayıt yok
Bu sırayla çalışın
- her dosyayı diskte değil telde tartın
- her satır için sorun: hangi özelliği veriyor ve burada gerekli mi
- ayakta kalanı defer ya da async ile çizim yolundan çıkarın
- en son küçültün ve sayıyı sıkıştırmadan sonra okuyun
- on değişiklikten sonra değil, her değişiklikten sonra bir kez test edin
Bunlar vakit yer, az getirir
- sayfada hiç olmaması gereken bir dosyayı küçültmek
- defer'i tek seferde her betiğe eklemek
- aracın sıkıştırmadan önce gösterdiği yüzdeyi ölçüt almak
- kritik CSS aracının çıktısını sayfaya bakmadan yayına almak
Son kontrol: Bu dersteki bilgiler ve araç adları bu tarihte kaynaklarıyla yeniden doğrulanır.
Herhangi bir iyileştirmeden önce gerçekte ne varsa tartın
Çoğu hız eğitimi ortadan başlar: küçültün, birleştirin, erteleyin. Bunların hepsi doğrudur ve hepsi kimsenin sormadığı bir sorunun ardından gelir: bu dosya burada ne arıyor?
Bunu sorabilmek için önce her dosyanın diskteki boyutunu değil gerçek ağırlığını görmeniz gerekir. Önemli olan teldeki boyuttur; ziyaretçiye gerçekten ulaşan sıkıştırılmış şey. Şu komut bir sayfadaki her betiği o boyutla listeler:
curl -s https://example.com/ \
| grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | sort -u \
| while read u; do printf '%8s %s\n' \
"$(curl -s -o /dev/null -H 'Accept-Encoding: gzip' -w '%{size_download}' "$u")" "$u"; doneBu komutta kendi düştüğümüz bir tuzak var: HTML'deki bir adres & içeriyorsa & biçiminde yazılır ve o satır sıfır bayt bildirir. Sıfır, ölçülmedi demektir, hafif demek değil. O tek satırı elle düzeltin ya da yok sayın.
Bu komutun kendi sayfalarımızdan birindeki çıktısı, en ağırdan hafife: Google analitik dosyası için 171,1 KB, jQuery için 29,9 KB, kendi ana betiğimiz için 5,9 KB, bir fiyat hesaplayıcı için 1,9 KB ve bir captcha betiği için bir kilobaytın altı. Cloudflare captcha betiği kendi alan adlarında duruyor ve komut satırından sıfır döndü; onu hesabın dışında bıraktık ve boyutunu bilmediğimizi burada açıkça söylüyoruz.
Şimdi toplayın. Bizim yazdığımız 7,8 KB, yazmadığımız 201,5 KB. Yani o sayfanın gönderdiği JavaScript ağırlığının yüzde 96,3'ü başkasının kodu. Hiçbir küçültme miktarı bu oranı oynatmaz.
Küçültme ne kadar kazandırır? Sayıyı sıkıştırmadan sonra okuyun
Küçültme, bir dosyadan tarayıcının ihtiyaç duymadığı her şeyi çıkarmaktır: boşluklar, yorumlar, uzun adlar ve daha iyi araçlarda birleştirilen yinelenen kurallar. Yapmanız gereken ve bedava olan bir iştir, ama eklentilerin size gösterdiği sayı yanlış sayıdır.
Bu sitenin ana stil sayfasını iki türlü ölçtük: bir kez ham, bir kez de gerçekten gönderildiği gibi gzip ile sıkıştırılmış. Orijinal 129,0 KB ve 32,3 KB'ye sıkışıyor. Küçültülmüş sürüm 79,1 KB ve 16,3 KB'ye sıkışıyor.
Şimdi iki tasarrufu yan yana koyun. Kâğıt üzerinde küçültme 49,9 KB, yani yüzde 39'a yakınını kaldırdı ve aracınızın raporunun gösterdiği rakam budur. Telde ise aynı iş 16,0 KB kaldırdı. İki sayı da doğrudur ve hıza etki eden yalnızca ikincisidir.
Bu neden önemli? Çünkü kâğıt sayısını ölçüt alırsanız sonraki kararlarınızı yanlış önceliklendirirsiniz. Kâğıtta yüzde 40 tasarruf gösteren bir iyileştirme telde birkaç kilobayt olabilirken, küçük ama sıkışmayan bir betiği silmek bunun birkaç katı değerinde olabilir. Sıkıştırmadan sonraki sayı, bir ziyaretçinin hissettiği tek sayıdır.
Daha az söylenen bir şey: bu sitedeki küçültme kazancının büyük bir kısmı dosyanın içindeki yorumların atılmasından geliyor. Ana dosyamız insanlar için yazılmış uzun Farsça yorumlar taşıyor; gzip onları iyi sıkıştırır ama silmez. Dosyanızda yorum yoksa sıkıştırılmışla küçültülmüş arasındaki fark daha dar olacaktır ve bu normaldir.
defer mi async mi; hangisi ve nerede
Sıradan bir betik, indirilip çalışırken sayfanın kurulmasını durdurur; o kurulumun tam olarak nasıl ilerlediği tarayıcı sayfayı nasıl kurar dersinin konusudur. İki öznitelik bu davranışı değiştirir ve farkı tam olarak bilmeniz gerekir, çünkü yanlış yerde bunlardan biri sayfayı bozar.
defer ile tarayıcı dosyayı hemen indirmeye başlar ama çalıştırmasını sayfa kurulana kadar bekletir ve bu özniteliği taşıyan birkaç betik, sayfada göründükleri sırayla çalışır. async ile indirme yine hemen başlar ama çalıştırma dosya hazır olduğu anda, iş nereye gelmişse orada olur ve sırayı hiçbir şey garanti etmez.
Pratik kural bu farktan çıkar. Kodunuzun geri kalanına bağlı olan ya da sayfa öğelerine dokunan her betik defer ister. Tümüyle bağımsız ve kimseyi ilgilendirmeyen her betik, analitik gibi, async alır. Emin değilseniz defer daha güvenli seçimdir, çünkü en kötü durumu biraz geç çalışmaktır; async'in en kötü durumu ise yalnızca yavaş bağlantıda ortaya çıkan, yeniden üretilemeyen bir hatadır.
Şimdi eğitimlerin en az söylediği ve pratikte en çok önemli olan şey: betiğin belgedeki yeri. Bütün betikler gövdenin dibindeyse, özniteliksiz bir betik bile çok az şeyi engeller, çünkü o noktada sayfa kurulmuştur. Bu sitenin ana sayfasında ilk betik belgenin yüzde 96,6'sında duruyor ve head içinde hiç dış betik yok. Oradaki üç betik hâlâ özniteliksiz ve biz onları düzeltmedik, çünkü onları ekleyen eklenti bizim yerimize karar veriyor.
Ve bu işte her şeyden çok site bozan bir uyarı: defer'i tek seferde her şeye eklemek. Bunu tek bir düğmeyle yapan eklentiler var ve kodu çalıştırma sırasına bağlı bir sitede sonuç, rastgele çalışan bir sayfadır. Teker teker ve her değişiklikten sonra bir kez test edin.
defer ve async ikisi de doğrudur, iki tür betik için
defer
- indirme hemen başlar, çalıştırma sayfa kurulduktan sonra
- sıra korunur, başka koda bağlı kod sağ kalır
- sayfa öğelerine dokunan her şey için
async
- indirme hemen başlar, çalıştırma dosya hazır olur olmaz
- sırayı hiçbir şey garanti etmez, bağımlılıkları kırar
- analitik gibi tümüyle bağımsız şeyler için
Hiçbiri diğerinden üstün değildir. Emin değilseniz defer'i seçin: en kötü durumu geç çalışmaktır, async'in en kötü durumu ise yalnızca yavaş bağlantıda görünen bir hatadır.
Kritik CSS ve satır içine alma: bedeli olan bir kazanç
Her dış stil sayfası çizimi engelleyen bir kaynaktır: tarayıcı onu almadan hiçbir şey çizmez. Yaygın yanıt kritik CSS'tir: ilk görünüm için gereken parçayı sayfanın kendisine yazmak ve gerisinin sonra gelmesine izin vermek. Biz bir adım öteye gidip stil sayfasının tamamını satır içine alıyoruz; bu sitenin ana sayfasında hiç link rel=stylesheet etiketi yok ve bütün kurallar başlıktaki dört stil bloğunda duruyor.
Bu kararın bir kazancı var ve bedelini ödüyoruz; bedeli neredeyse kimse yazmadığı için bizimkini buraya koyuyoruz. Aynı HTML'i aldık, ana stil bloğunu bir dış bağlantıyla değiştirdik ve iki sürümü de sıkıştırdık. Gerçekten gönderilen sürüm 41,8 KB, dış sayfalı sürüm 26,0 KB. Yani satır içine almak her HTML yanıtına, her ziyarette, her seferinde 15,8 KB ekliyor.
Başabaş noktası basit bir aritmetik. Bir sayfa görüp giden ziyaretçi fazladan bir şey ödemez, çünkü o CSS'i her hâlükârda alacaktı. Beş sayfa gören ziyaretçi ise aynı 15,8 KB'yi dört kez daha alır; dış sayfayla bir kez alınır, sonrası tarayıcı önbelleğinden gelirdi. Yani bu seçim genel bir kurala değil trafiğinizin biçimine bağlıdır: ziyaretleri çoğunlukla aramadan gelen ve tek sayfada biten bir site için satır içi kazanır.
Bunu bir görüşten ayıran şey, geri döndürülebilir yapmış olmamız. Hem satır içi hem dış mod kodda duruyor ve tek bir sabitle değiştiriliyor; tam da ikisi ölçülüp kazanan tutulabilsin diye. Trafiğin biçimi değişirse karar da değişir.
Ve kritik CSS araçları için bir uyarı: çıktılarına bakmak gerekir. Bu araçlar ilk görünümün hangi kurallara ihtiyacı olduğuna karar verir ve düzeni diğerlerinden farklı sayfalarda yanılırlar. Sonuç, bir an biçimsiz görünen bir sayfadır ve bu engelleyici bir stil sayfasından daha kötüdür.
CSS sayfanın içinde mi ayrı bir dosyada mı olsun?
Sayfanın içinde
- çizimi engelleyen kaynak kalmaz
- CSS HTML ile birlikte gelir, ikinci gidiş dönüş olmaz
- ama aynı baytlar her ziyarette yeniden gönderilir
- aramadan gelen tek sayfalık ziyaret için daha iyi
Ayrı bir dosyada
- bir kez indirilir, sonra tarayıcı önbelleğinden gelir
- her HTML yanıtı hafifler
- ama gelene kadar tarayıcı hiçbir şey çizmez
- birkaç sayfa okuyan ziyaretçi için daha iyi
Biz satır içini seçtik ve bedeli her HTML yanıtında 15,8 KB. Doğru seçim genel bir kurala değil, trafiğinizin biçimine bağlıdır.
Sizin yazmadığınız kod
Ders burada bir tutum alıyor ve bunu kendimize karşı alıyor: yukarıdaki dört bölümün anlattığı her şey sizin yazdığınız koda uygulanır ve ortalama bir sitede sizin yazdığınız kod azınlıktır.
Bizim o aynı sayfamızda jQuery 29,9 KB. Ondan tek satır kullanmıyoruz ve tek satırını yazmadık; captcha koyan güvenlik eklentisi ona ihtiyaç duyuyor ve WordPress onu gönderiyor. Analitik dosyası 171,1 KB ve o da Google'a ait, yalnızca kendi sunucumuzda barınıyor. Bu ikisi artı captcha betiği 201,5 KB ediyor; kendi kodumuzun 7,8 KB'sine karşı.
Şimdi asıl mesele: bunların hiçbiri iyileştirmeyle çözülmez. jQuery zaten küçültülmüş ve sıkışıyor. Analitik dosyası da öyle. İkisi de async ya da defer ile çizim yolundan çekilir ve ikisi de ziyaretçinin bağlantısından aynı sayıda baytı, telefonunun işlemcisinden aynı miktarda işi almaya devam eder. Bu sayıları değiştiren tek karar, o özelliği hiç isteyip istemediğinizdir.
Bu kararı henüz vermedik ve dürüst nedeni şu: captcha formlarımızdan istenmeyeni uzak tutuyor, analitik hangi sayfanın işe yaradığını söylüyor. İkisi de bedelinin üstünde gördüğümüz bir değer taşıyor. Yaptığımız şey bedeli sınırlamak oldu; jQuery her sayfada değil, yalnızca form taşıyan sayfalarda. Blog sayfaları ve bu bölümün dersleri onu hiç almıyor.
Yani sizin için işin sırası şu. Önce listeyi alın. Sonra her satır için sorun: bu hangi özelliği veriyor ve o özellik bu sayfada gerekli mi. Ayakta kalanı sonraya bırakın, ondan sonra da ayakta kalanı küçültün. Sırayı ters çevirirseniz birkaç kilobayta saatler harcar ve 171'i hiç görmezsiniz. Bir sonraki sorunuz sitenizin aslında ne kadar JavaScript'e ihtiyacı olduğuysa, yanıtı yeni başlayanlar için JavaScript dersinde.
Yapay zekayla hızlı yol
Hangi betiğin sonraya bırakılabileceğini bulmanın alışılmış yolu birini değiştirmek, siteye bakmak ve bir şey bozulmadıysa sonrakine geçmektir. Üç dosyayla işe yarar, yirmi dosyayla günler alır. Hızlı yol, ayıklama işini modele vermek, karar işini vermemektir. Bunu sıradan bir soru sormaktan ayıran şey: modele çıplak bir dosya listesi vermeyin, her dosya için onu hangi eklentinin ya da özelliğin getirdiğini söyleyin. Model bir dosya adından bir betiğin çalıştırma sırasına bağlı olduğunu bilemez; o özelliğin ne yaptığından iyi bir tahmin yürütebilir. Ortaya çıkan şey, sonra tek tek uygulayacağınız önceliklendirilmiş bir listedir.
- İlk bölümdeki komutla sayfadaki betiklerin listesini, teldeki boyutlarıyla alın.
- Her satırın yanına onu hangi eklentinin ya da özelliğin getirdiğini yazın. Bilmiyorsanız bilmiyorum yazın; o da bir bilgidir.
- Listeyi aşağıdaki reçeteyle verin ve üç küme isteyin: silinebilir, ertelenebilir ve dokunulmaz.
- Listenin başından başlayın ve her seferinde tam olarak bir değişiklik yapın. Her değişiklikten sonra sayfayı açın ve tarayıcı konsoluna bakın. Bu adım bir modele verilemez ve atlanamaz.
Kopyalamaya hazır şablon
Bu, sitemdeki bir sayfanın betik listesi. İlk sütun bayt cinsinden teldeki boyut, ikincisi adres, üçüncüsü onu getiren eklenti ya da özellik.
{listeyi buraya yapıştırın}
Site türü: {örneğin bir WordPress mağazası | bir şirket sitesi | bir blog}
Bu sayfada gerçekten kullanılan özellikler: {iletişim formu | kaydırıcı | harita | hiçbiri}
Listeyi üç kümeye ayır ve her kümeyi en ağırdan başlayarak sırala:
1. Silinebilir: bu sayfada kullanılmayan bir özellik.
2. Ertelenebilir: kalmalı ama ilk görünüm için gerekmiyor. Her biri için defer ya da async ve bir cümle gerekçe yaz.
3. Dokunulmaz: çalıştırma sırasına ya da sayfa öğelerine bağlı olan her şey.
Kurallar:
1. Yalnızca bu listeden çalış. Bir satır hakkında karar vermek için yeterli bilgin yoksa onu üçüncü kümeye koy ve neye ihtiyaç duyacağını yaz.
2. Tanımadığın bir dosyayı asla birinci kümeye koyma.
3. Bir satır güvenlik ya da ödeme eklentisinden geliyorsa varsayılan üçüncü kümedir.
4. İkinci kümedeki her öneri için, yanlışsa görünür biçimde neyin bozulacağını yaz. O cümle, değişiklikten sonra test etmem gereken şeyin ta kendisidir.
5. Tahmini bir tasarruf sayısı uydurma ve hız konusunda bir şey vaat etme.
Çıktıyı üç liste hâlinde, hiçbir giriş yapmadan ver.Çıktıya güvenmeden önce: Model sitenizi göremez; dolayısıyla silinebilir kümesine koyduğu her şey bir sonuç değil bir varsayımdır. En tehlikeli durumu, tanımadığı bir dosyayı adından tahmin etmesidir; yukarıdaki ikinci kural bunun içindir. Son adım da devredilemez: her değişiklikten sonra sayfayı açın ve tarayıcı konsoluna bakın. Dördüncü kuralda istenen cümle tam bunun için var, çünkü bu işin en kötü başarısızlıkları sessizdir ve bir düğme çalışmayı bırakmışken sayfa sağlam görünür.
Bu işte yapay zeka
Buradaki tutumumuz: yapay zekâ bu işte ayıklamakta ve açıklamakta iyi, karar vermekte kötüdür. Fark tam olarak söylenebilir. Hangi dosyaların sonraya bırakılabileceği bir ayıklama sorusudur ve model onu iyi yanıtlar. Bu dosyayı silmenin bir şeyi bozup bozmayacağı ise sitenizle ilgili bir sorudur ve model sitenizi görmedi. Akılda tutmaya değer cümle şu: listeyi model sıralar, değişikliği siz yaparsınız.
Gerçekten işe yarayan araçlar
- Claude Yukarıdaki ayıklama işine uygundur, özellikle de kurallar altında çalışmaya: tanınmayan bir dosyayı birinci kümeye koymamasını söyleyin, genellikle koymaz. İran, Anthropic'in desteklenen ülkeler listesinde değil; dolayısıyla resmi kayıt da yok, İran kartı da kabul edilmiyor.
- Gemini Tanımadığınız bir betiğin neye ait olduğunu çıkarmak için işe yarar, çünkü genellikle bilinen kitaplık ve eklenti adlarını bilir. Google'ın kendi sayfası, Gemini web uygulamasının 230'dan fazla ülke ve bölgede çalıştığını söylüyor ve İran o listede yok.
- ChatGPT Aynı ayıklama ve açıklama işi için yeterli. İran'dan erişim konusunda bir iddiada bulunmuyoruz, çünkü OpenAI'nin desteklenen ülkeler sayfası, o alan adının geri kalanı gibi, bu sunucuya 403 döndürüyor.
Nerede geri teper
İki risk var ve ikincisi özellikle bu derse ait. Birincisi, model tasarruf rakamları uydurur. Dizginlenmezse bu değişiklik sayfa hızını yüzde kırk iyileştirir gibi, arkasında hiçbir ölçüm olmayan cümleler üretir; yukarıdaki reçetede bunu açıkça yasaklamamızın nedeni budur. İkinci risk daha kötüdür, çünkü sessizce bozar: model yerine geçecek kod yazar. Ona jQuery'yi nasıl kaldırırım diye sorun; o kodu sizin için tam bir güvenle düz JavaScript ile yeniden yazar. O kod çoğu zaman çalışır ve bazen yalnızca mobilde ya da yalnızca formda hata varken görünen bir uç durumu kaçırır. Böyle bir değiştirme yapacaksanız, onu zararsız bir iyileştirme gibi değil, herhangi bir yeni kod gibi test edin.
Kaynaklar: MDN: the script element Anthropic: supported countries Google: where Gemini Apps are available
Bu tavsiyenin sınırı
Bu ders kodu teslim etmekle ilgilidir, yazmakla değil; kodunuzun kendi başına yavaş olup olmadığı başka bir konudur ve bunların hiçbiri onu düzeltmez. Üç sınırı daha var. Birincisi, bu sayfadaki sayılar tek bir siteye aittir ve sizinkinde farklı olacaktır; özellikle de dosyanın taşıdığı yorum miktarına bağlı olan küçültme payı. İkincisi, satır içine alma kararı trafiğin biçimine bağlıdır ve bizim seçimimiz, ziyaretleri çoğunlukla tek sayfalık ve aramadan gelen bir siteye uygundur; tek sayfalık bir uygulama ya da kullanıcının uzun oturumlar geçirdiği bir site için yanıt tersidir. Üçüncüsü, on binlerce sayfalı ve birkaç geliştirme ekipli çok büyük siteler konusunda doğrudan deneyimimiz yok ve onlar hakkında bir iddiada bulunmuyoruz.
Kendi işimizden
Bu iş hakkında öğrendiğimiz en öğretici şey, kendi sitemizde beklemediğimiz bir ölçümden geldi. Bu dersin önerdiği her şeyi kendi kodumuza uyguladık: stil sayfası tümüyle satır içinde, sayfada dış stil sayfası etiketi yok, kendi betiklerimizin hepsi defer taşıyor ve ilk betik belgenin yüzde 96,6'sında duruyor. Sonra gerçekte ne olduğunu tarttık ve sayfada, hiçbirini bizim yazmadığımız 171,1 KB'lik bir analitik dosyası ile 29,9 KB'lik bir jQuery bulduk; kendi kodumuzun 7,8 KB'sine karşı. Yani her şeyi doğru yaptığımız o sayfada JavaScript ağırlığının yüzde 96,3'ü elimizin dışındaydı. O günden sonra iş sıramız değişti: önce ağırlık listesi, sonra her satır için bir soru ve en sonda iyileştirme.
Gerçek devam soruları
CSS ve JavaScript dosyalarımı birleştirmeli miyim?
Sandığınızdan az. Birleştirme istek sayısını azaltmak için vardı ve bugünün bağlantılarında o maliyet epey düştü. Buna karşılık gerçek bir sakıncası var: büyük bir birleşik dosya, her küçük değişiklikte tarayıcı önbelleğinin tamamını geçersiz kılar. Birleştirmekle silmek arasında seçmek zorundaysanız silin.
İyileştirme eklentisi mi kurmalıyım, elle mi yapmalıyım?
Küçültme ve sıkıştırma için eklenti doğru seçimdir, çünkü o iş mekaniktir ve hataları geri alınabilir. Ama her şeye defer ekleyen ya da kritik CSS üreten düğmeleri teker teker açın ve her birinden sonra siteye bakın. Ve unutmayın: hiçbir eklenti bu sayfada hangi özelliğin gereksiz olduğuna karar vermez; o karar hep sizindir.
WordPress sitemden jQuery'yi kaldırmalı mıyım?
Önce onu neyin istediğini bulun, çünkü bu genellikle siz değilsinizdir. Bir eklenti ona bağlıysa jQuery'yi kaldırmak o eklentiyi bozar ve haftalarca fark edilmeyebilecek sessiz bir hata alırsınız. Daha güvenli ve genellikle yeterli olan hamle, onu yalnızca gerçekten ihtiyaç duyan sayfalarda tutmaktır; sitemizde bunu yaptık ve blog sayfaları onu hiç almıyor.