JavaScript Performans Optimizasyonu: Defer, Async ve Bundling

JavaScript yükleme için başlangıç ölçümünü netleştirin

Aynı sayfa farklı cihazlarda farklı hız gösterir. Tek sayıya bakıp karar vermek yerine dağılıma bakın.

• Gerçek kullanıcı verisi: CrUX raporundan 75. yüzdelik dilimi kontrol edin, ortalamaya değil.
• Laboratuvar testi: Lighthouse'u 3G throttling ile çalıştırın, WiFi değil.
• Cihaz kırılımı: Düşük-orta-yüksek segment için ayrı eşik belirleyin.
• Zaman karşılaştırması: Haftalık trend grafiği tutun, tek ölçüm yanıltır.

JavaScript yükleme darboğazını katman katman ayırın

Script darboğazını ayırırken render blocking kaynak yaklaşımı ve critical CSS planı birlikte ele alınırsa ilk ekran daha tutarlı hızlanır.

Hız sorunu tek kaynaktan doğmaz.

Ağır medya mı yavaşlatıyor, bloklayan kaynak mı, ana iş parçacığı yükü mü, sunucu gecikmesi mi? Chrome DevTools Performance sekmesinde Main thread grafiğine bakın: sarı bloklar uzunsa JavaScript işlem yükü yüksek demektir. Network sekmesinde waterfall grafiğinde Render-blocking kaynakları tespit edin. Lighthouse raporunda "Opportunities" bölümü size milisaniye bazında kazanç potansiyeli gösterir.

• Ağır medya: 1MB üzeri görsel LCP'yi 2 saniye geciktirebilir, WebP + lazy loading kullanın.
• Bloklayan kaynak: head içindeki CSS ve JS render'ı bloklar, critical CSS inline yapın.
• Ana iş parçacığı yükü: 50ms üzeri Long Task varsa kod splitting uygulayın.
• Sunucu gecikmesi: TTFB 600ms üzerindeyse CDN veya sunucu optimizasyonu öncelikli.

Bir metriği iyileştirirken başka bir alanda sorun üretmeyin.

JavaScript yükleme tarafında öncelik sırası kurun

Tüm sorunları aynı anda çözemezsiniz. Önceliklendirme matrisini net kurun.

Etki büyüklüğü, uygulama maliyeti, risk seviyesi ve geri dönüş süresi dört temel kriter. Yüksek etki + düşük maliyet kombinasyonu öncelikli. Örneğin: görsel optimizasyonu (WebP dönüşümü) yüksek etki + düşük risk, sunucu mimarisi değişikliği yüksek etki + yüksek risk. İlkini önce yapın.

• Etki büyüklüğü: Lighthouse "Opportunities" bölümünde milisaniye kazancına bakın, 500ms+ kazanç öncelikli.
• Uygulama maliyeti: Geliştirici-gün cinsinden hesaplayın, 2 günden az iş hızlı kazanç sağlar.
• Risk seviyesi: Kritik iş akışını etkileyen değişiklikler A/B test ile yayınlanmalı.
• Geri dönüş süresi: Feature flag ile yayınlanan değişiklikler 5 dakikada geri alınabilir.

JavaScript yükleme değişikliklerini küçük yayınlarla doğrulayın

Büyük değişiklikler risk taşır.

Aşamalı yayın yapın: önce %5 trafikte test edin, metrik stabil kalırsa %25'e çıkarın, sorun yoksa %100'e açın. Regresyon kontrolü için CI/CD pipeline'ına Lighthouse CI ekleyin, her commit'te performans skoru düşerse build fail olsun. Geri alma planı hazırlayın: feature flag kullanın, 5 dakikada eski versiyona dönebilmelisiniz.

• Aşamalı yayın: %5 → %25 → %100 trafik artışı, her adımda 24 saat bekleyin.
• Önce test sonra canlı: Staging ortamında Lighthouse skoru 90+ olmalı, yoksa canlıya almayın.
• Regresyon kontrolü: CI/CD'ye Lighthouse CI ekleyin, skor 5 puan düşerse build fail.
• Geri alma planı: Feature flag kullanın, sorun çıkarsa 5 dakikada geri alın.

Bir metriği iyileştirirken başka bir alanda sorun üretmeyin.

JavaScript yükleme verisini yanlış okumayın

Sonuç kontrolünde Lighthouse raporu yorumlama ile sayfa yüklenme hızı hedefleri aynı tabloda izlendiğinde yanlış optimizasyon riski düşer.

Tek ölçüm yanıltır. Ortalama yanıltır. Coğrafya farkı yanıltır. Cihaz sınıfı etkisi yanıltır.

Lighthouse'ta 95 skor aldınız, gerçek kullanıcı verisinde (CrUX) 65 görüyorsunuz. Neden? Laboratuvar testi ideal koşullarda çalışır: güçlü CPU, stabil ağ, cache temiz. Gerçek kullanıcı düşük işlem gücü, dalgalı ağ, arka planda açık 20 sekme ile sayfanızı açıyor. 75. yüzdelik dilime bakın, ortalamaya değil. Ortalama %1'lik ultra hızlı kullanıcı tarafından yukarı çekilir, gerçek deneyimi gizler.

• Tek ölçüm yanılgısı: 10 kez ölçün, medyan değeri alın, tek ölçüm %30 sapma gösterebilir.
• Aşırı ortalama kullanımı: 75. yüzdelik dilim gerçek kullanıcı deneyimini yansıtır, ortalama değil.
• Coğrafya farkı: Asya'dan ABD sunucusuna bağlanan kullanıcı 300ms ekstra gecikme yaşar.
• Cihaz sınıfı etkisi: Düşük segment Android cihazlar iPhone 14'ten 4x yavaş JavaScript çalıştırır.

JavaScript yükleme için sürdürülebilir kontrol rutini kurun

Tek seferlik iyileştirme yetmez. Süreklilik modeli kurun.

Haftalık denetim yapın: CrUX raporunu her Pazartesi kontrol edin, 75. yüzdelik dilim eşiğin üzerine çıktıysa alarm verin. Yayın öncesi kontrol: CI/CD pipeline'ına Lighthouse CI ekleyin, skor 5 puan düşerse merge bloklansın. Otomatik alarm: Google Analytics'te sayfa yüklenme süresi 3 saniyeyi geçerse Slack'e bildirim gitsin. Dokümantasyon disiplini: her iyileştirmeyi wiki'ye kaydedin, 6 ay sonra aynı sorunu tekrar çözmeyin.

• Haftalık denetim: CrUX raporunu her Pazartesi kontrol edin, 75. yüzdelik dilim eşiğin üzerine çıktıysa alarm verin.
• Yayın öncesi kontrol: CI/CD'ye Lighthouse CI ekleyin, skor 5 puan düşerse merge bloklansın.
• Otomatik alarm: Sayfa yüklenme süresi 3 saniyeyi geçerse Slack'e bildirim gitsin.
• Dokümantasyon disiplini: Her iyileştirmeyi wiki'ye kaydedin, 6 ay sonra aynı sorunu tekrar çözmeyin.

Bir metriği iyileştirirken başka bir alanda sorun üretmeyin.

Vaka Notu: Script sırası değişince etkileşim açıldı

Bir ürün liste sayfasında kullanıcı filtreye tıkladığında gecikme hissediliyordu. İncelemede kritik olmayan scriptlerin açılışta ana iş parçacığını meşgul ettiği görüldü. Ekip kod envanterini sınıflandırdı, zorunlu olmayan parçaları defer/async stratejileriyle yeniden konumlandırdı ve ilk yük baskısını azalttı.

Bu düzenlemeden sonra etkileşim daha erken kullanılabilir hale geldi. Vaka, JavaScript optimizasyonunda doğru sıranın çoğu zaman dosya sayısından daha belirleyici olduğunu ortaya koydu.