HTML Kod Optimizasyonunun Temel Kuralları
HTML tarafındaki küçük iyileştirmeler, ağ üzerinden taşınan bayt miktarını azaltır, tarayıcının DOM oluşturma süresini kısaltır ve First Contentful Paint gibi metriklerde doğrudan kazanım sağlar. Amaç; gereksiz işaretlemeyi ve tekrarı ortadan kaldırmak, semantik yapıyı koruyarak minimum HTML ile maksimum anlamı taşımaktır. Burada bahsedilen optimizasyon yalnızca hız artışı için değil, aynı zamanda kodun bakım kolaylığı, SEO uyumluluğu ve erişilebilirlik standartlarını da kapsar. İyi optimize edilmiş bir HTML, mobil cihazlarda düşük bant genişliği ortamlarında bile hızlı açılır, tarayıcı önbelleğini daha verimli kullanır ve arama motorları tarafından daha kolay taranır. Aşağıdaki ilkeler, hem statik siteler hem de SPA/SSR tabanlı projeler için güvenli ve ölçeklenebilir bir başlangıç oluşturur.
1) Gereksiz işaretlemeyi kaldır
İç içe gereksiz div katmanları, boş span’lar ve sadece stil amaçlı eklenen etiketler DOM ağacını şişirir. Her etiket tarayıcıda bir layout maliyeti yaratır ve bu da sayfanın render süresini uzatır. Tasarımın yapısal kısmını semantik etiketlerle (header, main, nav, section, article, footer) çözmek, hem erişilebilirliği hem render performansını iyileştirir. “Bir bileşen = bir anlam” prensibiyle yazmak, hem kod tekrarını azaltır hem de gelecekte tasarım değişikliklerini yönetmeyi kolaylaştırır. Görsel düzenlemeler için CSS’in gücünden faydalanarak HTML’nin yalnızca içerik anlamını taşımasını sağlamak uzun vadede performans ve bakım avantajı getirir.
2) HTML’yi küçült (minify) ve sıkıştır
Yayın hattında HTML dosyalarını boşluk, satır sonu ve yorumlardan arındırmak ağ yükünü düşürür. Özellikle büyük ölçekli sayfalarda, bu işlem tek başına %20-30 oranında dosya boyutu tasarrufu sağlayabilir. Sunucu tarafında Brotli (varsa brotli-11 statik) veya Gzip ile sıkıştırma açık olmalıdır. Bu sıkıştırma yöntemleri, tarayıcı ile sunucu arasındaki veri transferini minimize ederek yükleme sürelerini kısaltır. Note: Geliştirici deneyimi için minify işlemini yalnızca üretim çıktısında uygulayın; geliştirme ortamında okunabilir tutmak hata ayıklama sürecini kolaylaştırır.
3) Render’ı engelleyen head içeriğini sadeleştir
<head> içerisindeki her blok, ilk boyama öncesinde değerlendirilir ve bu da critical rendering path süresini doğrudan etkiler. Kullanmadığınız <meta> etiketlerini kaldırın, gereksiz @import kullanımlarından kaçının. Kritik CSS’yi küçük bir blok olarak satır içi verip kalan stilleri ertelenmiş yükleyin; <link rel="preload"> ile hero görseli ve başlık fontlarını önceliklendirin. Büyük ikon setlerini font yerine SVG sprite ile kullanmak, hem dosya boyutunu hem de render süresini azaltır. Bu yaklaşım, kullanıcıya ilk anlamlı boyamayı (FMP) daha hızlı sunmanızı sağlar.
4) Atributeleri ve inline kodu optimize et
Varsayılan değerleri yazmayın (type="text" gibi) çünkü tarayıcı zaten bu değerleri varsayılan olarak kullanır. Boş alt yerine anlamlı alternatif metin verin; erişilebilirlik hem kullanıcı deneyimi hem de SEO için kazançtır. Inline style ve onclick gibi inline handler’lardan kaçının; bu yaklaşım HTML’yi davranıştan ayırarak (separation of concerns) önbellekleme ve tekrar kullanımda esneklik sağlar. Çok kullanılan bileşenlerde tekrar eden atributeleri kısaltılmış yardımcı sınıflarla çözmek hem kodu okunabilir kılar hem de tekrarları azaltır.
5) Kaynakları doğru sırala
HTML, tarayıcıya “önce ne yüklenecek?” talimatını verir. <script defer> ile uygulama JavaScript’ini HTML parse bittikten sonra çalıştırın; yalnızca gerçekten paralel indirilmesini istediğiniz küçük, bağımsız script’lerde async kullanın. CSS’yi bölüyorsanız, ilk görünür alanı kapsayacak kadarını inline verin, geri kalanı media hilesi (media="print" + onload) veya preload ile yükleyin. Bu sayede kullanıcıya hızlı bir ilk render sunarken, tüm sayfa işlevselliğini arka planda tamamlayabilirsiniz.
Minimal DOM
Gereksiz katmanları temizleyin; semantik etiketler ve net hiyerarşi ile tarayıcıya daha az iş bırakın. Bu yaklaşım hem yükleme süresini hem de hafıza tüketimini düşürür.
Hafif Head
Kritik olmayan link/script’leri erteleyin; preload ile kahraman (hero) varlıklarını öne çekin ve kullanıcıya daha hızlı ilk görseli sunun.
Önbellek-Dostu HTML
HTML’yi kısa Cache-Control + ETag ile doğrulayın; asset’leri uzun TTL + dosya adı hash’leriyle yönetin, böylece gereksiz veri transferini önleyin.
Hızlı Kontrol Listesi
Minify + Brotli • Semantik etiket • Kritik CSS inline • Script defer • Preload ile font/hero görsel • Gereksiz meta/@import temizliği.
CSS Dosyalarını Küçültme (Minify) Teknikleri
CSS, hem indirilen bayt hem de recalculate style maliyeti üzerinden performansı etkiler. Hedef; üretim çıktısında minimum boyutlu, tekrarsız ve yalnızca gereken kuralları içeren bir CSS üretmektir. Bunu üç aşamada düşünebilirsiniz: küçültme (minify), temizleme (purge/tree-shake) ve parçalama/önceliklendirme.
1) Küçültme: boşluk, yorum, isim kısaltma
Üretim derlemesinde CSS’den boşluklar, satır sonları, yorumlar ve gereksiz noktalı virgüller kaldırılır. Birçok araç; kural birleştirme, sıfır birim sadeleştirme (0px → 0), renk kısaltma (#ffffff → #fff) ve hatta identifier sıkıştırma yapabilir. Modern seçenekler arasında Lightning CSS, esbuild (minify), cssnano ve csso bulunur. Amaç; işlevi bozmadan en küçük boyutu elde etmektir.
2) Temizleme: kullanılmayan kuralları at (purge)
Tasarım sistemleri ve UI kit’ler hızlı büyür; ancak sayfa başına aktif kullanılan sınıf oranı düşüktür. PurgeCSS tarzı araçlarla HTML/JS şablonlarınızı taratıp kullanılmayan sınıfları atın. Dinamik sınıf üretimi (ör. koşullu class isimleri) varsa safelist tanımlayın ki gerekli kurallar silinmesin. CSS-in-JS kullanıyorsanız derleme sırasında “dead code elimination” desteklerini etkinleştirin.
3) Parçalama ve önceliklendirme
Tek devasa bir stylesheet yerine, rotalara veya üst düzey bileşen gruplarına ayrılmış paketler üretin. İlk görünür alan için gereken “kritik CSS”’yi küçük bir blok halinde inline verin; geri kalanı non-critical olarak media hilesi veya preload ile sonradan yükleyin. Bu yaklaşım, mobilde LCP’yi düşürür ve ilk boyamayı hızlandırır.
4) @import ve tekrarlar: birleştir, sadeleştir
@import zincirleri ek RTT gecikmesi doğurur. Derleme aşamasında tüm import’ları tek dosyada toplayın. Yinelenen kuralları (aynı seçici için dağınık deklarasyonlar) araçlarla birleştirin; özgüllük (specificity) savaşlarından kaçınmak için katmanlı mimari (@layer veya BEM/ITCSS) uygulayın. Böylece gelecekteki bakım maliyeti ve regresyon riski azalır.
Minify + Gelişmiş Optimizasyon
cssnano/csso gibi araçlarla kural birleştirme, renk ve birim sadeleştirme; kaynak boyutunda anlık düşüş.
Purge (Tree-Shaking)
Kullanılmayan sınıfları at; dinamik sınıflar için safelist. Çoğu projede %50+ küçülme olağan.
Route Bazlı Paketleme
Kritik CSS inline, geri kalanı erteli; sayfa başına minimum CSS ile LCP/CLS üzerindeki yükü azalt.
Hızlı Kontrol Listesi
Minify etkin • Purge ile kullanılmayan sınıflar temiz • @import’lar derlemede birleşik • Kritik CSS inline • Non-critical CSS erteli.
JavaScript Dosyalarını Küçültme ve Birleştirme Yöntemleri
JavaScript, hem indirme hem de parse/compile/execute aşamalarında maliyetlidir. Bu yüzden üretim hattında iki hedefiniz olmalı: baytları azaltmak ve tarayıcının işini kolaylaştırmak. Minify işlemi (boşluk/yorum atma, isim kısaltma) ağ yükünü düşürürken; akıllı paketleme (bundle/splitting) gereksiz kodun istemciye hiç gitmemesini sağlar. Sonuç, daha düşük Download, daha kısa Parse/Compile ve daha hızlı ilk etkileşimdir (INP/TBT iyileşir).
Minify: Baytları küçült, anlamı koru
Modern araçlar (esbuild, Terser, SWC, Rollup, webpack minimize) üretim derlemesinde boşlukları/yorumları atar, ifadeleri kısaltır ve ölü kodu (dead code) eler. ES2017+ sözdizimi kullanıyorsanız derleyicinin target ayarını tarayıcı matrisinize uygun seçin; aksi takdirde gereksiz polyfill ve transpile yükü oluşur. Kaynak haritasını (source map) prod’da kapatın veya ayrı yükleyin; boyutu düşürür, iç kodu sızdırma riskini azaltır.
Bundle stratejisi: Tek dev paket yerine akıllı bölme
Tek parça büyük bir bundle, ilk ziyaret maliyetini şişirir. Bunun yerine code splitting uygulayın: route başına paket (örn. /product, /checkout) ve lazy import’lar. Üçüncü taraf kütüphaneleri (chart, map, editor) yalnızca gerektiği sayfalarda dynamic import ile yükleyin. Vendor ve app kodunu ayırmak, uzun süreli önbellekleme (hash’li dosya + immutable) için idealdir; uygulama değişse bile vendor sabit kalır, kullanıcı yeniden indirmez.
Tree-shaking ve dead code elimination
ES Module (ESM) yapısı, kullanılmayan export’ların paket dışında kalmasına izin verir. Kütüphaneleri sideEffects: false beyanı olan sürümlerden tercih edin. CommonJS kullanan eski paketlerde tree-shaking sınırlıdır; mümkünse ESM muadiline geçin. Uygulama içinde process.env.NODE_ENV bayraklarıyla geliştirme yalnız kodu (log/propTypes) üretimden çıkarın.
Minify + Mangle
Terser/SWC ile isim kısaltma ve ifade sadeleştirme; tipik %15–30 küçülme.
Code Splitting
Route ve özellik bazlı bölme; ilk yükte yalnızca gereken kodu gönderin.
Tree-shaking
ESM ve sideEffects ile kullanılmayan export’ları paket dışına it.
Üçüncü taraf bağımlılıklar: Boyutu yönet
Büyük kütüphaneleri (moment, lodash, charting) “tükettiğin kadar öde” yaklaşımıyla kullanın: lodash-es ve adlandırılmış import; tarih/fonksiyon yardımcıları için yerel Intl API’leri; ikon setlerinde SVG sprite. Paket yöneticinizde why / analyze eklentileriyle bundle grafiğini görüp ağır bağımlılıkları tespit edin.
HTTP katmanı: Önbellek ve iletim
Hash’li dosyaları Cache-Control: public, max-age=31536000, immutable ile yayınlayın; HTML kısa süreli/no-cache olsun. HTTP/2/3 altında çok sayıda küçük parça taşımak sorun değildir; bu yüzden aşırı birleştirme yerine anlamlı bölme daha verimli sonuç verir. İlk ekranda gereken kritik modülleri modulepreload ile öne çekebilirsiniz.
Hızlı kontrol listesi
ESM + tree-shaking • Route bazlı splitting • Dynamic import • Minify/Mangle • Vendor ayrımı • Uzun TTL + hash’li dosya • Source map prod’da kapalı.
Kullanılmayan CSS ve JS Kodlarını Temizleme (Purge)
Projeler büyüdükçe stil ve script katmanı şişer; her sayfa yalnızca küçük bir kısmını kullanır. Bu “ölü ağırlık”, indirme ve yürütme maliyeti getirir. Purge/Tree-shaking, üretim çıktınızdan kullanılmayan kuralları ve fonksiyonları atarak hem dosya boyutunu hem de parse/execute süresini düşürür. Doğru yapılandırıldığında, özellikle CSS’te %50+ küçülme görmek olağandır.
CSS purge: Şablona bakıp gereksizi at
PurgeCSS veya entegre çözümler (Tailwind JIT, PostCSS eklentileri) HTML/JS/TSX şablonlarınızı tarar, kullanılmayan sınıfları siler. Dinamik sınıf üretimi yaptığınız durumlarda (koşullu class, CMS içeriklerinden gelen sınıflar) safelist tanımlayın. Stil sisteminizi katmanlara ayırın (base, components, utilities) ve “kritik CSS”’yi küçük, geri kalanını erteli olacak şekilde bölün; purge işleminden önce kritik bloğu belirlemek güvenlidir.
JS tarafında temizlik: Import’tan başlayın
Tree-shaking, kullanılmayan export’ları atmanın temelidir; bunun için ESM ve pure anotasyonları gerekir. API’leri “geniş import” yerine seçici kullanın (import { pick } from 'lodash-es'). Dead code elimination için process.env.NODE_ENV bayraklarıyla geliştirme yalnız kodu ayıklayın; özellik bayrakları (feature flags) ile devre dışı modülleri paket dışında bırakın.
Üçüncü taraf ve CMS kaynaklı şişkinlik
A/B test, reklam, analitik snippet’leri en çok unutulan yüklerdir. Kullanım dışı deneyleri kaldırın, snippet’leri defer/koşullu yükletin veya sunucu tarafına taşıyın. CMS bileşenlerinde kullanılmayan şablon/tema varlıklarını (eski galeriler, ikon setleri) yayın hattından çıkarın; “herkese aynı CSS/JS” yerine şablon bazlı dağıtım yapın.
PurgeCSS / JIT
Şablon tarama + safelist ile güvenli temizlik; CSS boyutunda dramatik düşüş.
Seçici Import
Geniş paketleri parça parça kullan; tree-shaking’e uygun ESM sürümleri tercih et.
Güvenli Liste
Koşullu/dinamik sınıfları safelist’e ekleyerek yanlış silmeleri önle.
Süreç ve doğrulama
Temizlik öncesi/sonrası boyut ve metrikleri karşılaştırın (bundle analyzer, Lighthouse). Görsel regresyon ve kritik akış testleriyle (checkout, lead form) UI bozulmalarını yakalayın. CI’da “boyut bütçesi” koyun: top CSS ≤ 60KB, top JS ≤ 170KB gibi. Eşik aşılırsa uyarı verin ya da derlemeyi durdurun.
Hızlı kontrol listesi
PurgeCSS + safelist • ESM + tree-shaking • Seçici import • Snippet’leri gözden geçir • Boyut bütçesi + CI kontrolü.
Kodun Tarayıcıya Yüklenme Sırasını Düzenleme (defer/async)
Tarayıcı, HTML’yi yukarıdan aşağı okurken CSS ve bloklayıcı JavaScript yüzünden çizimi (render) durdurabilir. Performansın anahtarı, ilk görünür alanı (above-the-fold) hızlı boyamak ve etkileşime girmeden önce gerekmeyen kaynakları ertelemektir. Bu nedenle script’lerinizi defer/async, modül yapısı ve preload/prefetch önceliklendirmesiyle düzenlemek büyük kazanç sağlar.
defer vs async: Gerçek fark
async işaretli script, indirildiği an çalışır; HTML parse akışını kesebilir ve çalıştırma sırası belirsizdir. Analitik, reklam, A/B test gibi bağımsız üçüncü taraf script’ler için idealdir. defer işaretli script ise HTML parse tamamlandıktan sonra, sırayı koruyarak çalışır; sayfa çizimini engellemez. Uygulama kodu (app bundle) ve birbirine bağımlı dosyalar için güvenli tercihtir.
ES Modules ile yükleme stratejisi
<script type="module"> tarayıcıda doğal olarak deferred davranır ve dependency graph üzerinden alt modülleri getirir. Modern tarayıcılar için “module”, eski tarayıcılar için nomodule yedeği vererek çift hedefli dağıtım yapabilirsiniz. Kritik modülleri öne çekmek için <link rel="modulepreload" href="/app.js"> kullanımı, ilk etkileşim gecikmesini düşürür.
Kaynak önceliklendirme: preload, prefetch, fetchpriority
preload kritik CSS/JS/font/görseli yüksek öncelikle indirir; prefetch ise bir sonraki sayfa/etkileşim için boşta indirir. Kahraman (hero) görseli, ana font ve app bundle için preload mantıklıdır. fetchpriority="high|low" ipucu (destekleyen tarayıcılarda) tarayıcıya hangi kaynağa öncelik vereceğini söyler. Gereksiz preload kalabalığı, kritik olmayan kaynakları da öne alıp ters etki yapabilir; ölçerek ilerleyin.
Başlık (head) ve gövde (body) yerleşimi
CSS daima <head> içinde olmalı (bloklayıcı ama zorunlu); kritik kısmı inline, kalanı erteli yükleyin. Uygulama JS’si defer ile <head>’de ya da <body> sonunda olabilir. Üçüncü taraf script’ler mümkünse async ve koşullu yükleme ile. Inline <script>’ta defer çalışmaz; defer yalnız harici dosyalarda etkilidir.
Uygulama JS: defer
Çalıştırma sırasını korur, parse’ı engellemez. Birbirine bağımlı bundle’lar için güvenlidir.
3. Taraf Script: async
Bağımsız ve kritik olmayan snippet’ler için ağ geldiği anda çalıştır; etkileşimi bloklama.
Ön Yükleme: preload/modulepreload
Kahraman varlıkları ve ana modülü erken indirerek LCP ve INP’yi iyileştir.
Pratik yükleme sırası (öneri)
- Head: kritik CSS (inline), ana stylesheet, kritik fontlar (
preload+font-display: swap), app JSdeferveyatype="module". - Body sonu: etkileşim sonrası gereken modüller (
dynamic import()), üçüncü tarafasyncscript’ler. - Gelecek sayfa: route tahmini ile
prefetch/prerender(ölçerek kullanın).
Hızlı kontrol listesi
defer = app kodu • async = bağımsız 3P • kritik varlıklar için preload • modüller için modulepreload • gereksiz preload’dan kaçın.
async yaptığınızda çalıştırma sırası bozulur. Bağımlı zincirlerde defer veya tek bundle kullanın. Kodun Okunabilirliğini Bozmadan Performans Artırma
Performans kazanırken geliştirilebilirlikten ödün vermek uzun vadede daha büyük maliyet doğurur. Doğru yaklaşım; geliştirme (dev) ve üretim (prod) çıktısını ayırmak, ekip içi standartlarla okunabilir kod yazıp prod’da otomatik küçültme ve paketlemeye bırakmaktır. Böylece günlük iş akışı temiz kalır, son kullanıcı ise en küçük ve en hızlı çıktıyı alır.
Dev vs Prod: İki farklı hedef
Geliştirme ortamında: formatlı kod, açıklayıcı değişken adları, kapsamlı yorumlar, source map açık, sıkı lint kuralları (ESLint/Stylelint). Üretimde: minify/mangle, dead code elimination, tree-shaking, source map kapalı veya ayrı host, hash’li dosya adları ve uzun TTL. Bu ayrımı build komutlarıyla otomatikleştirin (NODE_ENV bayrağı).
Okunabilir kalıp performanslı kal
- Kompozisyon: Küçük, tek amaçlı bileşenler; tekrar eden desenleri yardımcı fonksiyonlara taşıyın.
- Seçici optimizasyon: Mikro hileler yerine ölçüm → darboğaz yaklaşımı. Profillemeden optimize etmeyin.
- Standartlar: Prettier + ESLint/Stylelint ile tutarlı biçim; PR’da otomatik fix/ci engeli.
- Tür güvenliği: TS/JSDoc ile niyetinizi belgeleyin; bundler tree-shaking için daha cesur davranır.
Yorum ve dokümantasyon: Az, öz, güncel
Yorumlar “neden”i açıklamalı; “ne” zaten koddadır. Performans gerekçeli kararların (ör. “bu modülü dinamik yüklüyoruz çünkü INP düşüyordu”) kısa notlarını bırakın. Dokümantasyonu repo kökünde PERFORMANCE.md gibi tek yerde toplayın; ekip yeni PR’larda aynı kalıpları tekrarlar.
Kodu böl, veriyi küçült
Okunabilirliği bozmadan performans için kodu route/özellik bazlı parçalara ayırın; ağır bileşenleri dinamik yükleyin. JSON/konfig dosyalarını minimal tutun; yalnız gereken alanları gönderin. İkon/asset tarafında paket yerine SVG sprite veya “gerektikçe indirme” stratejisi kullanın.
Takım Disiplini
Prettier + ESLint/Stylelint + commit hook (lint-staged) ile standartları otomatik uygula.
Modüler Mimari
Küçük modüller + dynamic import; ilk yük hafif, bakım kolay.
Ölç, Sonra Optimize Et
Lighthouse/WebPageTest/Profiler ile darboğazı doğrula; değişiklik sonrası aynı senaryoda yeniden ölç.
Hızlı kontrol listesi
Dev: okunabilir + map açık • Prod: minify + tree-shake + uzun TTL • Standart: lint/format • Böl: dynamic import • Belgele: nedenini yaz.
Inline ve External Dosya Kullanımı Arasındaki Denge
Kod optimizasyonunun temel taşlarından biri, stil ve betiklerin sayfaya nasıl dahil edileceğini doğru seçmektir. Inline yaklaşımda CSS/JS doğrudan HTML içinde gömülür; external yaklaşımda ise ayrı dosyalarda tutulup <link> ve <script src> ile çağrılır. Performans açısından amaç; ilk etkileşim süresini (FCP, LCP) kısaltırken, tekrar ziyaretlerde tarayıcı önbelleğinin gücünden faydalanmaktır. Kritik nokta, her şeyin inline olmasıyla her şeyin harici olması arasında bilinçli bir denge kurmaktır.
Inline kullanımının en güçlü tarafı, ek HTTP isteği oluşturmamasıdır. Özellikle critical CSS için idealdir: katmanlı CSS mimarisinde above-the-fold için gerekli minimal kuralları (tipografi, grid başlangıcı, header, hero) inline vererek CSS bloklamasını düşürürsün. Böylece tarayıcı DOM’u boyarken beklemek zorunda kalmaz ve kullanıcı çok daha hızlı bir ilk boyama görür. Ancak tüm stilleri inline vermek HTML boyutunu şişirir, sayfa her açılışta bu kod tekrar indirilir ve Cache-Control ile uzun süreli önbelleklemek mümkün olmaz.
External dosyalar ise yeniden kullanım ve önbellek avantajı sağlar. Çok sayfalı yapılarda tek bir app.min.css ve app.min.js dosyasının sayfalar arasında paylaştırılması, ikinci sayfadan itibaren sıfıra yakın indirme maliyeti demektir. HTTP/2 ve HTTP/3 ile birlikte bağlantı çoğullama geldiği için birden çok küçük dosya göndermek eskisi kadar maliyetli değil; yine de bundle sayısını makul tutmak iyi pratiktir. Gerekirse code splitting ile rotalara göre parça parça dosyalar üretip giriş sayfasının yükünü azaltabilirsin.
Doğru denge için pratik yol haritası: 1) Kritik CSS’i 6–12 KB aralığında inline ver; geri kalan stil katmanlarını harici dosyaya taşı. 2) JavaScript’i render bloklamayacak biçimde yükle: <script src="app.js" defer> kullan, üçüncü parti betikleri mümkünse async ile arkaya at. 3) Preload ve prefetch ipuçlarını ölçümle kullan: hero görseli, ana yazı tipi veya kritik CSS için <link rel="preload"> doğru konumlandırıldığında LCP’yi belirgin iyileştirir. 4) Inline SVG simgeler, küçük kritik ikonlar için mantıklı; ancak onlarca SVG’yi inline etmek HTML’i ağırlaştırır. Büyük ikon setlerinde sprite tercih et.
Yan etkiler ve kaçınma: Çok fazla inline JS yönetimi zorlaştırır, XSS risk yüzeyini büyütebilir ve CSP politikalarını karmaşıklaştırabilir (ör. unsafe-inline gereksinimi). Bu nedenle olay bağlayıcılarını (onclick vb.) HTML’den temizleyip modüler JS içinde tutmak daha güvenli ve sürdürülebilirdir. Stil tarafında da inline style="" ile tekil çözümler yerine bileşen bazlı sınıflar kullan; bu, tekrarları azaltır ve purge süreçlerini kolaylaştırır.
Son olarak, denge veriye dayanmalıdır. Lighthouse ve WebPageTest çıktılarında render-blocking resources, unused CSS/JS ve transfer size metriklerini takip et; FCP, LCP ve TBT’ye duyarlı bir şekilde kritik alanı inline tutup kalanını harici ve önbellekli servis ettiğinde hem ilk yükleme hızlanır hem de gezinme deneyimi akıcı kalır. Kısacası; kritik olanı inline, kalanı external—ama her zaman ölçerek.
Kod Tekrarı (Duplicate) Tespit Etme ve Temizleme
Kod tekrarı; dosya boyutlarını büyüten, bakım maliyetini artıran ve hata riskini yükselten görünmez bir borçtur. Minify ve bundle işlemleri dosyayı küçültür ama mükerrer mantığı ortadan kaldırmaz; asıl kazanç, yinelenen kalıpları tek kaynakta toplayarak gelir. Amaç; hem CSS hem JS’de ortak kuralları soyutlamak, paylaşılan fonksiyonları modüler hale getirmek ve kullanılmayan kodu arındırmaktır.
Tespit için araç seti: JavaScript tarafında ESLint (kural tabanlı tekrar ve anti-pattern yakalama), ts-prune veya unused-exports (TypeScript projelerinde atıl dışa aktarımları bulma), webpack-bundle-analyzer (paket içinde tekrar eden bağımlılıkları görselleştirme) güçlü başlangıç sağlar. CSS’te Stylelint ve csstree tabanlı analizler yinelenen kuralları ve erişilemeyen seçicileri işaretler. Framework kullanıyorsan, tree-shakeable kütüphaneleri (örn. ESM modülleri) tercih etmek, tekrarın paket seviyesinde önüne geçer.
Temizleme stratejisi üç adımlıdır: 1) Normalize et: Tasarım sistemini tanımla (renk değişkenleri, tipografi ölçüleri, spacing ölçeği). Rastgele hex değerlerini ve keyfi margin/padding’leri ortadan kaldırıp tutarlı token’lar kullan. 2) Modülerleştir: JS’de tekrarlanan yardımcıları (formatlayıcılar, isValid kontrolleri, fetch sarmalayıcıları) tek bir yardımcı modülde topla; CSS’te utility-first yaklaşım veya bileşen tabanlı sınıflarla tekrar eden kuralları ortaklaştır. 3) Arındır: Build aşamasında purge (CSS için içerik tarama), dead code elimination ve tree shaking uygulayarak erişilmeyen kodu paket dışına it.
Pratik ipuçları: Tekrar eden fetch çağrılarını ortak bir apiClient altında topla; otomatik yeniden deneme, zaman aşımı ve hata ele alma tek yerden yönetilsin. Form doğrulamada aynı desenleri kopyalamak yerine şema tabanlı bir doğrulayıcıyla (örn. Zod/Yup) kuralları tanımla ve her formda yeniden kullan. CSS’te aynı gradyanların beş farklı varyantını yazmak yerine CSS değişkenleriyle tema katmanı kur. İkon kullanımında farklı paketleri karıştırmak paket boyutunu şişirir; tek bir ikon seti seç ve ağaç sarsılabilir (tree-shakable) içe aktarımlar kullan.
Ölçüm ve güvence: CI sürecine bundle analizini otomatik ekle; her PR’da toplam boyut, first party vs third party yüzdeleri ve “kullanılmayan kod” metriği raporlansın. Eşik aşılırsa PR “degrade” etiketiyle uyarı versin. Stil tarafında coverage (Chrome DevTools Coverage) ile gerçek kullanım oranını takip et; kritik sayfalarda %60–70’in altı alarmdır. Zamanla tekrarlar geri gelir; bu yüzden linter kuralları, styleguide ve kod inceleme kontrol listesiyle koruma hattı oluştur.
Sonuç olarak, tekrarı azaltmak yalnızca kilobyte tasarrufu değil; daha az hata, daha hızlı derleme, daha sürdürülebilir bir kod tabanı demektir. Optimize edilmiş bir bundle, küçültmenin ötesine geçip gereksiz mantığı da budar; gerçek hız kazanımı burada başlar.
Versiyon Kontrol Sistemleri ile Optimizasyon Süreçlerini Yönetme
Kod küçültme (minify), birleştirme (bundle), parçalara ayırma (code splitting), purge ve ağaç sarsma (tree-shaking) gibi işlemler, doğru yönetilmediğinde geri dönüşü zor deneylere dönüşebilir. Git tabanlı bir iş akışıyla optimizasyonu sistematik hale getirmek; ölç, değiştir, karşılaştır, geri al döngülerini güvenle çalıştırmanı sağlar. Hedef; her performans değişikliğini izlenebilir kılmak ve riskleri izole etmektir.
Branch stratejisi ve deney izolasyonu
Performans denemeleri için short-lived feature branch’ler aç; örneğin feat/lcp-preload-fonts, chore/enable-http3 gibi açık isimler kullan. Her dalda A/B karşılaştırması için temel metrikleri (LCP, FCP, TBT, CLS, boyut/istek sayısı) ölçüp README veya perf-notes.md altında kaydet. Başarı kriteri sağlanmadan ana dala birleşme yapma. Böylece “küçülttüm ama etkileşim yavaşladı” gibi gerilemeleri baştan yakalarsın.
CI/CD ile otomasyon ve kalite kapıları
CI üzerinde build ve testten hemen sonra otomatik bundle analyze ve Lighthouse çalıştır. Raporları artefact olarak sakla ve son PR’lara yorum olarak düş. Kilit metrikler için quality gate eşikleri belirle (ör. main.js < 180 KB gzip, LCP < 2.5 s, TBT < 200 ms). Eşik aşılırsa merge bloklansın; bu disiplin, zamanla bir “performans kültürü” oluşturur. Vercel/Netlify önizleme ortamlarında gerçek kullanıcıya yakın testler alarak sentetik ve saha verisini birlikte değerlendir.
Git hooks ile yerel koruma hattı kur: pre-commit aşamasında ESLint/Stylelint ve tip denetimi koşsun; pre-push’ta küçük bir Lighthouse denetimi veya paket boyutu kontrolü yap. Böylece sorunlar daha depo dışına çıkmadan yakalanır.
Değişim günlüğü, sürümleme ve geri alma
Optimizasyonlar çoğu zaman görünmeyen teknik değişikliklerdir; etkilerini şeffaflaştırmak için CHANGELOG.md’de “Performance” bölümü tut. Örneğin “CSS critical inline 9 KB → 7 KB; hero görseli preload; LCP −280 ms” gibi somut notlarla ekip iletişimini güçlendir. Yayınlamayı semantic versioning ile hizala: yalnızca optimizasyon içeren değişiklikler patch versiyona gitsin; davranış değiştiriyorsa minor. Sorun çıkarsa git revert ile hızlı geri dönüş planı hazır olmalı.
Uzun vadede, feature flags ile yeni optimizasyonları kademeli aç/kapat yapabilmek (ör. yeni görüntü sıkıştırma hattı) risk yönetimini kolaylaştırır. RUM (Real User Monitoring) toplayıp Git SHA ile ilişkilendirerek “hangi commit’ten sonra LCP yükseldi?” sorusuna doğrudan cevap verebilirsin. Böylece küçültme ve dağıtım hattı, ölçülebilir hedeflere bağlanır ve tesadüfe bırakılmaz.
Özetle, VCS; kod optimizasyonunu tek seferlik bir kampanya olmaktan çıkarıp, sürdürülebilir bir mühendislik pratiğine dönüştürür. Standart branch modeli, CI kalite kapıları, otomatik analiz ve iyi tutulmuş bir değişim günlüğüyle; küçültme, önbellekleme ve CDN ayarları güvenle evrilir, riskler minimize edilir ve ekip her adımda hangi değişimin hangi metriği etkilediğini görebilir.
