Hiçbir ekip siteyi bilerek şişirmez. Şişme, tek tek bakıldığında makul görünen kararların üst üste binmesidir: bir kampanya için eklenen sayaç scripti, denemesi biten A/B testinin kodu, tek bir sayfa için kurulan slider eklentisi, tasarımcının bıraktığı ikinci ikon seti, "şimdilik kalsın" denen canlı destek widget'ı. Her biri eklenirken beş dakikalık bir karardır. Hiçbiri kaldırılırken kimsenin işi değildir.
Bu birikimin bedelini her ziyaretçi öder. Tarayıcı, o sayfada hiç çalışmayacak CSS kurallarını da JavaScript satırlarını da indirir, ayrıştırır ve işler. Kullanılmayan kod temizliği tam olarak bu bagajı geri boşaltma işidir ve iki hamleye indirgenir: kodu hiç göndermemek ya da gerçekten gerektiği ana ertelemek.
İşin ölçülebilir tarafı şudur: Chrome DevTools'un Coverage paneli her dosyanın kaç baytının kullanıldığını, kaç baytının kullanılmadığını satır düzeyinde gösterir. Lighthouse ise bunu iki ayrı denetimle raporlar; kullanılmayan CSS için 2 KiB, kullanılmayan JavaScript için 20 KiB eşiğini aşan dosyaları listeler. Bu iki araç, "sitem ağır" hissini bir dosya listesine çevirir.
Kod yükü neden fark edilmeden birikir
Kullanılmayan kodun kaynakları birbirinden çok farklı görünür ama hepsi aynı yapısal nedene dayanır: eklemek kolaydır, kaldırmak sorumluluk ister.
- Tema ve eklenti varsayılanları. Çoğu tema ve eklenti kendi CSS ve JavaScript dosyasını sitenin tamamına yükler. İletişim formu eklentisinin stilleri ürün sayfasında da iner, slider kodu slider olmayan şablonda da çalışır.
- Framework şişkinliği. Utility temelli CSS framework'leri veya geniş bileşen kütüphaneleri, geliştirme sırasında binlerce kural tanımlar. Üretim yapılandırması doğru kurulmadıysa bu kuralların tamamı canlıya çıkar.
- Kopyala yapıştır kütüphaneler. Tek bir tarih seçici için sayfaya eklenen büyük bir kütüphane, o özellik kaldırıldıktan sonra da script etiketinde kalır.
- Ölü pazarlama etiketleri. Kapatılan reklam hesabının pikseli, sözleşmesi biten ısı haritası aracı, artık kimsenin bakmadığı ikinci analitik kurulumu. Bunlar genelde bir etiket yöneticisi konteynerinin içinde, geliştirme ekibinin görüş alanı dışında durur.
- Geçici çözümlerin kalıcılaşması. Bir hatayı örtmek için yazılan küçük script, hata düzeldikten sonra da sayfada kalır.
Bu listedeki hiçbir madde kötü mühendislik değildir. Hepsi, envanteri tutulmayan bir sistemin doğal çıktısıdır. Temizliğin ilk adımı da bu yüzden silmek değil, envanter çıkarmaktır.
Kullanılmayan CSS ile kullanılmayan JavaScript aynı maliyeti üretmez
İki dosya türü aynı klasörde durur ama tarayıcıya farklı faturalar keser. Bu ayrımı bilmeden yapılan temizlik, en pahalı kalemi atlayıp en görünür kalemi hedefler.
CSS tarafında sorun render engellemedir. Tarayıcı, sayfanın stil modelini kurmadan içeriği boyayamaz. Lighthouse'un render engelleyici kaynak denetimi bu yüzden iki kalıbı işaretler: <head> içinde defer veya async taşımayan script etiketleri ve disabled özniteliği bulunmayan, kullanıcının cihazıyla özel olarak eşleşen bir media değeri taşımayan stil dosyaları. media="all" değeri de render engelleyici sayılır. Dosyanın içindeki kuralların yüzde doksanı o sayfada hiç eşleşmese bile tarayıcı hepsini okur ve stil modeline işler.
JavaScript tarafında sorun ana iş parçacığıdır. Bir script ağdan indikten sonra iş bitmez: tarayıcı sözdizimini denetlemek için dosyayı ayrıştırır, bayt koduna derler ve çalıştırır. Dosya büyüdükçe bu iş ana iş parçacığında uzun görevlere dönüşür ve tarayıcının kullanıcı etkileşimlerine yanıt vermesini geciktirir. Sayfa görünmüş olsa bile yüklenmesi bitmemiş olabilir; kullanıcı tam bu aralıkta tıkladığında gecikmeyi hisseder.
Bu maliyet en büyük içerik boyamasına da sıçrar. Tarayıcılar görselleri ana iş parçacığında render eder. Yani en büyük görsel tamamen inmiş olsa dahi, alakasız bir scriptin çalışması bitene kadar ekrana gelmeyi bekleyebilir. LCP tarafındaki bütün zincir için LCP süresini 2,5 saniyenin altına çekme rehberimize bakabilirsiniz.
Buradan çıkan pratik sonuç şudur: sıkıştırma bu sorunu çözmez. Gzip veya Brotli, dosyanın ağ üzerinde kapladığı yeri küçültür; açıldıktan sonra CPU'nun yapacağı ayrıştırma, derleme ve stil hesaplama işini küçültmez. Küçük inen büyük dosya, hâlâ büyük dosyadır.
Coverage paneli ile gerçek kullanım oranını ölçmek
Coverage paneli, bu konudaki en doğrudan ölçüm aracıdır çünkü tahmin değil, gerçek çalıştırma verisi üretir. Açmak için geliştirici araçlarını açın, komut menüsünü çağırın, coverage yazıp Show Coverage komutunu seçin. Panel alt çekmecede açılır. Alternatif yol, sağ üstteki daha fazla seçenek menüsünden More tools altındaki Coverage girdisidir.
Kaydı başlatıp sayfayı yeniden yüklediğinizde tablo şu kolonlarla dolar:
- URL: incelenen kaynağın adresi.
- Type: kaynağın CSS mi, JavaScript mi yoksa ikisini birden mi içerdiği.
- Total Bytes: kaynağın toplam boyutu.
- Unused Bytes: kullanılmayan bayt sayısı.
- Usage Visualization: bu iki değerin görselleştirmesi. Çubuğun yeşil bölümü kullanılan, gri bölümü kullanılmayan baytlardır.
Panelin altındaki durum satırı, uygulanan filtreyi de hesaba katarak kullanılan kod yüzdesini verir. Açılır listeden yalnızca CSS veya yalnızca JavaScript gösterebilir, üstteki filtreye adres yazarak listeyi daraltabilirsiniz. Bir satıra tıkladığınızda kaynak, Sources panelinde satır satır açılır ve kullanılmayan satırlar, satır numaralarının solunda dikey gri çizgilerle işaretlenir. Raporu dışa aktarmak için Export coverage düğmesi vardır.
Burada çoğu ölçümü boşa çıkaran bir incelik var. Coverage yalnızca kaydın sürdüğü aralıkta gerçekten çalışan kodu kullanılmış sayar. Fareyle üzerine gelince açılan menü, tıklayınca çalışan form doğrulaması, aşağı kaydırınca tetiklenen animasyon, yalnızca hata durumunda devreye giren kod parçası; siz o etkileşimi yapmadıkça hepsi "kullanılmıyor" görünür. Sayfayı açıp hemen rapora bakmak, silinmemesi gereken kodu silinebilir gibi gösterir.
Doğru kullanım şöyledir: kayıt açıkken gerçek bir kullanıcı yolculuğu oynayın. Menüleri açın, sekmeleri gezdirin, formu hatalı doldurup uyarıyı tetikleyin, sayfa sonuna kadar kaydırın. Sonra aynı ölçümü her şablon türü için ayrı ayrı tekrarlayın: ana sayfa, kategori, ürün veya yazı detayı, iletişim, sepet. Silme kararını tek bir sayfanın raporuna değil, bu raporların birleşimine dayandırın. Ölçümü tarayıcı eklentilerinin bulunmadığı temiz bir profilde yapmak da sonucu belirgin biçimde temizler.
Lighthouse uyarılarını doğru okumak
Coverage size ham gerçeği verir, Lighthouse ise bunu eşiklere bağlanmış denetimlere çevirir. Konuyla doğrudan ilgili beş denetim şunlardır:
| Denetim | Ne zaman uyarı verir |
|---|---|
| Remove unused CSS | Fırsatlar bölümünde, 2 KiB ve üzeri potansiyel tasarrufu olan kullanılmayan CSS içeren tüm stil dosyalarını listeler. |
| Remove unused JavaScript | 20 kibibayttan fazla kullanılmayan kod içeren her JavaScript dosyasını işaretler. |
| Reduce the impact of third-party code | Üçüncü taraf kodun ana iş parçacığını toplamda 250 ms veya daha uzun süre bloklaması durumunda başarısız olur. |
| Lazy load third-party resources with facades | Sayfa, ertelenebilir bir gömülü ürün yüklüyorsa (sosyal buton widget'ları, video oynatıcı gömüleri gibi) başarısız olur. |
| Eliminate render-blocking resources | Baş bölümünde defer veya async taşımayan script etiketlerini ve cihaza özel media değeri taşımayan stil dosyalarını işaretler. |
Bu denetimleri okurken üç şeyi karıştırmamak gerekir. Birincisi, fırsat listesindeki tasarruf tahminleri ceza değildir; sıralamayı düşüren bir eksi puan değil, sayfanın hangi baytları boşa taşıdığının dökümüdür. İkincisi, Lighthouse tek bir cihazda tek bir yüklemenin laboratuvar ölçümüdür; Core Web Vitals değerlendirmesi ise gerçek kullanıcı verisinden gelir, ikisi farklı sorular sorar. Üçüncüsü ve en çok hata yapılan nokta: "bu sayfada kullanılmıyor" ile "sitede kullanılmıyor" aynı cümle değildir. Ana sayfada işe yaramayan bir stil dosyası, ödeme adımında hayati olabilir.
CSS yükünü azaltmanın iki kaldıracı
Birinci kaldıraç, kuralı hiç göndermemektir. PurgeCSS gibi araçlar şablon dosyalarınızı tarar, gerçekten kullanılan selektörleri bulur ve geri kalanını üretim çıktısından çıkarır. Utility temelli framework'lerde bu adım isteğe bağlı değildir; geliştirme çıktısı ile üretim çıktısı arasındaki farkın tamamı bu taramaya bağlıdır. Yapılandırmanın kalbi, taranacak dosyaları tarif eden içerik listesidir:
module.exports = {
content: ['./src/**/*.{html,js,jsx,vue}', './templates/**/*.php'],
safelist: ['active', 'is-open', 'has-error']
};Buradaki en yaygın kaza, dinamik olarak üretilen class isimleridir. Kod içinde parça parça birleştirilen bir class adı, statik taramada hiçbir yerde tam metin olarak görünmez ve silinir. Sonuç, canlıda stilsiz kalan bir bileşendir. JavaScript'in çalışma anında eklediği durum class'ları da aynı tuzağa düşer. Çözüm ikili: class adlarını parçalayarak değil tam yazarak üretmek ve çalışma anında eklenen adları güvenli liste ile korumak.
İkinci kaldıraç, kalan CSS'i render yolundan çıkarmaktır. Yalnızca yazdırma için gereken stiller media="print" ile işaretlendiğinde ilk boyamayı bekletmez. İlk ekranda gereken kuralları ayırıp geri kalanını sonraya bırakma yaklaşımını ise ayrıca ele aldık: inline kritik CSS yüklemesi rehberi bu bölümün doğal devamıdır. Sıralama önemlidir: önce kullanılmayan kuralları temizlemek, kritik CSS çıkarımını hem küçültür hem doğrultur.
JavaScript yükünü azaltma: tree shaking ve kod bölme
JavaScript tarafında da aynı ikili mantık işler, sadece araçların adı değişir.
Tree shaking: gönderilmeyecek kodu build aşamasında ayıklamak
Tree shaking, ölü kodun paketten çıkarılmasına verilen addır. Mekanizması basittir: modül paketleyici, import ve export ifadelerine bakarak hangi modüllerin dışa aktarıldığını ve gerçekten içe aktarıldığını çözer, kimsenin kullanmadığı export'ları çıktıya koymaz. Webpack ve Rollup gibi paketleyiciler bunu dosyaları birleştirirken otomatik yapar.
Bu mekanizmanın çalışması statik modül sözdizimine bağlıdır. Kütüphanenin tamamını tek bir isim altında içe aktarmak, paketleyiciye "neyin kullanılmadığını" çözme şansı bırakmaz; ihtiyaç duyulan fonksiyonu kendi modül yolundan çekmek ise yalnızca o parçayı bağlar:
// paketleyiciye ayıklama şansı bırakmaz
import _ from 'lodash';
// yalnızca ihtiyaç duyulan modülü bağlar
import debounce from 'lodash/debounce';Paket sahibi tarafında da bir beyan gerekir. package.json içindeki sideEffects alanı, modülün yan etkisiz olduğunu ve kullanılmayan export'ların güvenle atılabileceğini paketleyiciye bildirir. CSS içe aktarımları veya polyfill dosyaları gibi yan etkili girdiler varsa bu alanda tek tek belirtilir. Sonucu doğrulamanın yolu paket analiz raporudur: kullanılmadığını bildiğiniz bir fonksiyon hâlâ çıktıda görünüyorsa, ya beyan eksiktir ya da statik olmayan bir içe aktarma kullanılıyordur.
Kod bölme: göndermek zorunda olduğunuz kodu ertelemek
Kod bölme, tek bir dev paket yerine, ilk açılışta gerçekten gereken kodu ayırıp geri kalanını ayrı parçalara bölmektir. Amaç, kullanıcı uygulamayı açtığında yalnızca ilk rotanın ihtiyaç duyduğu kodu göndermek ve böylece ayrıştırılıp derlenmesi gereken script miktarını en aza indirmektir. Webpack, Rollup ve Parcel gibi paketleyiciler bunu dinamik içe aktarma ile yapar.
İki uygulama biçimi vardır. Rota bazlı bölme her URL yolu için ayrı parça üretir; kullanıcı ürün listesindeyken blog sayfasının kodu inmez. Bileşen bazlı bölme ise ağırlığı belli tekil parçaları hedefler: grafik kütüphaneleri, zengin metin editörleri, harita bileşenleri, tarih seçiciler, video oynatıcılar. Bunların ortak özelliği, sayfanın küçük bir bölümünde ve çoğu zaman bir etkileşimden sonra gerekmeleridir.
form.addEventListener('submit', async (e) => {
e.preventDefault();
const { validate } = await import('./agir-dogrulama.js');
validate(form);
});Dosya sistemi tabanlı yönlendirme kullanan modern framework'lerde rota bazlı bölme zaten varsayılandır; her sayfa dosyası ayrı bir parça olarak üretilir. Ancak bu otomatik davranış tek başına yetmez: bir sayfa bileşeni büyük bir kütüphaneyi doğrudan içe aktarıyorsa, o kütüphane o sayfanın parçasına dahil olur ve parça şişer. Bu noktada bileşen düzeyinde ek bölme gerekir.
Kod bölmeye kimin gerçekten ihtiyacı var?
Burada dürüst olmak gerekiyor, çünkü kod bölme çoğu sitede yanlış adrese atılan bir çözümdür. Kod bölme bir paketleyici tekniğidir ve ancak bölünecek bir paketiniz varsa anlamlıdır. Sitenizi bir JavaScript uygulaması olarak kuruyorsanız, tek bir büyük paket üretiyorsanız ve kullanıcı ilk açılışta uygulamanın tamamını indiriyorsa, bu bölüm sizin için birinci öncelik demektir.
Buna karşılık siteniz sunucuda üretilen klasik sayfalardan oluşuyor ve sayfada birbirinden bağımsız birkaç script etiketi varsa, bölünecek bir paket yoktur. Sizin sorununuz "paketi nasıl bölerim" değil, "hangi script hangi şablonda yükleniyor" sorusudur. Bu iki soru aynı hedefe hizmet eder ama çözümleri tamamen farklıdır ve birbirinin yerine geçmez.
Kod bölmenin WordPress karşılığı: koşullu yükleme ve eklenti diyeti
WordPress tarafında pratik karşılık, dinamik içe aktarma değil, hangi varlığın hangi şablonda kuyruğa gireceğine karar vermektir. Her eklenti kendi stil ve script dosyalarını kaydeder ve çoğu bunu sayfa ayrımı yapmadan yapar. Sonuç, tek bir iletişim formu için sitenin tamamına dağılmış bir CSS dosyasıdır.
WordPress bunun için doğrudan bir yol sunar: wp_dequeue_style() daha önce kuyruğa alınmış bir stil dosyasını kuyruktan çıkarır, wp_dequeue_script() aynısını script için yapar. Kritik nokta zamanlamadır. Sizin kodunuz, eklentinin kendi kayıt işleminden sonra çalışmalıdır; bu yüzden kanca geç bir öncelik değeriyle bağlanır:
add_action('wp_enqueue_scripts', function () {
if (!is_page('iletisim')) {
wp_dequeue_style('iletisim-formu');
wp_dequeue_script('iletisim-formu');
}
}, 100);Bu yaklaşımın iki bilinen kırılganlığı var. Birincisi, tanıtıcı adlar eklenti sürümleri arasında değişebilir; adı değişen bir tanıtıcıyı hedefleyen kod hiçbir hata vermeden eşleşmeyi bırakır ve yük sessizce geri döner. Bu yüzden koşullu yükleme kuralları, eklenti güncellemelerinden sonra yeniden ölçülmelidir. İkincisi, kuyruktan çıkarmak eklentiyi durdurmaz. Eklenti sunucu tarafında çalışmaya, sorgu üretmeye ve kancalarını işletmeye devam eder. Özellik hiç kullanılmıyorsa doğru hamle kuyruktan çıkarmak değil, eklentiyi tamamen kaldırmaktır.
Bu iki maddeyi birlikte düşünen bir yaklaşım, temizliği tek seferlik bir operasyon olmaktan çıkarıp düzenli bir kontrol kalemine dönüştürür. Site içi SEO analizi çalışmalarımızda kod yükü envanteri de bu mantıkla, şablon şablon çıkarılır.
Üçüncü taraf scriptler: en pahalı ve en az sahiplenilen yük
Kendi kodunuzu küçültmek için harcanan emek, çoğu sitede tek bir üçüncü taraf etiketinin maliyetini bile karşılamaz. Lighthouse burada net bir eşik kullanır: denetlediğiniz adresin alan adından farklı bir alan adında barındırılan her script üçüncü taraf sayılır ve bu scriptlerin ana iş parçacığını bloklama süresi toplamda 250 ms'yi aşarsa denetim başarısız olur.
Sorunun mekanizması ayrıştırıcı engellemedir. Tarayıcı bir script etiketiyle karşılaştığında DOM inşasını durdurur, scripti JavaScript motoruna verir ve çalışması bitene kadar bekler. async ve defer öznitelikleri bu davranışı değiştirir ama aynı şekilde değil:
- async: tarayıcı HTML'i ayrıştırmayı sürdürürken scripti eşzamansız indirir. İndirme bitince ayrıştırma durur ve script çalışır. Analitik gibi erken çalışması önemli scriptler için uygundur.
- defer: indirme yine eşzamansız yapılır ama script, belge ayrıştırması tamamlanana kadar çalıştırılmaz. Sayfanın ilk görünen bölümünde işi olmayan kaynaklar için uygundur.
Kritik render yolunun parçası olmadıkça üçüncü taraf scriptler her zaman bu ikisinden biriyle yüklenmelidir. Blink temelli tarayıcılarda bu öznitelikler ilgili ağ isteğinin önceliğini de düşürür, yani kazanç yalnızca çalışma zamanında değil indirme sırasında da oluşur.
Gömülü içerikler için ayrı bir çözüm var. Lighthouse, ertelenebilir gömülü ürünleri (sosyal buton widget'ları ve video oynatıcı gömüleri gibi) tanır ve bunlar için facade yaklaşımını önerir. Facade, gerçek gömünün yerine konan hafif bir yer tutucudur: kullanıcı tıklayana kadar ekranda statik bir önizleme durur, gerçek oynatıcı veya sohbet penceresi ancak tıklamadan sonra yüklenir. Ziyaretçilerin küçük bir bölümünün kullandığı bir canlı destek penceresi için bu, yükü herkesten alıp yalnızca ihtiyaç duyana bindirir.
Teknik çözümden daha zor olan kısım sahipliktir. Etiket yöneticisi konteynerleri genelde pazarlama tarafında yönetilir, geliştirme ekibi neyin ne zaman eklendiğini görmez. Kalıcı çözüm, konteynerdeki her etiketin bir sahibi ve bir varlık nedeni olduğu bir envanter tutmaktır. Sahibi bulunamayan etiket, silinecek etikettir.
Temizliği bozmadan yapmanın sırası
Kullanılmayan kod temizliği, yanlış yapıldığında hız kazancından çok daha pahalı arızalar üretir. Riski düşük tutan sıra şudur:
- Envanter çıkarın. Ağ panelinde sayfanın yüklediği tüm kaynakları listeleyin, üçüncü taraf alan adlarını ayırın ve her birinin hangi iş fonksiyonuna hizmet ettiğini ilgili ekibe doğrulatın.
- Ölçün. Coverage kaydını tam bir kullanıcı yolculuğuyla ve her şablon türü için ayrı ayrı alın. Lighthouse denetimlerini not edin.
- Getirisi yüksek ve riski düşük olandan başlayın. Genellikle sıra şudur: iş fonksiyonu kalmamış üçüncü taraf etiketler, gömülü içerikler için facade, eklenti varlıklarının koşullu yüklenmesi, build aşamasında selektör temizliği, en son kod bölme.
- Tek seferde tek değişiklik yapın ve önce hazırlık ortamında deneyin. Beş değişikliği birlikte yayına alıp arızayı geri sarmak, kazandığınız süreden fazlasını götürür.
- Regresyonu görsel olarak değil işlevsel olarak test edin. Kritik kontrol noktaları: çalışma anında eklenen durum class'ları, form doğrulama uyarıları, hata ve boş durum ekranları, giriş yapmış kullanıcı görünümü, mobil menü, çerez bildirimi ve ödeme adımları.
- Yeniden ölçün ve alan verisinde doğrulayın. Laboratuvar ölçümü değişikliğin çalıştığını gösterir; gerçek kullanıcı verisi ise etkisinin anlamlı olup olmadığını gösterir.
Ne kadar iyileşme beklemelisiniz
Bu sorunun dürüst cevabı bir yüzde değildir ve yüzde veren her kaynağa temkinli yaklaşmakta fayda var. Kazanç, temizlenen kodun miktarına değil, o kodun darboğazın neresinde durduğuna bağlıdır. Aynı 200 KB, iki farklı sitede bambaşka sonuç üretir.
Mekanizmaya bağlı beklenti şöyle kurulur:
- Kullanılmayan kod, baş bölümünde render engelleyen bir stil dosyasının içindeyse, kazanç ilk boyama ve LCP zincirinde görünür.
- Kullanılmayan kod, sayfa yüklenirken ayrıştırılıp derlenen büyük bir script içindeyse, kazanç etkileşim gecikmesinde ve dolaylı olarak LCP'nin render gecikmesi bileşeninde görünür.
- Kullanılmayan kod, zaten sayfa yüklendikten sonra tembel olarak inen bir dosyadaysa, silmek kod tabanını temizler ama metriklerde kayda değer bir hareket üretmeyebilir.
Bu yüzden önceliklendirmeyi dosya boyutuna göre değil, engelleme süresine göre yapmak gerekir. Ana iş parçacığını çeyrek saniye bloklayan tek bir üçüncü taraf scripti kaldırmak, tekrar eden ziyaretçilerde zaten önbellekten gelen büyük bir stil dosyasını inceltmekten çok daha fazla iş görür.
Zamanlama konusunda da beklentiyi doğru kurmak gerekir. Laboratuvar araçları değişikliği yayına aldığınız anda gösterir. Gerçek kullanıcı verisine dayanan raporlar ise son haftaların hareketli bir penceresini kullanır, yani yeterli sayıda yeni ziyaret birikene kadar rapor eski durumu göstermeye devam eder. Temizlik yaptıktan sonraki gün rapora bakıp sonuç çıkarmak, çoğu ekibin yaptığı ve gereksiz yere moral bozan bir hatadır.
Sık sorulan sorular
Brotli veya gzip sıkıştırma varken kullanılmayan kodu temizlemek hâlâ gerekli mi?
Evet, çünkü sıkıştırma yalnızca ağ maliyetini azaltır. Dosya tarayıcıya ulaştıktan sonra açılır ve tam boyutuyla işlenir: CSS'teki her kural stil modeline girer, JavaScript'teki her satır ayrıştırılır ve derlenir. Sıkıştırma indirme süresini kısaltır, ana iş parçacığında geçen süreyi kısaltmaz. Yavaş cihazlarda asıl darboğaz da genellikle indirme değil, işlemedir.
Coverage bir dosyanın büyük bölümünün kullanılmadığını söylüyor, hepsini silebilir miyim?
Hayır. O oran, yalnızca kaydın sürdüğü aralıkta ve yalnızca o sayfada gerçekleşen çalıştırmayı yansıtır. Etkileşimle tetiklenen kod, hata durumunda devreye giren kod ve başka şablonlarda kullanılan kod bu ölçümde kullanılmıyor görünür. Karar vermek için ölçümü tüm önemli şablonlarda ve gerçek etkileşimler yapılarak tekrarlayın, sonra bu raporların birleşimini alın. Silinecek küme, hiçbir ölçümde kullanılmayan kümedir.
Eklentiyi kaldırmak yerine varlıklarını kuyruktan çıkarmak yeterli mi?
Kısmen. Kuyruktan çıkarma yalnızca CSS ve JavaScript dosyalarının o şablonda yüklenmesini engeller; eklentinin sunucu tarafındaki kodu, veritabanı sorguları ve kancaları çalışmaya devam eder. Eklenti bazı sayfalarda gerçekten kullanılıyorsa koşullu yükleme doğru çözümdür. Özellik artık hiç kullanılmıyorsa yarım çözümle uğraşmak yerine eklentiyi tamamen kaldırmak hem daha hızlı hem daha güvenlidir.
Bir kütüphaneyi CDN üzerinden yüklemek kullanılmayan kod sorununu çözer mi?
Çözmez, yalnızca dosyanın nereden indiğini değiştirir. Kütüphanenin kullanılmayan bölümleri yine indirilir, ayrıştırılır ve derlenir. Üstelik dış bir alan adından yüklenen script, ölçüm tarafında üçüncü taraf koda dönüşür ve ana iş parçacığı bloklama bütçesine dahil edilir. CDN bir dağıtım kararıdır, kod yükü kararı değildir.
