Web Sitesi Hızlandırma Rehberi 2026 – Core Web Vitals

Türkiye’deki internet kullanıcılarının yüzde 78’i mobil cihazlardan web’e giriyor ve bu kullanıcıların yarısından fazlası 3 saniyeden uzun yüklenen bir siteyi terk ediyor. E-ticaret siteleri için her 1 saniyelik gecikme, dönüşüm oranını yüzde 7 düşürüyor. Google, 2025 sonunda Core Web Vitals metriklerini sıralama faktörleri arasında daha ağırlıklı hale getirdi. Web sitesi hızlandırma artık sadece kullanıcı deneyimini iyileştirmek değil, arama sonuçlarında üst sıralara çıkmak için de zorunlu. Bir reklam kampanyasına binlerce lira harcayıp kullanıcıyı yavaş bir siteye yönlendirmek, o bütçeyi çöpe atmakla eşdeğer.

Bu rehberde Google’ın hız metriklerinden görsel sıkıştırmaya, sunucu konfigürasyonundan cache mekanizmalarına kadar tüm katmanları ele alacağız. Her bölümde somut adımlar ve Türkiye’ye özel öneriler var.

Core Web Vitals: Google’ın Hız Karnesi

Core Web Vitals, Google’ın sayfa deneyimini ölçmek için kullandığı üç temel metrik. Bu metrikler, arama sıralamasını doğrudan etkiliyor. Üçünü de anlamak ve optimize etmek gerekiyor.

LCP (Largest Contentful Paint)

Sayfadaki en büyük görsel öğenin (hero görseli, başlık bloğu, büyük bir metin alanı) ekranda tamamen görünür hale gelme süresi. Google’ın “iyi” kabul ettiği eşik 2,5 saniye. Türkiye’deki sitelerin büyük çoğunluğu bu eşiğin üzerinde kalıyor, çünkü optimize edilmemiş görseller ve yavaş sunucu yanıt süreleri yaygın.

LCP’yi iyileştirmek için ilk bakılacak yer sunucu yanıt süresi (TTFB). Sunucu 800 milisaniyeden uzun sürede yanıt veriyorsa, ön yüzde ne yaparsanız yapın LCP iyi çıkmaz. İkinci kritik faktör, LCP öğesinin yükleme önceliği. Hero görseline fetchpriority="high" eklemek ve lazy loading uygulamaktan kaçınmak fark yaratır.

INP (Interaction to Next Paint)

Mart 2024’te FID (First Input Delay) metriğinin yerini alan INP, kullanıcının sayfayla her etkileşiminde (tıklama, dokunma, klavye girişi) tarayıcının ne kadar sürede görsel yanıt verdiğini ölçüyor. 200 milisaniyenin altı “iyi” kabul ediliyor. Ağır JavaScript dosyaları, ana iş parçacığını (main thread) bloke eden üçüncü parti scriptler ve karmaşık DOM yapıları INP’yi olumsuz etkiliyor.

Türkiye’deki e-ticaret sitelerinde sıkça rastlanan bir sorun: canlı sohbet widget’ları, analitik scriptleri ve reklam pikselleri üst üste yükleniyor. Her biri tek başına küçük bir yük gibi görünse de, toplamda ana iş parçacığını 300-500 milisaniye bloke edebiliyor. Bu durum kullanıcının butona tıkladığında birkaç saniye beklemesine yol açıyor.

CLS (Cumulative Layout Shift)

Sayfa yüklenirken içeriğin beklenmedik şekilde kayması. Bir metin okurken üstten gelen bir reklam banner’ı yüzünden paragrafın aşağı kayması, CLS puanını düşüren klasik bir örnek. Eşik değer 0,1. Görsellere genişlik ve yükseklik tanımlamak, reklam alanlarına sabit boyut ayırmak ve web fontlarının yüklenme stratejisini optimize etmek CLS’yi düşürür.

Mevcut Performansınızı Ölçün

Hız optimizasyonuna başlamadan önce mevcut durumu doğru ölçmek şart. “Site yavaş” demek yetmez; hangi metrik kötü, hangi sayfalarda sorun var, mobil mi masaüstü mü daha kötü, bunları bilmek gerekiyor.

Google PageSpeed Insights

PageSpeed Insights, hem laboratuvar verilerini (Lighthouse simülasyonu) hem de saha verilerini (Chrome kullanıcılarından toplanan gerçek veriler, CrUX) gösteriyor. Saha verileri, Google sıralamasını etkileyen asıl veriler. Laboratuvar verileri ise sorunları teşhis etmek için daha faydalı. Her iki veriyi de dikkate alın ama önceliği saha verilerine verin.

Google Search Console

Search Console’un “Sayfa Deneyimi” raporu, sitenizin tamamındaki Core Web Vitals performansını toplu olarak gösteriyor. Hangi URL gruplarında sorun olduğunu, sorunun LCP mi CLS mi INP mi olduğunu buradan görebilirsiniz. Bu rapor, önceliklendirme yapmak için çok değerli.

GTmetrix ve WebPageTest

GTmetrix, sayfa yükleme sürecini şelale (waterfall) grafiğiyle detaylı gösteriyor. Hangi dosyanın ne zaman yüklendiğini, hangi isteğin darboğaz oluşturduğunu bu grafikten anlayabilirsiniz. WebPageTest ise farklı lokasyonlardan (İstanbul dahil) test yapma imkanı sunuyor ve filmstrip görüntüsüyle sayfanın saniye saniye nasıl yüklendiğini gösteriyor.

Bir ipucu: tek bir test sonuçuna güvenmeyin. Aynı sayfayı 3-5 kez test edin, ortalamasına bakın. Sunucu tarafındaki anlık yoğunluklar tek bir testi yanıltabilir.

Görsel Optimizasyonu

Görseller, çoğu web sitesinde toplam sayfa ağırlığının yüzde 50-70’ini oluşturuyor. Bir ürün sayfasında 10 tane ayarla edilmemiş fotoğraf varsa, sayfanın toplam boyutu kolayca 5-8 MB’ı geçebilir. Oysa aynı görseller doğru formatlandığında 500 KB’ın altına inebilir.

WebP ve AVIF Formatları

JPEG ve PNG artık eski nesil formatlar. WebP, JPEG’e göre yüzde 25-35 daha küçük dosya boyutu sunarken aynı görsel kaliteyi koruyor. AVIF ise WebP’den bile yüzde 20 daha küçük. Tarayıcı desteği artık yeterli seviyeye ulaştı: Chrome, Firefox, Edge ve Safari’nin güncel sürümleri hem WebP’yi hem AVIF’i destekliyor.

WordPress kullanıyorsanız ShortPixel, Imagify veya EWWW Image Optimizer gibi eklentiler mevcut görselleri otomatik olarak WebP’ye dönüştürebilir. Yeni yüklenen görseller de otomatik iyileştir edilir. Ama dikkat: eklenti ayarlarında sıkıştırma seviyesini kontrol edin. “Aggressive” mod bazı görsellerde kalite kaybına yol açabilir; “lossy” yüzde 80-85 kalite ayarı genellikle optimum denge.

Doğru Boyutlandırma

1920×1080 piksel çözünürlükteki bir görseli 400 piksel genişliğinde bir alana yerleştirmek, tarayıcının gereksiz yere büyük bir dosyayı indirmesine neden olur. srcset ve sizes nitelikleri kullanarak farklı ekran boyutları için farklı görsel varyantları sunun. Mobil kullanıcıya masaüstü boyutunda görsel göndermek, hem bant genişliğini hem de yükleme süresini olumsuz etkiler.

Lazy Loading

Ekranın alt kısmında kalan görsellerin sayfa ilk yüklenirken indirilmesine gerek yok. loading="lazy" niteliği, görselleri kullanıcı o bölgeye scroll ettikçe yüklüyor. Tarayıcı desteği mükemmel, ek JavaScript gerektirmiyor. Ama ilk ekranda görünen (above the fold) görsellere lazy loading uygulamayın, çünkü LCP’yi olumsuz etkiler.

CSS ve JavaScript Temizliği

Kullanılmayan CSS ve JavaScript kodları, sayfanın render süresini uzatıyor. Bir WordPress sitesinde 15-20 eklenti aktifse, her biri kendi CSS ve JS dosyasını yüklüyor. Bunların çoğu ilgili sayfada hiç kullanılmıyor bile.

Kullanılmayan Kodları Tespit Etme

Chrome DevTools’un Coverage sekmesi, sayfada yüklenen CSS ve JS dosyalarının yüzde kaçının kullanıldığını gösteriyor. Kırmızı ile işaretlenen kısımlar kullanılmayan kodlar. Tipik bir WordPress sitesinde yüklenen CSS’in yüzde 60-80’i kullanılmıyor. Bu oran, ciddi bir optimizasyon potansiyeli anlamına geliyor.

Minification ve Birleştirme

CSS ve JavaScript dosyalarındaki boşluklar, yorumlar ve gereksiz karakterler kaldırılarak dosya boyutu yüzde 10-20 küçültülebilir. Birden fazla CSS dosyası tek bir dosyada birleştirildiğinde HTTP istek sayısı azalır, bu da yükleme süresini kısaltır. WordPress’te Autoptimize veya WP Rocket gibi eklentiler bunu otomatik yapıyor.

Render-Blocking Kaynaklar

Tarayıcı, <head> bölümündeki CSS ve JavaScript dosyalarını indirip işleyene kadar sayfayı render etmeye başlamaz. Bu durum “render-blocking” olarak adlandırılır. Kritik CSS’i satır içi (inline) olarak <head>‘e yerleştirmek ve geri kalan CSS’i media="print" onload="this. media='all'" tekniğiyle asenkron yüklemek, ilk render süresini belirgin şekilde kısaltır. JavaScript dosyalarına defer veya async eklemek de aynı etkiyi yapar.

Veritabanı Optimizasyonu

WordPress siteleri MySQL veya MariaDB veritabanı kullanır. Her sayfa yüklenmesinde onlarca veritabanı sorgusu çalışır. Veritabanı düzenle edilmemişse, bu sorguların yanıt süresi artar ve TTFB yükselir.

WordPress varsayılan olarak her yazı kaydettiğinizde bir revizyon oluşturur. 50 yazının her birinde 20 revizyon varsa, wp_posts tablosunda 1.000 gereksiz satır birikmiş demektir. Transient veriler (geçici veriler) de benzer şekilde birikir; süresi dolmuş transient’lar otomatik temizlenmez. Silinmiş yazıların meta verileri, orphaned (yetim) meta satırları ve spam yorumlar da veritabanını şişiren unsurlar arasında.

Optimizasyon adımları: WP-Optimize veya Advanced Database Cleaner ile düzenli temizlik yapın. wp-config.php’de revizyon sayısını sınırlayın. Autoload edilen seçenekler (options) tablosunu kontrol edin; silinmiş eklentilerin bıraktığı autoload verileri yükleme süresini artırır.phpMyAdmin’den veya WP-CLI’dan Iyileştir TABLE komutuyla tabloları defragmente edin.

Cache Stratejileri

Cache (önbellekleme), aynı kaynağın tekrar tekrar sunucudan istenmesini engeller. İki temel cache katmanı var: tarayıcı cache ve sunucu tarafı cache.

Tarayıcı Cache

HTTP yanıt başlıklarında Cache-Control direktifi ile statik dosyaların (görseller, CSS, JS, fontlar) ne kadar süre tarayıcıda saklanacağını belirleyebilirsiniz. Nadiren değişen dosyalar (logo, font dosyaları) için 1 yıl gibi uzun süreler uygun. Sık güncellenen dosyalar için daha kısa süreler tercih edin ve dosya adına versiyon hash’i ekleyin (örneğin style.v3.css veya style. abc123.css).

Sunucu Tarafı Cache

Dinamik sayfalar her istekte veritabanı sorguları çalıştırıp HTML oluşturur. Sunucu tarafı cache, oluşturulmuş HTML’i belirli bir süre saklayarak sonraki isteklerde veritabanına gitmeden yanıt verir. WordPress için sayfa cache eklentileri (WP Super Cache, W3 Total Cache, WP Rocket) veya sunucu seviyesinde Varnish, LiteSpeed Cache gibi çözümler kullanılabilir.

Göz ardı edilmemesi gereken bir nokta: sepet sayfası, kullanıcı profili gibi kişiye özel sayfaları cache’lemeyin. Bu sayfalar her kullanıcı için farklı içerik gösteriyor. Cache’li bir sepet sayfası, bir kullanıcının ürünlerini başka bir kullanıcıya gösterebilir.

Object Cache

WordPress’te veritabanı sorguları en büyük yavaşlama nedenlerinden biri. Redis veya Memcached gibi in-memory cache sistemleri, tekrarlayan veritabanı sorgularının sonuçlarını RAM’de tutar. Hızlı yüklenme süresi hedefleyen e-ticaret siteleri için object cache neredeyse zorunlu.

CDN Yapılandırması

CDN (Content Delivery Network), statik dosyalarınızı dünya genelindeki sunuculara dağıtır. Kullanıcı, en yakın sunucudan dosyayı indirir, bu da gecikmeyi azaltır. Türkiye merkezli bir site için İstanbul’da PoP (Point of Presence) noktası olan bir CDN sağlayıcısı seçmek önemli.

Cloudflare, Türkiye’de İstanbul’da PoP noktasına sahip ve ücretsiz planı bile temel CDN hizmeti sunuyor. Bunun yanında DNS yönetimi, DDoS koruması ve SSL sertifikası da sağlıyor. BunnyCDN ise fiyat/performans oranıyla öne çıkan bir alternatif; Türkiye’deki gecikme süreleri Cloudflare ile karşılaştırılabilir seviyede.

CDN yapılandırırken atlanmaması gerekenler: orijin sunucu ile CDN arasındaki cache süreleri uyumlu olmalı, dinamik içerikler CDN’den geçirilmemeli, purge (cache temizleme) mekanizması düzgün çalışmalı. Bir ürün fotoğrafını değiştirdiğinizde eski versiyonun CDN’de kalmasını istemezsiniz.

Sunucu ve Hosting Seçimi

Ön yüzde ne kadar optimizasyon yaparsanız yapın, sunucu yanıt süresi (TTFB) yavaşsa sayfa hızlı açılmaz. Türkiye’de paylaşımlı hosting kullanan birçok site, aynı sunucudaki diğer sitelerin yükünden etkileniyor. TTFB’nin 200 milisaniyenin altında olması ideal, 600 milisaniye üstü ciddi sorun.

Hosting Türleri

Paylaşımlı hosting (shared), aylık 50-200 TL arasında en ucuz seçenek ama performansı en düşük olan. Aynı sunucuyu yüzlerce site paylaşıyor. VPS (Virtual Private Server) ile tahsis edilmiş kaynaklar alırsınız; aylık 300-1.000 TL arasında. Cloud hosting (AWS, Google Cloud, DigitalOcean) ise trafik artışlarına otomatik ölçekleme sunar. Managed WordPress hosting (Cloudways, Kinsta, WP Engine) performans ve güvenlik optimizasyonlarını sağlayıcı yapıyor; aylık 500-2.000 TL arası.

Yıllık 100.000 ziyaretin altındaki siteler için kaliteli bir VPS yeterli. E-ticaret siteleri ve yüksek trafikli siteler için cloud veya managed hosting daha uygun. Profesyonel web sitesi tasarımıyla birlikte doğru hosting seçimi, sitenizin temelini oluşturur.

PHP Sürümü

WordPress siteleri PHP ile çalışıyor. PHP 7.4 kullanıyorsanız PHP 8.2 veya 8.3’e geçmek, yüzde 15-30 performans artışı sağlayabilir. Hosting panelinizden PHP sürümünü değiştirebilirsiniz. Ama önce tüm eklentilerinizin yeni PHP sürümüyle uyumlu olduğunu kontrol edin; uyumsuzluk hata verebilir.

HTTP/2 ve HTTP/3

HTTP/2 çoklu istekleri tek bir bağlantı üzerinden paralel gönderebiliyor, bu da yükleme süresini kısaltıyor. HTTP/3 ise UDP tabanlı QUIC protokolünü kullanarak bağlantı kurma süresini daha da düşürüyor. Çoğu modern hosting sağlayıcısı HTTP/2’yi destekliyor; Cloudflare HTTP/3 desteğini ücretsiz planında bile sunuyor.

Mobil Hız Optimizasyonu

Google, mobil öncelikli dizinlemeye (mobile-first indexing) tamamen geçti. Sitenizin mobil uyumluluk performansı, masaüstünden daha kritik. Mobil cihazlarda işlemci gücü düşük, ağ bağlantıları kararsız ve ekran boyutu küçük. Bu üç faktör, masaüstünde sorunsuz görünen bir sitenin mobilde çok yavaş çalışmasına yol açabilir.

Mobil hız optimizasyonu için odaklanılması gereken alanlar: JavaScript miktarını minimumda tutun (mobilde JavaScript işleme süresi masaüstünün 3-5 katı), dokunmatik öğeler arası mesafeyi kontrol edin (Google “tapable elements too close” uyarısı verir), font dosyalarını geliştir edin (kullandığınız karakterleri subset olarak yükleyin, Türkçe karakterleri içeren Latin Extended subset yeterli).

AMP (Accelerated Mobile Pages) bir dönem popülerdi ama Google, AMP’yi sıralama avantajı olarak kaldırdı. AMP yerine normal sayfanızı hızlı yapmak daha sürdürülebilir bir strateji.

Mobilde Üçüncü Parti Script Yönetimi

Türkiye’deki e-ticaret sitelerinin büyük bölümünde Facebook Pixel, Google Analytics 4, Google Tag Manager, canlı destek widget’ı, Hotjar veya Microsoft Clarity gibi izleme araçları aynı anda yüklü. Masaüstünde bu scriptler fark edilmeyecek düzeyde yük bindiriyor olabilir ama orta segment bir Android telefonda durum farklı. Ana iş parçacığını (main thread) bloke eden her script, kullanıcının ekrana dokunduğunda yanıt almayı bekleme süresini uzatıyor.

Çözüm, tüm üçüncü parti scriptleri kaldırmak değil. Önceliklendirmek. Google Tag Manager kullanıyorsanız, kritik olmayan etiketleri (örneğin remarketing pikselleri, anket araçları) “Window Loaded” tetikleyicisiyle yükleyin. Sayfa tamamen yüklendikten sonra devreye giren scriptler, kullanıcının ilk etkileşimini etkilemez. Partytown gibi kütüphaneler ise üçüncü parti scriptleri web worker’a taşıyarak ana iş parçacığını tamamen serbest bırakır; henüz yaygın kullanılmıyor ama performans açısından umut vaat eden bir teknoloji.

Font Optimizasyonu

Web fontları, sayfa yüklenme süresini etkileyen gizli bir kalem. Google Fonts’tan bir Türkçe font yüklediğinizde, varsayılan olarak Latin, Latin Extended ve Cyrillic karakter setlerinin tamamı indirilir. Oysa Türkçe siteler için sadece Latin Extended subset yeterli. Google Fonts URL’sine &subset=latin-ext parametresi eklemek, font dosya boyutunu yüzde 60-70 azaltabilir.

Font display stratejisi de önemli. font-display: swap değeri, font yüklenene kadar sistem fontunu gösterir; bu sayede metin gecikmeden görünür. font-display: optional ise daha agresif bir yaklaşım: font 100 milisaniye içinde yüklenmezse hiç kullanılmaz, sadece önbellekteyse gösterilir. Bu değer CLS’yi sıfıra indirir ama ilk ziyarette font görünmeyebilir.

Self-hosted font kullanmak (Google Fonts CDN yerine fontları kendi sunucunuzda barındırmak) DNS lookup süresini ortadan kaldırır ve GDPR uyumluluğu sağlar. WOFF2 formatı, en yüksek sıkıştırma oranını sunuyor ve tüm modern tarayıcılar tarafından destekleniyor.

E-Ticaret Siteleri İçin Hız Stratejileri

E-ticaret siteleri, sayfa hızı konusunda ek zorluklar taşır. Ürün sayfalarında çok sayıda görsel, varyant seçenekleri, fiyat hesaplamaları, stok kontrolü ve öneri widget’ları var. Kategori sayfalarında düzinelerce ürün kartı yükleniyor. Hepsinin hızlı açılması gerekiyor çünkü her saniye dönüşüm kaybı demek.

Ürün Sayfası Optimizasyonu

Ürün fotoğraflarını AVIF veya WebP formatında sunun. Her ürün için farklı boyutlarda (thumbnail, orta, büyük) varyant oluşturun. Ürün sayfasındaki ilk görsele fetchpriority="high" ekleyin, diğer görseller lazy load olsun. Ürün açıklama metni uzunsa, ilk 200 kelimeyi gösterip “devamını oku” butonu ile genişletmek, ilk render süresini kısaltır.

Kategori Sayfası Optimizasyonu

Kategori sayfalarında sayfalama (pagination) veya sonsuz kaydırma (infinite scroll) kullanın. Tek sayfada 200 ürün göstermek hem sayfa boyutunu hem de render süresini artırır. Sayfa başına 20-40 ürün göstermek idealdir. Ürün kartlarındaki görseller için düşük kaliteli yer tutucu (LQIP – Low Quality Image Placeholder) kullanmak, algılanan yükleme süresini iyileştirir.

Sepet ve Ödeme Sayfası

Sepet sayfası cache’lenemez çünkü her kullanıcıda farklıdır. Ama ödeme sayfasındaki gereksiz scriptleri kaldırabilirsiniz. Sohbet widget’ı, analitik araçları ve remarketing pikselleri ödeme sayfasında gereksiz yük yaratır. Ödeme sayfasında sadece ödeme için gereken scriptleri tutun. Bazı e-ticaret platformları “checkout optimization” seçeneği sunuyor; bu seçeneği aktif edin.

WordPress Hız İpuçları

Türkiye’deki web sitelerinin tahminen yüzde 40’ı WordPress altyapısıyla çalışıyor. WordPress esnek bir platform ama optimizasyon yapılmazsa yavaşlayabiliyor. İşte WordPress’e özel pratik ipuçları:

Eklenti sayısını kontrol altında tutun. Her eklenti veritabanı sorgusu ve HTTP isteği eklir. Aktif olarak kullanmadığınız eklentileri sadece devre dışı bırakmak yetmez, silin. Devre dışı bırakılmış eklentiler güvenlik açığı riski de taşır.

Tema seçimi performansı doğrudan etkiler. Çok amaçlı (multipurpose) temalar genellikle onlarca özellik barındırır ve bunların çoğu kullanılmaz ama yine de yüklenir. GeneratePress, Astra veya Kadence gibi hafif temalar, sayfa hızı açısından çok daha iyi başlangıç noktaları sunar.

Veritabanı temizliği düzenli yapılmalı. Post revisions (yazı revizyonları), transient veriler, spam yorumlar ve optimize edilmemiş tablolar veritabanını şişirir. WP-Iyileştir veya Advanced Database Cleaner eklentileri bu temizliği otomatik yapabilir. wp-config.php dosyasına define('WP_POST_REVISIONS', 5); ekleyerek revizyon sayısını sınırlayabilirsiniz.

Sayfa oluşturucu (page builder) kullanıyorsanız dikkatli olun. Elementor, Divi gibi oluşturucular tasarım kolaylığı sağlar ama arka planda çok miktarda ek HTML, CSS ve JavaScript üretir. Mümkünse Gutenberg bloklarını tercih edin veya en azından sayfa oluşturucunun ürettiği kodu düzenli olarak kontrol edin.

Heartbeat API sıklığını azaltın. WordPress, arka planda düzenli aralıklarla sunucuya istek gönderir (otomatik kaydetme, oturum kontrolü). Bu istekler, yönetici panelinde ve bazen ön yüzde performans kaybına yol açar. Heartbeat Control eklentisi veya WP Rocket’ın ilgili ayarı ile bu sıklığı azaltabilirsiniz.

Üçüncü Parti Araçların Hız Etkisi

Çoğu web sitesinde performans sorunlarının kaynağı kendi kodunuz değil, üçüncü parti scriptlerdir. Google Tag Manager, Facebook Pixel, Google Analytics, canlı sohbet widget’ları, A/B test araçları, heatmap araçları ve reklam pikselleri sayfa yüklenme süresini ciddi ölçüde artırır.

Her üçüncü parti scripti eklemeden önce şu soruyu sorun: Bu aracın sağladığı fayda, yarattığı performans kaybına değer mi? Kullanmadığınız bir analitik aracını veya artık aktif olmayan bir reklam pikselini sitede bırakmak, bedavaya bile pahalı.

Google Tag Manager’ı doğru yapılandırmak kritik. Tüm etiketleri “All Pages” tetikleyicisiyle yüklemek yerine, her etiketi ilgili sayfada ve doğru zamanda (Page View, DOM Ready veya Window Loaded) tetiklemek performansı korur. Consent Mode v2 entegrasyonu da Tag Manager üzerinden yapılabilir ve KVKK uyumluluğu için gerekli.

Optimizasyon Sonrası Takip

Hız optimizasyonu tek seferlik bir iş değil. Yeni eklenti kurulması, içerik eklenmesi, tema güncellemesi gibi her değişiklik performansı etkileyebilir. Düzenli izleme ve bakım şart.

Google Search Console İzleme

Search Console’un Core Web Vitals raporunu ayda en az bir kez kontrol edin. “İyileştirme gerekli” veya “zayıf” kategorisine düşen URL gruplarını tespit edip öncelik sırasına göre düzeltin. Google bu raporu 28 günlük saha verileriyle oluşturuyor, yani bir değişikliğin etkisini görmek 4-6 hafta sürebilir.

Otomatik Hız Testi

SpeedVitals, DebugBear veya Calibre gibi araçlarla otomatik hız testleri planlayabilirsiniz. Günlük veya haftalık testler, performans düşüşlerini erken tespit etmenizi sağlar. Organik arama trafiğindeki ani düşüşlerin arkasında hız sorunları olabilir.

Performans Bütçesi Belirleme

Performans bütçesi, sayfanızın toplam boyutu, JavaScript miktarı ve yükleme süresi için üst sınırlar belirlemektir. Toplam sayfa boyutu 1,5 MB’ın altında, JavaScript boyutu 300 KB’ın altında, LCP 2,5 saniyenin altında gibi hedefler koyun. Her yeni özellik veya içerik eklenirken bu bütçeye uyulup uyulmadığını kontrol edin. Webpack veya Lighthouse CI ile bu kontroller otomatikleştirilebilir.

Akif Diri Dijital Dönüşüm Projesi‘nde uyguladığımız hız optimizasyonu çalışmalarında, sayfa yükleme süresini 6,2 saniyeden 1,8 saniyeye indirdik ve organik trafikte yüzde 45 artış gözlemledik. Bu tür sonuçlar, sistematik bir yaklaşımla her site için mümkün.

Google Ads kalite puanı da sayfa hızından doğrudan etkilenir. Reklam veriyorsanız ve açılış sayfanız yavaşsa, tıklama başı maliyetiniz (CPC) yüksek, kalite puanınız düşük olacaktır. Hız optimizasyonu sadece SEO değil, ücretli reklam performansınızı da iyileştirir.