Kullanılmayan CSS'i Temizleme

Bir sitede kullanılmayan CSS neredeyse her zaman birikir. Tema satın alınır, içindeki slider ve portfolyo bileşenleri hiç kullanılmaz ama stilleri her sayfada iner. Bootstrap tam sürüm çağrılır, ondan sadece grid ve buton kullanılır. Eski bir kampanya sayfasının stilleri silinmez. Sonuçta 250 KB'lık bir style.css dosyasının belki 40 KB'lık kısmı gerçekten uygulanır; geri kalanı her ziyaretçiye gereksiz yere indirilir ve tarayıcı ayrıştırırken zaman harcar.

Bu yazıda kullanılmayan CSS'i nasıl ölçeceğini, hangi kuralları silmenin güvenli olduğunu, PurgeCSS gibi araçları build sürecine nasıl bağlayacağını ve en tehlikeli kısmı — JavaScript'in çalışma anında ürettiği sınıfların yanlışlıkla silinmesini — nasıl önleyeceğini anlatacağım. Sonunda WordPress gibi kaynak koduna hâkim olmadığın kurulumlarda ne yapabileceğine de değineceğim.

Kullanılmayan CSS Neden Bir Sorun#

İki ayrı maliyeti vardır. Birincisi ağ maliyetidir: dosya ne kadar büyükse indirilmesi o kadar sürer ve CSS render engelleyici olduğu için bu süre doğrudan boş ekran süresidir. Brotli ile sıkıştırıldığında CSS çok iyi küçülür, dolayısıyla ağ maliyeti çoğu zaman düşünüldüğü kadar dramatik değildir. Asıl mesele ikinci maliyettir: ayrıştırma ve eşleştirme. Tarayıcı her kuralı ayrıştırıp CSSOM'a koyar, sonra DOM'daki her öğe için hangi kuralların eşleştiğini hesaplar. On binlerce seçicili bir dosyada bu hesap, özellikle düşük güçlü telefonlarda ölçülebilir bir CPU maliyetidir.

Üçüncü ve daha az konuşulan bir maliyet de bakımdır. Hangi kuralın kullanıldığını bilmediğin bir dosyada hiçbir şeyi silmeye cesaret edemezsin; her yeni ihtiyaçta üzerine yazarsın ve dosya büyümeye devam eder. Temizlik yaptığında sadece hız değil, sonraki değişikliklerin güvenliğini de kazanırsın. Temizlik sonrası kalan dosyanın ilk ekrana ait kısmını ayırıp gömmek istersen critical CSS yazısındaki yöntem sıradaki adımdır.

Önce Ölç: Coverage Sekmesi#

Silmeden önce ölçmen gerekir, yoksa çalışan bir şeyi bozarsın. Chrome DevTools'un Coverage aracı bu iş için tasarlanmıştır ve tek bir yüklemede hangi CSS baytlarının kullanıldığını satır satır gösterir.

1. DevTools'u aç, Ctrl+Shift+P ile komut çubuğunu çağır, Show Coverage yaz ve seç.
2. Sol üstteki yeniden yükle simgesine bas; sayfa baştan yüklenir ve ölçüm başlar.
3. Listeden CSS dosyanı seç. Kırmızı çubuklar kullanılmayan, yeşil çubuklar kullanılan baytlardır.
4. Ölçüm sırasında sayfayı kaydır, menüyü aç, sekmeleri değiştir. Yeşil oran artacaktır, çünkü bu etkileşimler yeni kuralları devreye sokar.

Buradaki en önemli uyarı şudur: Coverage anlık ölçer. Bir kural, o sayfada o an uygulanmadığı için kırmızı görünür; başka bir sayfada ya da bir hover durumunda gerekli olabilir. Bu yüzden Coverage sonucunu "silinecekler listesi" olarak değil, "ne kadar israf var" göstergesi olarak kullan. Gerçek silme işini, tüm şablonlarını tarayan otomatik bir araca bırak.

# Dosya boyutlarını ve sıkıştırılmış hallerini hızlıca görmek için
ls -lh dist/assets/*.css
gzip -c dist/assets/style.css | wc -c
brotli -c -q 11 dist/assets/style.css | wc -c

PurgeCSS ile Otomatik Temizlik#

PurgeCSS, verdiğin içerik dosyalarını (HTML, JS, PHP, şablon dosyaları) tarar, içinde geçen tüm kelimeleri bir havuzda toplar ve CSS'teki seçicilerden bu havuzda karşılığı olmayanları siler. Çalışma mantığı bilinçli olarak basittir: CSS'i anlamaz, sadece metin eşleşmesine bakar. Bu basitlik hem hızının hem de en büyük tuzağının sebebidir.

npm install --save-dev purgecss

# Şablonlarda geçmeyen tüm seçicileri temizle
npx purgecss \
  --css dist/assets/style.css \
  --content "dist/**/*.html" "src/**/*.js" \
  --output dist/assets/

Build aracına bağlamak daha sürdürülebilirdir. PostCSS kullanıyorsan yapılandırma şu şekildedir:

// postcss.config.js
module.exports = {
  plugins: [
    require("@fullhuman/postcss-purgecss")({
      content: ["./src/**/*.{html,js,jsx,ts,tsx}", "./templates/**/*.php"],
      // Çalışma anında üretilen sınıfları koru
      safelist: {
        standard: ["is-active", "has-error", /^swiper-/],
        deep: [/^modal-/],
        greedy: [/^wp-block-/],
      },
      defaultExtractor: (content) => content.match(/[\w-/:]+(?<!:)/g) || [],
    }),
  ],
};

defaultExtractor satırını atlamak, Tailwind gibi md: veya hover: gibi ön ekli sınıflar kullanan kurulumlarda toplu yanlış silmeye yol açar; varsayılan çıkarıcı iki nokta içeren sınıf adlarını tanımaz. Tailwind kullanıyorsan zaten kendi içinde bu mekanizmayı barındırır ve tailwind.config dosyasındaki content alanı aynı işi görür — ayrıca PurgeCSS eklemene gerek yoktur.

Safelist Tuzağı ve Dinamik Sınıflar#

Temizliğin sizi ısıracağı tek yer burasıdır, o yüzden dikkatle oku. PurgeCSS kaynak dosyalarında metin olarak geçen sınıfları korur. Eğer JavaScript'in bir sınıf adını parça parça birleştiriyorsa, o ad hiçbir dosyada tam olarak geçmez ve stili silinir. Klasik örnek:

// TEHLİKELİ: 'btn-primary' metni hiçbir yerde tam geçmiyor
const tip = kullanici.premium ? "primary" : "secondary";
buton.className = `btn-${tip}`;

// GÜVENLİ: tam sınıf adları kaynakta geçiyor
const sinif = kullanici.premium ? "btn-primary" : "btn-secondary";
buton.className = sinif;

İkinci biçim hem PurgeCSS hem de okuyan insan için nettir. Kodu değiştiremiyorsan safelist kullanırsın ama safelist'i bir çöp kutusuna çevirme; her eklediğin desen, temizliğin kazancını azaltır. Aşağıdaki tablo hangi safelist tipinin ne yaptığını özetliyor:

Sık unutulan bir grup daha var: body.admin-bar, html.no-js gibi koşullu gövde sınıfları, animasyon isimleri (@keyframes), ve sunucu tarafında üretilen sınıflar. Silme işleminden sonra siteyi mobil, masaüstü, giriş yapmış ve yapmamış hallerinde mutlaka gez.

WordPress ve Kaynak Koda Hâkim Olmadığın Kurulumlar#

Build süreci olmayan bir WordPress sitesinde PurgeCSS'i doğrudan çalıştırmak riskli olabilir, çünkü sınıfların bir kısmı PHP içinde koşullu üretilir. Burada üç kademeli bir yaklaşım daha güvenlidir.

Birinci kademe, yüklenmemesi gerekeni hiç yüklememektir. Eklentiler kendi CSS'lerini her sayfaya ekler; iletişim formu eklentisinin stili yalnızca iletişim sayfasında gerekir. wp_dequeue_style ile bunu koşullandırabilirsin:

add_action('wp_enqueue_scripts', function () {
    // İletişim formu stilini yalnızca iletişim sayfasında bırak
    if (!is_page('iletisim')) {
        wp_dequeue_style('contact-form-7');
    }
    // Blok editörü stilleri klasik temada gereksizse
    if (!is_admin()) {
        wp_dequeue_style('wp-block-library-theme');
    }
}, 100);

İkinci kademe, önbellek eklentisinin "Unused CSS" veya "Kullanılmayan CSS'i Kaldır" özelliğidir. LiteSpeed Cache ve benzerleri sayfayı tarayıp sayfaya özel bir CSS üretir. Bu özellik güçlüdür ama açtıktan sonra tüm sayfa tiplerini elle gezip kontrol etmen şarttır. Sunucu tarafındaki önbellek ayarlarıyla birlikte nasıl kurulacağını LiteSpeed Cache yazısında bulabilirsin.

Üçüncü kademe, kalan dosyanın iyi sıkıştırılıp uzun süre önbelleklenmesidir. Temizleyemediğin baytın maliyetini en azından tekrar tekrar ödememiş olursun; .htaccess üzerinden brotli/gzip ve Cache-Control ayarlarını htaccess önbellek ve sıkıştırma yazısındaki gibi yapılandırabilirsin.

Silme Sonrası Doğrulama#

Temizlik yaptıktan sonra "site açılıyor" demek yeterli değildir; bozulan şey genellikle nadir görülen bir durumdur. Şu kontrol listesini uygula:

1. Ana sayfa, kategori, tekil içerik, iletişim ve varsa sepet/ödeme sayfalarını aç.
2. Mobil genişlikte gez — duyarlı kurallar (@media) yanlışlıkla silinmiş olabilir.
3. Menüyü aç/kapa, modal aç, form gönder, hata mesajı çıkart. Bu durumların sınıfları çalışma anında eklenir.
4. Giriş yapmış kullanıcı olarak gez; yönetici çubuğu gövdeye ekstra sınıf ekler.
5. Öncesi/sonrası dosya boyutlarını ve Lighthouse skorunu karşılaştır.

Otomatik bir güvence istiyorsan, build çıktısındaki CSS boyutuna bir üst sınır koymak basit ve etkilidir:

# 60 KB'ı aşarsa build'i kır
SIZE=$(stat -c%s dist/assets/style.css)
if [ "$SIZE" -gt 61440 ]; then
  echo "CSS bütçesi aşıldı: $SIZE bayt"
  exit 1
fi

Ölü CSS'in Tekrar Birikmesini Önlemek#

Temizlik tek seferlik bir kampanya olarak yapıldığında altı ay içinde başladığın noktaya dönersin; kalıcı çözüm, CSS'in nasıl yazıldığı ve nasıl yüklendiğiyle ilgilidir. En etkili alışkanlık, stilleri tek bir dev dosyada değil bileşen başına tutmaktır. Bir kart bileşeninin stili o bileşenin yanında durursa, bileşen projeden çıktığında stili de onunla birlikte çıkar; kimse "bu kural hâlâ kullanılıyor mu" diye tahmin yürütmek zorunda kalmaz.

İkinci alışkanlık, üçüncü parti CSS'i tam sürüm olarak çağırmamaktır. Bootstrap'in yalnızca grid ve buton bileşenlerini kullanıyorsan tam paketi bağlamak yerine kaynak SCSS'ten sadece ihtiyacın olan parçaları içeri al; bu, sonradan temizlemekten çok daha temiz bir sonuç verir çünkü ölü kurallar hiç üretilmez.

// Tam paket yerine parça parça içeri alma
@import "bootstrap/scss/functions";
@import "bootstrap/scss/variables";
@import "bootstrap/scss/mixins";
@import "bootstrap/scss/grid";     // sadece grid
@import "bootstrap/scss/buttons";  // sadece butonlar

Üçüncü alışkanlık ölçümü otomatikleştirmektir. Build çıktısındaki CSS boyutunu bir eşikle karşılaştıran küçük bir kontrol, dosyanın sessizce büyümesini engeller; bir eklenti ya da kütüphane beklenmedik bir boyut getirdiğinde bunu aylar sonra kullanıcı şikayetiyle değil, aynı gün build çıktısında görürsün. Aynı bütçe mantığını JavaScript tarafında da uygulamak istersen bundle boyutunu küçültme yazısındaki eşik kurma örnekleri doğrudan uyarlanabilir.

Son olarak, silinmesi riskli görünen ama gerçekten kullanılmayan blokları hemen atmak yerine bir sürüm boyunca yorum satırına almak yerine ayrı bir dosyaya taşımak işe yarar: bir şey bozulursa geri almak saniyeler sürer, bozulmazsa bir sonraki sürümde dosyayı tamamen silersin.

Sık Yapılan Hatalar#

Coverage çıktısını doğrudan silme listesi sanmak. Tek bir sayfa yüklemesindeki ölçüm, sitenin tamamını temsil etmez. Bir kuralın kırmızı görünmesi, hiçbir yerde kullanılmadığı anlamına gelmez.

Safelist'i şişirmek. "Emin olmak için" yüzlerce desen eklendiğinde temizlik anlamsızlaşır. Bunun yerine dinamik sınıf üretimini kodda düzeltmek kalıcı çözümdür.

Üçüncü parti CSS'i temizlemeye çalışmak. Harici bir alan adından gelen stili (harita, ödeme formu, chat widget) sen küçültemezsin. Buradaki doğru hamle temizlik değil, o kaynağı gerektiğinde yüklemektir.

Temizliği bir kerelik iş sanmak. Yeni bir eklenti kurulduğunda ya da tema güncellendiğinde ölü CSS geri gelir. Temizliği build sürecine bağlamazsan altı ay sonra aynı yerdesin. Aynı mantığın JavaScript tarafındaki karşılığı için tree shaking yazısına bakabilirsin.

Animasyonları ve @font-face bloklarını unutmak. Bazı çıkarıcılar @keyframes adlarını ve font tanımlarını sınıf saymaz; silindiklerinde animasyon durur ya da yazı tipi düşer.

Sıkça Sorulan Sorular#

Kullanılmayan CSS'i temizlemek ne kadar hız kazandırır#

Kazanç, temizlenen oranın ve kullanıcının bağlantı hızının çarpımıdır. 300 KB'lık bir dosyayı 50 KB'a indirdiğinde, sıkıştırma sonrası ağdan tasarruf birkaç on kilobayt olur ve yavaş bir mobil bağlantıda 100-300 ms arası bir iyileşme görürsün. Buna ek olarak düşük güçlü cihazlarda ayrıştırma ve stil eşleştirme süresi de kısalır; bu, sayının gösterdiğinden daha çok hissedilen bir kazançtır.

PurgeCSS sitemi bozar mı#

Bozabilir, ama nedeni tahmin edilebilir: JavaScript veya sunucu tarafında parça parça üretilen sınıf adları kaynak dosyalarda tam metin olarak geçmediği için silinir. Bu riski iki şekilde yönetirsin — sınıf adlarını kodda tam yaz ya da gerçekten dinamik olanları safelist'e ekle. Temizlik sonrası tüm sayfa tiplerini ve etkileşimli durumları elle gezmek, otomatik testin yerini tutan en pratik güvencedir.

Tailwind kullanıyorsam ayrıca PurgeCSS gerekir mi#

Hayır. Tailwind, sürüm 3 ile birlikte yalnızca kaynağında gördüğü sınıfları üretir; yani "temizlik" adımı üretimin kendisine gömülüdür. Yapman gereken tek şey tailwind.config dosyasındaki content dizisinin tüm şablon yollarını kapsadığından emin olmaktır. Üstüne bir de PurgeCSS eklemek gereksizdir ve iki farklı çıkarıcının çakışması yüzünden yanlış silmelere yol açabilir.

Eklentilerin CSS'ini nasıl kaldırırım#

WordPress'te wp_dequeue_style ile bir eklentinin stilini koşullu olarak devre dışı bırakabilirsin; örneğin bir form eklentisinin CSS'ini yalnızca form bulunan sayfalarda bırakırsın. Bunun için eklentinin kayıt ettiği tanıtıcıyı (handle) bilmen gerekir; sayfa kaynağındaki id niteliğinde -css ekiyle görünür. Kaldırdıktan sonra ilgili sayfayı mutlaka kontrol et, çünkü bazı eklentiler kritik düzen kurallarını da aynı dosyada tutar.

Kritik CSS ile temizliği hangi sırayla yapmalıyım#

Önce temizlik, sonra kritik CSS üretimi. Kritik stil, mevcut CSS'ten türetilir; temizlemeden önce üretirsen ölü kuralların bir kısmı kritik bloğa da sızar ve inline blok gereksiz yere şişer. Temizliği bitirdikten sonra kritik CSS aracını çalıştırdığında hem daha küçük hem de daha isabetli bir blok elde edersin.

Kullanılmayan CSS'i tespit eden ücretsiz bir araç var mı#

Evet, en yakınında olanı Chrome DevTools'un Coverage sekmesidir ve hiçbir kurulum gerektirmez. Komut satırında çalışan PurgeCSS de açık kaynak ve ücretsizdir. Online tarayıcılar da vardır ancak çoğu tek bir URL'yi ölçer ve JavaScript ile üretilen sınıfları göremez; bu yüzden onların çıktısını referans olarak alıp silme kararını yerel araçlarla vermek daha güvenlidir.

Kapanış#

Kullanılmayan CSS temizliği, en az çabayla en somut kazancı veren optimizasyonlardan biridir ama körlemesine yapılırsa sitenin görünümünü bozar. Aklında tutman gereken dört alışkanlık şudur: önce Coverage ile israfın büyüklüğünü ölç, silmeyi tüm şablonları tarayan otomatik bir araca bırak, dinamik sınıf üretimini kodda düzelterek safelist ihtiyacını en aza indir ve temizliği build sürecine bağlayarak ölü kuralların tekrar birikmesini engelle.

Bu tür optimizasyonlar sunucunun ilk yanıt süresi makul olduğunda gerçekten hissedilir. Hızlı diskli ve modern web sunuculu web hosting ya da WordPress hosting paketlerimiz bu tabanı verir; build sürecini kendi kontrolünde çalıştırmak istersen tam root erişimli VDS sunucularımızı tercih edebilir, temizlik ve önbellek yapılandırmasını bizim üstlenmemizi isterseniz sunucu yönetimi hizmetimize bakabilirsin.