Kullanılmayan CSS/JS Temizliği

Kullanılmayan CSS/JS temizliği, sayfa render'ı sırasında hiçbir işlev görmeyen stil kurallarının ve JavaScript kodlarının tespit edilerek codebase'den çıkarılması sürecidir. 2026 verilerine göre ortalama bir web sayfası 400 KB CSS ve 900 KB JavaScript yüklemekte, bu kaynakların %40-60'ı sayfada hiç kullanılmamaktadır. Bu ölü kod yükü, parse süresini uzatarak LCP'yi doğrudan geciktirir ve ana thread'i bloke ederek INP'yi olumsuz etkiler.

Kullanılmayan Kodun Performans Maliyetinin Anatomisi

Kullanılmayan CSS ve JavaScript, üç ayrı performans katmanında maliyet üretir. Birinci katman ağ transferidir: gereksiz baytlar indirilir ve bant genişliği tüketilir. İkinci katman parse süresidir: tarayıcı, indirilen dosyanın tamamını parse eder, kullanılan ve kullanılmayan kurallar arasında ayrım yapmaz. Üçüncü katman bellek tüketimidir: parse edilen kurallar ve fonksiyonlar, kullanılmasa bile belleğe yüklenir ve garbage collection döngüsüne girer.

Bu üç katmanın kümülatif etkisi, mobil cihazlarda dramatik biçimde belirginleşir. Orta segment bir Android cihaz, 200 KB JavaScript'i parse etmek için ortalama 1-2 saniye harcar. Bu sürenin yarısı kullanılmayan koda aitse, 0.5-1 saniye tamamen boşa giden işlem süresidir. Dolayısıyla kullanılmayan kod temizliği, dosya boyutu küçültmenin ötesinde, doğrudan CPU zamanı tasarrufu sağlayan bir optimizasyondur.

Chrome DevTools Coverage ile Kullanım Oranı Analizi

Chrome DevTools'un Coverage sekmesi, sayfada yüklenen her CSS ve JavaScript dosyasının ne kadarının gerçekten çalıştırıldığını veya uygulandığını gösterir. Bu araç, kullanılmayan kod tespitinin en doğrudan ve güvenilir yöntemidir.

Coverage analizini çalıştırmak için Chrome DevTools'u açın (F12), Ctrl+Shift+P ile komut paletini açın ve "Show Coverage" yazıp seçin. Coverage panelinde "Reload" butonuna tıklayarak sayfayı yeniden yükleyin. Her dosya için kullanılan (mavi) ve kullanılmayan (kırmızı) oranları görüntülenir. Dosyaya tıkladığınızda, satır bazında hangi kodun çalıştırıldığını ve hangisinin çalıştırılmadığını görebilirsiniz.

Bu analiz sırasında dikkat edilmesi gereken kritik nokta şudur: Coverage aracı, yalnızca o anki sayfa yüklemesi sırasında kullanılan kodu işaretler. Hover, click veya scroll gibi etkileşimlerle tetiklenen kodlar, bu etkileşimler gerçekleştirilmeden "kullanılmayan" olarak görünür. Dolayısıyla Coverage analizini tam bir kullanıcı yolculuğu simülasyonu yaparak (menülere tıklama, formlara yazma, scroll etme) çalıştırmak daha doğru sonuç verir.

CSS Kullanım Analizi ve Ölü Kural Tespiti

CSS dosyalarında kullanılmayan kurallar, genellikle üç kaynaktan beslenir. Birincisi, framework ve kütüphane CSS'leridir. Bootstrap, Tailwind veya Foundation gibi UI framework'lerinin tamamı dahil edildiğinde, kullanılan bileşenlerin CSS'i toplam dosyanın %10-30'unu oluşturur. İkincisi, kaldırılmış bileşenlerden kalan artık stillerdir. Projede artık kullanılmayan bir modal, slider veya banner'ın CSS kuralları dosyada kalmaya devam eder. Üçüncüsü, medya sorgularıyla yalnızca belirli ekran boyutlarında uygulanan kuralların diğer boyutlarda gereksiz olmasıdır.

PurgeCSS, HTML ve JavaScript dosyalarını tarayarak CSS selektörleriyle eşleştirme yapar ve eşleşmeyen kuralları kaldırır:

    
// postcss.config.js
module.exports = {
  plugins: [
    require('@fullhuman/postcss-purgecss')({
      content: [
        './src/**/*.html',
        './src/**/*.jsx',
        './src/**/*.tsx',
        './src/**/*.vue'
      ],
      defaultExtractor: content => content.match(/[\w-/:]+(?<!:)/g) || [],
      safelist: {
        standard: ['active', 'open', 'is-visible', 'show'],
        deep: [/^modal/, /^tooltip/],
        greedy: [/data-theme$/]
      }
    })
  ]
};       
    

safelist yapılandırması kritik önem taşır. JavaScript ile dinamik olarak eklenen class'lar (.active, .is-visible), PurgeCSS tarafından HTML'de bulunamadığı için yanlışlıkla silinebilir. Bu class'ları safelist'e eklemek, yanlış pozitif temizlikleri önler.

JavaScript Kullanım Analizi ve Dead Code Tespiti

JavaScript'te kullanılmayan kod, CSS'ten daha karmaşık bir yapıya sahiptir. İmport edilen ancak hiç çağrılmayan fonksiyonlar, koşullu dallanmalarda hiç girilmeyen bloklar ve geliştirme ortamına özgü debug kodları (console.log, devtools entegrasyonları) ölü kod kategorisine girer.

Webpack Bundle Analyzer, hangi modülün bundle'da ne kadar yer kapladığını treemap formatında görselleştirir:

    
npx webpack --profile --json > stats.json
npx webpack-bundle-analyzer stats.json    
    

Bu analiz, büyük kütüphanelerin tamamının bundle'a dahil edildiği noktaları ortaya koyar. Moment.js'in locale dosyalarının tamamı (300 KB+) bundle'da yer alabilir. Lodash'ın tüm fonksiyonları tek import ile dahil edilmiş olabilir. Bu tespitler, tree shaking ve seçici import stratejilerinin uygulanması gereken alanları doğrudan işaret eder.

Tree Shaking ile Kullanılmayan Export'ların Eliminasyonu

Tree shaking, ES Module (import/export) sözdiziminde kullanılmayan export'ların build aşamasında bundle'dan çıkarılmasını sağlar. Webpack, Rollup ve Vite, tree shaking'i varsayılan olarak destekler. Ancak bu mekanizmanın çalışması için birkaç ön koşul gereklidir.

Birincisi, kodun ES Module formatında yazılmış olması gerekir. CommonJS (require/module.exports) ile tree shaking çalışmaz. İkincisi, kütüphanelerin package.json dosyasında "sideEffects": false beyanı bulunmalıdır. Bu beyan, build aracına modülün yan etkisiz olduğunu ve kullanılmayan export'ların güvenle kaldırılabileceğini bildirir:

    
{
  "name": "my-library",
  "sideEffects": false
}
    

CSS import'ları veya polyfill'ler gibi yan etkili dosyalar varsa, bu dosyalar sideEffects dizisinde belirtilmelidir:

    
{
  "sideEffects": ["*.css", "./src/polyfills.js"]
}
    

Tree shaking'in etkinliğini doğrulamak için bundle analyzer çıktısını kontrol edin. Kütüphanenin kullanılmayan fonksiyonları hâlâ bundle'da görünüyorsa, sideEffects beyanı eksik veya CommonJS import kullanılıyor demektir.

Kütüphane Swap ile Toplam Boyut Düşürme

Büyük kütüphaneleri küçük alternatiflerle değiştirmek, tree shaking'in yetersiz kaldığı durumlarda etkili bir stratejidir. Bu swap'lar, API uyumluluğunu koruyarak geçiş maliyetini minimumda tutar.

Moment.js (300 KB gzip öncesi) yerine Day.js (7 KB) veya date-fns (modüler, yalnızca kullanılan fonksiyonlar) kullanmak, tarih işleme kodunu %95 küçültür. Lodash (70 KB gzip) yerine lodash-es (tree shaking destekli) veya native JavaScript metotları kullanmak, utility fonksiyon yükünü ortadan kaldırır. Axios (13 KB gzip) yerine native Fetch API kullanmak, HTTP istemci bağımlılığını tamamen kaldırır.

Bu swap kararları, projenin başında verilmesi ideal olan ancak sonradan da uygulanabilir adımlardır. Her swap öncesinde ilgili kütüphanenin kullanım noktalarını grep veya IDE search ile tespit edin, alternatifte API farkları varsa migration path oluşturun ve swap sonrasında test suite'inizi çalıştırarak regresyon olmadığını doğrulayın.

WordPress Eklenti Kaynaklı CSS/JS Şişkinliği

WordPress ekosisteminde her eklenti kendi CSS ve JavaScript dosyalarını yükler. 20 aktif eklentisi olan bir WordPress sitesinde, her sayfa yüklemesinde 15-25 ayrı CSS ve 20-30 ayrı JavaScript dosyası indirilir. Bu dosyaların çoğu, ilgili eklentinin işlev gördüğü sayfa dışında da yüklenir. İletişim formu eklentisinin CSS'i, ürün sayfasında da yüklenir. Slider eklentisinin JavaScript'i, slider olmayan sayfalarda da aktiftir.

Bu sorunu çözmek için WordPress'te koşullu kaynak yüklemesi uygulanır. functions.php dosyasında eklenti scriptlerini yalnızca gerekli sayfalarda yüklemek mümkündür:

    
function optimize_plugin_assets() {
  if (!is_page('iletisim')) {
    wp_dequeue_style('contact-form-7');
    wp_dequeue_script('contact-form-7');
  }
  if (!is_front_page()) {
    wp_dequeue_style('slider-plugin');
    wp_dequeue_script('slider-plugin');
  }
}
add_action('wp_enqueue_scripts', 'optimize_plugin_assets', 100);
    

priority parametresi 100 olarak ayarlanarak, eklentilerin kendi enqueue fonksiyonlarından sonra çalışması sağlanır. Asset CleanUp ve Perfmatters gibi eklentiler, bu koşullu yüklemeyi görsel arayüzle yönetmeye olanak tanır.

Webpack ve Vite Build Yapılandırmasında Ölü Kod Eliminasyonu

Webpack'te ölü kod eliminasyonu, mode: 'production' ayarıyla otomatik olarak aktifleşir. Bu mod, Terser ile minification, tree shaking ve dead code elimination'ı varsayılan olarak uygular. Ancak bazı yapılandırma hataları bu optimizasyonları devre dışı bırakabilir.

Webpack yapılandırmasında kontrol edilmesi gereken noktalar:

    
module.exports = {
  mode: 'production',
  optimization: {
    usedExports: true,      // Tree shaking'i etkinleştirir
    minimize: true,          // Minification'ı etkinleştirir
    sideEffects: true,       // sideEffects beyanlarını dikkate alır
    concatenateModules: true  // Scope hoisting uygular
  }
};
    

Vite projelerinde ise Rollup'ın tree shaking mekanizması varsayılan olarak aktiftir. build.rollupOptions.treeshake ayarı ile daha agresif tree shaking yapılandırılabilir. Ancak agresif tree shaking, bazı side-effect'li modülleri yanlışlıkla kaldırabilir. Build sonrasında uygulamanın tam fonksiyonelliğini test etmek bu riski kontrol altına alır.

Dinamik Import ile Sayfa Bazlı Kod Yükleme

Kullanılmayan JavaScript'in en köklü çözümü, kodu sayfa veya bileşen bazında bölerek yalnızca ihtiyaç duyulan parçaları yüklemektir. Dinamik import() ifadesi, build aracının kodu ayrı chunk'lara bölmesini ve tarayıcının yalnızca ilgili chunk'ı indirmesini sağlar.

    
// Tüm sayfaların kodunu tek bundle'da taşımak yerine
import AdminPanel from './pages/AdminPanel';
import UserDashboard from './pages/UserDashboard';

// Sayfa bazlı chunk'lara bölmek
const AdminPanel = lazy(() => import('./pages/AdminPanel'));
const UserDashboard = lazy(() => import('./pages/UserDashboard'));
    

Bu yaklaşımda AdminPanel'in JavaScript'i, yalnızca kullanıcı admin paneline gittiğinde indirilir. Ana sayfayı ziyaret eden kullanıcı, admin panelinin kodunu hiç indirmez. Bu strateji, "kullanılmayan kod temizliği" nin en yapısal formudur; kod silinmez, yalnızca doğru zamanda yüklenir.

CSS Modülleri ve Scoped CSS ile Ölü Kural Önleme

CSS Modules, her bileşenin CSS'ini o bileşenin kapsamına (scope) sınırlar. Bileşen kaldırıldığında, o bileşenin CSS'i de doğal olarak kullanılmaz hale gelir ve build sürecinde bundle'dan çıkarılır. Bu yaklaşım, ölü CSS birikimini yapısal olarak önler.

    
/* ProductCard.module.css */
.card { border: 1px solid #e0e0e0; border-radius: 8px; padding: 16px; }
.title { font-size: 1.125rem; font-weight: 600; margin: 0 0 8px; }
.price { color: #2563eb; font-size: 1.25rem; }
    

    
import styles from './ProductCard.module.css';

function ProductCard({ product }) {
  return (
    <div className={styles.card}>
      <h3 className={styles.title}>{product.name}</h3>
      <span className={styles.price}>{product.price}</span>
    </div>
  );
}
    

Bu yapıda ProductCard bileşeni projeden kaldırıldığında, ProductCard.module.css dosyası da import edilmez ve build çıktısına dahil olmaz. Global CSS dosyasında birikerek "kimsenin dokunmaya cesaret edemediği" ölü kurallar oluşmaz. Vue'nun <style scoped> ve Svelte'in yerleşik scoped CSS mekanizması da aynı izolasyonu sağlar.

Tailwind CSS'te Kullanılmayan Class Temizliği

Tailwind CSS, utility-first yaklaşımıyla binlerce CSS class'ı tanımlar. Geliştirme build'inde tüm class'lar mevcuttur (3-4 MB). Üretim build'inde ise Tailwind'in yerleşik PurgeCSS entegrasyonu, kullanılmayan class'ları otomatik olarak temizler ve dosya boyutunu 10-30 KB'a düşürür.

tailwind.config.js dosyasındaki content dizisi, Tailwind'in hangi dosyaları tarayarak kullanılan class'ları tespit edeceğini belirler:

    
module.exports = {
  content: [
    './src/**/*.{html,js,jsx,tsx,vue}',
    './public/index.html'
  ],
  theme: { extend: {} },
  plugins: []
};
    

content dizisinin eksik veya yanlış tanımlanması, kullanılan class'ların temizlenmesine ve prodüksiyonda stilsiz elemanlar görülmesine neden olur. Dinamik olarak oluşturulan class isimleri (bg-${color}-500 gibi) PurgeCSS tarafından tespit edilemez. Bu class'ları safelist'e eklemek veya tam class adını kullanmak (bg-blue-500) zorunludur.

Üçüncü Parti Script Audit ve Gereksiz Bağımlılık Kaldırma

Sayfada yüklenen üçüncü parti scriptlerin tamamı aktif olarak kullanılmayabilir. Denemesi biten A/B test scriptleri, kapatılmış reklam ağı kodları, artık kullanılmayan analytics araçları ve eski canlı sohbet entegrasyonları, silinmeyi unutan teknik borç birikimidir.

LinkedIn üzerindeki web performans topluluklarında paylaşılan site denetim raporları gösteriyor ki, kurumsal sitelerin ortalama %15-20'si artık kullanılmayan üçüncü parti scriptler barındırıyor. Bu scriptleri tespit etmek için Chrome DevTools Network sekmesinde üçüncü parti domain'leri listeleyin ve her birinin iş fonksiyonunu ekiple doğrulayın. İş fonksiyonu ortadan kalkmış scriptleri kaldırmak, hem JavaScript yükünü hem de güvenlik yüzey alanını küçültür.

npm/yarn Dependency Audit ve Kullanılmayan Paket Tespiti

node_modules dizinindeki paketlerin tamamı projede aktif olarak kullanılmayabilir. Geliştirme sürecinde denenen ve terk edilen kütüphaneler, refactoring sonrasında gereksiz hale gelen utility paketleri ve dolaylı bağımlılıklar package.json dosyasında birikir.

depcheck aracı, package.json'daki bağımlılıkları proje dosyalarıyla karşılaştırarak kullanılmayan paketleri tespit eder:

    
npx depcheck
    

Bu komut, hiçbir dosyada import edilmeyen paketleri listeler. Listelenen paketlerin gerçekten gereksiz olduğunu doğruladıktan sonra npm uninstall ile kaldırın. Her kaldırılan paket, dolaylı bağımlılıklarını da (transitive dependencies) beraberinde götürür ve node_modules boyutunu küçültür. Bundle boyutuna etkisi, build sonrası bundle analyzer ile doğrulanmalıdır.

Polyfill Stratejisi ve Gereksiz Tarayıcı Desteği Temizliği

Polyfill'ler, eski tarayıcılarda desteklenmeyen JavaScript API'lerinin çalışmasını sağlayan kod parçalarıdır. 2026 itibarıyla ES2020+ özellikleri (%96+ tarayıcı desteği), Promise, fetch, Array.from ve Object.assign gibi API'ler için polyfill'ler gereksizdir. Ancak birçok proje, eski yapılandırmalardan kalan geniş polyfill bundle'larını hâlâ yüklemektedir.

Babel ve core-js yapılandırmasındaki targets ayarı, hangi tarayıcılar için polyfill üretileceğini belirler:

    
{
  "presets": [
    ["@babel/preset-env", {
      "targets": "> 0.5%, last 2 versions, not dead",
      "useBuiltIns": "usage",
      "corejs": 3
    }]
  ]
}
    

useBuiltIns: "usage" ayarı, yalnızca kodda kullanılan ve hedef tarayıcılarda desteklenmeyen API'ler için polyfill ekler. "entry" ayarına kıyasla %60-80 daha küçük polyfill bundle'ı üretir. targets değerini güncelleyerek eski tarayıcı desteğini daraltmak, polyfill yükünü doğrudan azaltır.

Console.log ve Debug Kodlarının Üretim Build'inden Temizliği

Geliştirme sürecinde eklenen console.log, console.warn, debugger ifadeleri ve geliştirici araçları entegrasyonları, üretim build'inde yer almamalıdır. Bu kodlar hem dosya boyutunu artırır hem de istemci tarafında gereksiz işlem maliyeti üretir. Özellikle döngü içindeki console.log ifadeleri, büyük veri setlerinde belirgin performans kaybına neden olur.

Terser (Webpack'in varsayılan minifier'ı) yapılandırmasında console ifadelerinin otomatik kaldırılması sağlanabilir:

    
module.exports = {
  optimization: {
    minimizer: [
      new TerserPlugin({
        terserOptions: {
          compress: {
            drop_console: true,
            drop_debugger: true,
            pure_funcs: ['console.info', 'console.debug']
          }
        }
      })
    ]
  }
};
    

drop_console: true tüm console çağrılarını kaldırır. Daha seçici yaklaşımda pure_funcs dizisiyle yalnızca belirli console metotlarını hedefleyerek console.error gibi kritik log'ları koruyabilirsiniz.

Unused CSS/JS Temizliğinin Core Web Vitals Üzerindeki Ölçülebilir Etkisi

Kullanılmayan kod temizliğinin etkisi, her Core Web Vitals metriğinde farklı biçimde tezahür eder. LCP açısından, render-blocking CSS dosyasının küçülmesi ilk paint süresini doğrudan kısaltır. 80 KB'lık bir CSS dosyasını 20 KB'a düşürmek, 3G bağlantıda 500 ms'lik LCP iyileştirmesi sağlayabilir. INP açısından, JavaScript parse ve execution süresinin azalması ana thread'in daha erken serbest kalmasını sağlar. CLS açısından ise dolaylı bir etki vardır: daha hızlı yüklenen CSS, layout kurallarının erken uygulanmasını garanti eder ve geç yükleme kaynaklı shift'leri önler.

Sahadaki gerçek tecrübemiz gösteriyor ki, kapsamlı bir unused code temizliği sonrasında ortalama iyileşme değerleri şöyle oluyor: LCP 300-800 ms iyileşme, INP 50-150 ms iyileşme, toplam transfer boyutu %30-50 azalma. Bu değerler, Search Console Core Web Vitals raporunda "kötü" kategorisinden "iyi" kategorisine geçişi sağlayacak düzeydedir.

Sürekli Temizlik Disiplini ve Teknik Borç Yönetimi

Çoğu uzman aksini iddia etse de, kullanılmayan kod temizliği tek seferlik bir operasyon değil, sürekli bakım gerektiren bir disiplindir. Her yeni bileşen, her kütüphane ekleme ve her özellik kaldırma sonrasında ölü kod birikme potansiyeli doğar. Bu birikimi kontrol altına alacak sistematik bir yaklaşım olmadan, altı ay içinde dosya boyutları temizlik öncesi seviyeye geri döner.

Bu disiplini kurmak için üç mekanizma birlikte çalışmalıdır. Birincisi, CI/CD pipeline'ında bundle boyutu bütçesi tanımlayıp her deployment öncesinde otomatik kontrol uygulamaktır. Webpack'te performance.maxAssetSize veya Lighthouse CI'daki resource-summary assertion'ları bu kapıyı oluşturur. İkincisi, üç aylık periyotlarla Coverage analizi çalıştırıp kullanılmayan kod oranını raporlamaktır. Üçüncüsü, dependency audit'i code review sürecinin zorunlu adımı haline getirmektir. Her pull request'te eklenen yeni bağımlılığın bundle boyutuna etkisi değerlendirilmeli ve alternatif çözüm araştırılmalıdır.

Teoride doğru görünen ama pratikte patlayan nokta şudur: "Bunu ileride kullanabiliriz" gerekçesiyle bırakılan her ölü kod satırı, o noktadan itibaren tüm kullanıcıların indirmek zorunda kaldığı bir yüktür. Kullanılmayan kodu silmek cesaret ister, ancak versiyon kontrol sistemi her zaman geri almayı mümkün kılar. Git'te silinen kod kaybolmaz; gereksiz dosya boyutunun kullanıcıya yüklediği maliyet ise her sayfa yüklemesinde tekrarlanır.