Hafif Kod logosu

Yazılar · 6/7

Kod optimizasyonu ve frontend performansı notları.

  1. Web Vitals RUM ve Lab Data Farkı Nedir?

    Lighthouse testi tamamlandı: LCP 1.8 saniye, genel skor 97. Her şey yeşil. Birkaç dakika sonra Google Search Console açılıyor ve o sayfanın "Zayıf URL'ler" listesinde göründüğü görülüyor. İki araç aynı sayfayı ölçüyor; sonuçlar birbirine zıt. Hangisi doğru?

  2. Cache-Control ve ETag Nasıl Birlikte Çalışır?

    Cache-Control: no-cachebaşlığını ilk gören çoğu geliştirici bu direktifin önbelleği tamamen devre dışı bıraktığını varsayar. İsim tam da bunu çağrıştırıyor. Oysano-cache, "önbelleğe alma" değil, "önce doğrula" anlamına gelir. Tarayıcı varlığı önbelleğe alır; ama kullanmadan önce sunucuya sorar. Bu tek yanlış anlamanın bedeli, binlerce gereksiz tam HTTP isteği veya tam tersi — güncellenmesi gereken varlıkların günlerce eski haliyle sunulması olabilir.

  3. Immutable Cache Nedir? Ne Zaman Kullanılır?

    Diyelim ki bir JavaScript dosyasınaCache-Control: public, max-age=31536000uyguladınız — 1 yıllık önbellek. Kullanıcı sayfayı ziyaret etti, dosya önbelleğe alındı. Bir hafta sonra o dosyada kritik bir hata düzelttiniz ve yeni sürümü deploy ettiniz. Aynı URL'de sunulan bu dosyanın önbelleği tarayıcıda hâlâ geçerli. Kullanıcı eski, hatalı sürümü görmeye devam eder. 51 hafta boyunca.

  4. Versioned Asset Nedir? CSS ve JS Cache Busting Rehberi

    Bir ekipstyle.css?v=2olarak versiyonladığı CSS dosyasını deploy etti. Sunucu yeni dosyayı gönderiyor; ama kullanıcıların bir kısmı eski tasarımı görmeye devam ediyor. Geliştirici araçlarında 200 yanıtı görünüyor — dosya gelmiş gibi. Soruna bakıldığında anlaşılıyor ki önünde duran CDN, query string'i önbellek anahtarına dahil etmeyecek biçimde yapılandırılmış.?v=1ve?v=2CDN için aynı kaynak. Eski yanıt TTL dolana kadar servis edildi; hiçbir hata mesajı, hiçbir uyarı yoktu.

  5. Brotli mi Gzip mi? Sıkıştırmada Hangisi Daha İyi?

    Brotli, web performans tartışmalarında uzun süredir Gzip'in yerini alması beklenen algoritma olarak anılır. Sıkıştırma karşılaştırmalarında ortalama %15–20 daha küçük çıktı üretir; tüm modern tarayıcılar destekler; büyük CDN sağlayıcılarının çoğunda artık varsayılan seçenektir. Bu tablo "Brotli her zaman daha iyidir" sonucuna götürür gibi görünse de asıl soru daha dardır: hangi sıkıştırma seviyesinde, hangi içerik türü için ve hangi altyapı koşulunda?

  6. HTTP/2 ve HTTP/3 Performansı Gerçekte Ne Kadar Etkiler?

    Sunucu yapılandırmasını HTTP/2'ye taşıdıktan birkaç gün sonra PageSpeed Insights'ı yeniden açanların önemli bir kısmı bekledikleri puanı göremez. LCP değişmemiştir, TTFB yerindedir, toplam puan en fazla birkaç birim oynamıştır. Akla gelen ilk soru şudur: Protokol gerçekten uygulandı mı? Genellikle uygulanmıştır. Sorun, beklenti ile protokolün gerçekte ne yaptığı arasındaki uçurumdan kaynaklanır.

  7. CDN Kullanmak Ne Zaman Gerçekten Fayda Sağlar?

    CDN entegrasyonu tamamlandıktan sonra PageSpeed Insights yeniden açılır veTTFBdeğerinin yerinde durduğu görülür. LCP değişmemiştir. Toplam puan en fazla birkaç birim ilerlemiştir. "CDN aktif, DNS de düzgün çalışıyor, peki neden fark etmedi?" sorusu kaçınılmaz olarak gündeme gelir. Bu deneyim, CDN kullananların önemli bir bölümünün yaşadığı ve çoğunlukla yanlış yerde aradığı bir sorundur.

  8. Service Worker Performansı Artırır mı Yoksa Karmaşıklaştırır mı?

    "Service Worker ekledik, site belirgin biçimde hızlandı" ile "Service Worker ekledik, kullanıcılar güncel içeriği göremez oldu" — bu iki gözlem aynı ekiplerden, hatta aynı projeden çıkabilir. Çelişkili görünen bu tablo aslında tutarlı bir mekanizmanın iki farklı koşul altındaki yansımasıdır. Her ikisinin kaynağı da aynı yerdedir: önbellekleme kontrolü.

  9. Resource Hint Türleri: dns-prefetch, preconnect, preload, prefetch

    Dört farklı resource hint türünün varlığı, hangisinin ne işe yaradığını belirsizleştirir. Bazı projelerde hepsi birden head bölümüne eklenir; "bir şeyler işe yarar" düşüncesiyle kurulan bu yaklaşım çoğunlukla tam tersine performans düşürür. Kullanılmayan preconnect bağlantıları gereksiz TCP ve TLS el sıkışması başlatır. as niteliği olmadan eklenen preload direktifi kaynağı iki kez indirir. Gerektiğinden erken yapılan prefetch isteği kritik kaynakların bant genişliğini tüketir. Her hint türünün tarayıcıda farklı bir maliyet ürettiğini anlamadan yapılan eklemeler, azaltmak istediğiniz yükü artırır.

  10. `content-visibility` Nedir? Büyük Sayfalarda Ne İşe Yarar?

    Sayfa yüklendi, ağ performansı iyiydi, kaynaklar optimize edildi — ama render yine de ağır hissettiriyor. Lighthouse skoru tatmin ediciyken gerçek kullanımda sayfa hâlâ gecikmeli davranıyor. Bu çelişkinin kaynağı çoğu zaman DOM'un kendisidir. Tarayıcı, sayfadaki her öğeyi — görünür olsun ya da olmasın — layout ve paint hesabına katar. Kullanıcının viewport'unda olmayan 200 kart, 50 bölüm veya 1000 satırlık tablo, sayfanın ilk render anında işleme girip maliyet üretir.

  11. `contain` Özelliği Performansı Nasıl Etkiler?

    Tarayıcı, bir DOM değişikliği aldığında ne kadar alanı yeniden hesaplamak zorunda olduğuna kendisi karar verir. Varsayılan yanıt çoğu zaman genişleme yönündedir: bir kutunun içindeki metin değişirse o metnin genişliği değişebilir, genişlik değişirse flex container yeniden hesaplanabilir, container yeniden hesaplanırsa komşu öğeler de etkilenebilir. Bu zincir, DOM'da birbirine bağımlı öğeler olduğu sürece yayılır. Sayfa büyüdükçe bu yayılımın maliyeti artar.

  12. Reflow ve Repaint Nedir? Tarayıcıda Maliyet Nerede Oluşur?

    Bir kullanıcı sayfayı kaydırırken veya açılır bir menüye tıklarken tarayıcı perde arkasında sessizce hesap yapar. Bu hesabın boyutu, yapılan işlemin türüne göre çarpıcı biçimde değişir. Bir kutunun arka plan rengini değiştirmek ile genişliğini değiştirmek, sezgisel olarak birbirine yakın işlemler gibi görünebilir — ikisi de CSS değişikliğidir. Tarayıcı için ise bu iki değişiklik birbirinden tamamen farklı bir iş yüküne karşılık gelir.

  13. DOM Boyutu Fazla Olursa Ne Olur?

    Bir tablo bileşeni düşünün: 100 satır, her satırda 8 sütun, her hücrede metin ve bir simge. Bu tek bileşen 800'den fazla DOM düğümü üretir. Buna sayfa başlığı, gezinti menüsü, filtre paneli, sayfalama kontrolü ve birkaç açılır bileşen eklenince toplam 1.500'ü aşmak için özel bir çaba gerekmez. Sonsuz kaydırma uygulayan bir içerik akışı ise kullanıcı sayfayı indirdikçe bu sayıyı durmaksızın artırır; kaldırma mekanizması yoksa DOM büyümeye devam eder.

  14. Üçüncü Parti Scriptler Performansı Nasıl Bozar?

    Tipik bir kurumsal pazarlama sayfasını inceleyin — tarayıcının geliştirici araçlarını açın, Network sekmesini filtreleyin. İstek listesinde büyük olasılıkla şunlar çıkar: Google Analytics veya GA4, Google Tag Manager, bir sohbet widget'ı, Facebook Pixel, LinkedIn Insight Tag, bir ısı haritası aracı, bir A/B test sistemi ve belki bir reklam dönüşüm izleme scripti. Bunlar ayrı etki alanlarından gelen, sekiz ila on iki bağımsız script anlamına gelir. Her biri ayrı bir ağ bağlantısı, ayrı bir parse işlemi ve ayrı bir execution görevi demektir.

  15. Cookie Banner ve Analitik Scriptleri Ne Kadar Yavaşlatır?

    Kullanıcı sayfayı açar. İçerik henüz tam görünmeden ekranın altında veya ortasında bir banner belirir: "Bu site çerez kullanmaktadır." Birkaç buton, belki bir "Tüm Ayarları Yönet" bağlantısı. Banner, sayfanın geri kalanından önce yüklenir — çünkü öyle ayarlanmıştır. Banner scripti<head>içinde, sayfanın kendi JavaScript'inden ve stil dosyalarından önce konumlandırılmıştır. Kullanıcı bir şeyi okumadan önce önce onay vermek zorunda olduğunu fark eder.