Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
LCP
Largest Contentful Paint
≤ 2,5 snAna içeriğin kullanıcıya ne kadar hızlı göründüğünü ölçer. Büyük hero görselleri, yüksek TTFB, geç keşfedilen LCP kaynağı ve render gecikmesi sık nedenlerdir.
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
Sitenizin yalnızca PageSpeed puanına bakmıyoruz. Gerçek kullanıcı verileri, sunucu yanıt süresi, LCP, INP, CLS, render engelleyen kaynaklar, görseller, JavaScript, CSS, fontlar, cache, PHP, veritabanı ve hosting limitlerini ayrı katmanlar halinde değerlendiriyoruz.
İlk ön analiz için site adresinizi iletmeniz yeterlidir. Yönetim paneli, FTP veya hosting şifresi ilk aşamada gerekli değildir. Müdahale gerekirse erişim ihtiyacı ve yapılacak işlem ayrıca netleştirilir.
Gerçek kullanıcı (CrUX) ve sunucu katman analizi
Yavaşlık tek bir nedenden oluşmaz. Sorun sunucunun HTML yanıtını geç üretmesi, büyük LCP görseli, render engelleyen CSS, ağır JavaScript, üçüncü taraf scriptler, fontlar, cache eksikliği, veritabanı sorguları, düşük CPU/RAM/I/O limitleri, PHP worker yetersizliği, eklenti-tema yükü veya bunların birkaçının birleşimi olabilir. Sağlıklı analizde önce sorun istemci, uygulama ve sunucu katmanlarına ayrılır; ardından gerçek darboğaz ölçülür.
İlk ön analiz için site adresinizi iletmeniz yeterlidir. Yönetim paneli, FTP veya hosting şifresi ilk aşamada gerekli değildir. Müdahale gerekirse erişim ihtiyacı ve yapılacak işlem ayrıca netleştirilir.
Google PageSpeed Insights mobil ve masaüstü sonuçları
LCP, INP ve CLS Core Web Vitals değerlendirmesi
TTFB ve ilk HTML yanıt süresi
FCP, Speed Index, TBT gibi laboratuvar metrikleri
Render engelleyen CSS ve JavaScript dosyaları
Kullanılmayan CSS ve JavaScript yükü
Hero ve ürün görsellerinin boyut / format analizi
WebP / AVIF, responsive image ve lazy-load kullanımı
Font dosyaları ve font-display davranışı
Tarayıcı cache ve sunucu cache davranışı
LiteSpeed Cache, Redis veya object cache ihtiyacı
CDN / Cloudflare kaynaklı gecikme veya yanlış cache kuralları
WordPress, WooCommerce, OpenCart, PrestaShop ve özel PHP uygulama yükü
PHP sürümü, OPcache, PHP-FPM / worker ve uygulama darboğazları
MySQL / MariaDB sorgu ve veritabanı şişkinliği ihtimali
CPU, RAM, I/O, IOPS, Entry Process ve inode gibi hosting limitleri
Mobilde açılışın masaüstünden neden daha yavaş olduğu
Öncelikli düzeltmelerin etki / risk sırasına göre ayrılması
Google ve web.dev rehberlerinde iyi deneyim için 75. yüzdelikte hedeflenen değerler
Ana içeriğin kullanıcıya ne kadar hızlı göründüğünü ölçer. Büyük hero görselleri, yüksek TTFB, geç keşfedilen LCP kaynağı ve render gecikmesi sık nedenlerdir.
Tıklama, dokunma ve klavye etkileşimlerine sayfanın ne kadar hızlı görsel yanıt verdiğini ölçer. Uzun JavaScript görevleri ve ana iş parçacığı yükü INP değerini bozabilir.
Sayfa yüklenirken içeriklerin beklenmedik şekilde kaymasını ölçer. Boyutsuz görseller, reklam alanları, geç yüklenen fontlar ve sonradan eklenen bileşenler sık sebeplerdir.
Hayır. PageSpeed Insights tek bir sayıdan ibaret değildir. Araç hem kontrollü laboratuvar testleri hem de yeterli trafik bulunan URL veya origin için Chrome User Experience Report tabanlı gerçek kullanıcı verileri gösterebilir. Laboratuvar verisi hata ayıklamak için, saha verisi ise ziyaretçilerin gerçek cihaz ve ağ koşullarındaki deneyimini anlamak için kullanılır.
Bu nedenle mobil performans puanının 50 olması tek başına teşhis değildir. Aynı raporda LCP kötü olabilirken CLS iyi, TTFB yüksekken JavaScript yükü düşük olabilir. Analizin amacı puanı körlemesine 100 yapmak değil; gerçek kullanıcı deneyimini bozan darboğazı tespit etmektir.
Bir diğer önemli ayrım URL verisi ile origin verisidir. Belirli sayfada yeterli saha verisi yoksa araç alan adının genel verisini gösterebilir veya saha verisi hiç göstermeyebilir. Bu durumda Lighthouse laboratuvar sonucu ile gerçek kullanıcı ölçümünü aynı şey gibi yorumlamamak gerekir.
LCP çoğu zaman sayfanın üst kısmındaki büyük hero resmi, ürün görseli, banner veya büyük metin bloğudur. Sorunu çözebilmek için önce hangi DOM öğesinin LCP olarak seçildiğini görmek gerekir. Yalnızca tüm görselleri sıkıştırmak, gerçek LCP öğesi farklıysa beklenen iyileştirmeyi sağlamaz.
LCP süresi dört parçaya ayrılabilir: TTFB, LCP kaynağının keşfedilmesine kadar geçen yükleme gecikmesi, kaynağın indirilme süresi ve kaynak indikten sonra ekranda çizilmesine kadar geçen render gecikmesi. Örneğin görsel küçük olsa bile JavaScript o görseli geç görünür yapıyorsa asıl problem dosya boyutu değil render gecikmesidir.
Hero görselinin CSS background içinde geç keşfedilmesi, yanlış lazy-load uygulanması, düşük fetch priority, çok büyük responsive olmayan görseller, CDN gecikmesi veya sunucunun HTML yanıtını geç üretmesi LCP süresini ayrı ayrı yükseltebilir.
INP, sayfanın kullanıcı etkileşimlerine verdiği görsel yanıtın gecikmesini ölçer. Menüye dokunduğunuzda geç açılması, filtre butonunun birkaç yüz milisaniye tepkisiz kalması, sepete ekle tıklamasından sonra arayüzün donmuş gibi görünmesi INP açısından tipik belirtilerdir.
Ağır JavaScript paketleri, çok sayıda event listener, uzun süren senkron görevler, DOM üzerinde pahalı işlemler, üçüncü taraf canlı destek ve reklam scriptleri ana iş parçacığını meşgul edebilir. WooCommerce mağazalarında varyant, filtre, tracking ve ödeme scriptlerinin aynı sayfada toplanması özellikle mobil cihazlarda etkileşim gecikmesini artırabilir.
INP problemi yalnız minify ile çözülmeyebilir. Kullanılmayan kodun kaldırılması, ağır görevlerin bölünmesi, üçüncü tarafların ertelenmesi ve kritik etkileşimlerin daha az JavaScript ile çalışması gerekebilir.
CLS, kullanıcı etkileşimi olmadan gerçekleşen beklenmedik düzen kaymalarını ölçer. Ürün görseli yüklenince metnin aşağı itilmesi, çerez bildirimi veya reklam alanının sonradan araya girmesi, web fontu geldiğinde başlığın genişliğinin değişmesi buna örnektir.
Görsel ve iframe alanlarına width-height veya aspect-ratio ayrılması, reklam ve banner alanları için önceden yer tutulması, font stratejisinin düzeltilmesi ve sayfanın üstüne sonradan içerik enjekte edilmemesi temel kontrollerdir.
CLS sadece estetik bir sorun değildir. Kullanıcı tam bir butona basacakken butonun yer değiştirmesi yanlış tıklamalara ve özellikle ödeme ekranlarında ciddi deneyim problemlerine yol açabilir.
TTFB, tarayıcının isteği başlatmasından HTML yanıtının ilk baytını almasına kadar geçen süreyi ifade eder. DNS, TLS, ağ gecikmesi ve özellikle sunucu tarafında sayfanın üretilme süresi bu değeri etkiler. Yüksek TTFB olduğunda tarayıcı CSS, JavaScript ve görselleri keşfetmeye de geç başlar; dolayısıyla LCP zincirleme biçimde kötüleşebilir.
Ancak yüksek TTFB gördüğümüzde doğrudan hosting firmasını suçlamak doğru değildir. Aynı sunucuda statik bir dosya hızlı fakat dinamik ürün sayfası yavaşsa uygulama veya veritabanı tarafı daha güçlü şüphedir. Tüm dinamik ve statik istekler yavaşsa ağ, sunucu yükü veya kaynak limiti ihtimali artar.
Cache açıkken ana sayfa hızlı, giriş yapmış kullanıcıda veya sepet sayfasında yavaşsa page cache arkasında gizlenen uygulama maliyeti vardır. Bu senaryoda PHP worker, veritabanı sorguları ve dinamik endpointler ayrıca incelenmelidir.
Mobil test daha kısıtlı işlem gücü ve ağ koşullarını taklit ettiği için ağır JavaScript, büyük görsel ve uzun ana thread görevleri masaüstünden daha görünür hale gelir. Masaüstünde fark edilmeyen 1 MB JavaScript veya 2 MB hero görseli düşük güçlü telefonda ciddi gecikme yaratabilir.
Responsive görsellerin yanlış yapılandırılması da sık görülür. Telefonda 390 piksel genişliğinde gösterilen bir görselin 3000 piksel kaynak dosyasının indirilmesi gereksiz ağ maliyetidir. srcset, sizes ve doğru boyutlandırma burada önem kazanır.
Mobilde açılan sticky bar, chat widget, analytics, reklam ve sosyal medya scriptleri de masaüstünden farklı yüklenebildiği için iki cihaz sınıfının waterfall ve main-thread profilleri ayrı incelenmelidir.
WebP veya AVIF kullanmak faydalıdır fakat tek başına yeterli değildir. 4000x3000 çözünürlükte bir görseli WebP yapmak, ekranda 600x450 gösteriliyorsa hâlâ gereksiz veri transferi yaratabilir. Doğru format kadar doğru fiziksel boyut ve sıkıştırma seviyesi de önemlidir.
Viewport altındaki görseller lazy-load edilebilirken LCP görselini lazy-load etmek ters etki yapabilir. Tarayıcı ana görseli geç keşfettiğinde kullanıcı en önemli içeriği daha geç görür. Bu yüzden üst bölüm ve alt bölüm görsellerine aynı yükleme politikası uygulanmamalıdır.
E-ticarette kategori sayfasında onlarca ürün görseli bulunabilir. Thumbnail boyutlarının gerçekten küçük üretilmesi, aynı büyük görselin CSS ile küçültülmemesi ve görünür alan dışındaki resimlerin kontrollü ertelenmesi önemlidir.
Tarayıcı sayfayı çizebilmek için gerekli CSS dosyalarını beklemek zorunda kalabilir. Çok sayıda büyük stylesheet, kullanılmayan tema CSS’i ve farklı eklentilerin ayrı dosyaları render başlangıcını geciktirebilir. Kritik stillerin küçük tutulması ve kritik olmayan stillerin daha uygun biçimde yüklenmesi gerekebilir.
JavaScript tarafında async veya defer kullanımı her dosya için körlemesine uygulanmamalıdır. Bağımlılık sırası olan scriptlerde yanlış erteleme menü, slider, sepet veya ödeme fonksiyonlarını bozabilir. Bu nedenle optimizasyon sonrası yalnız puan değil gerçek fonksiyon testi yapılmalıdır.
Minify dosyayı küçültür fakat kullanılmayan 300 KB kodu 250 KB yapmak gerçek çözüm değildir. Kodun gerçekten gerekli olup olmadığını ve hangi sayfalarda yüklendiğini değerlendirmek daha kalıcı sonuç verir.
Evet. Üçüncü taraf scriptler kendi ağ isteklerini, JavaScript yürütmesini ve bazen iframe yapılarını getirir. Her bir script küçük görünse bile birden fazla pazarlama, reklam, chat, heatmap ve A/B test aracı birlikte kullanıldığında ana iş parçacığı ciddi yük alabilir.
Bu kodların hepsini kaldırmak her zaman işletme açısından mümkün değildir. Analizde hangi scriptin iş değeri sağladığı, hangisinin tüm sayfalarda yüklenmesi gerektiği ve hangisinin kullanıcı etkileşimine kadar ertelenebileceği ayrıştırılır.
Ödeme veya dönüşüm ölçümü için kritik eventlerin optimizasyon sırasında bozulmaması gerekir. Hız puanı uğruna analytics veya checkout eventlerinin çalışamaz hale gelmesi kabul edilebilir bir sonuç değildir.
Birden fazla font ailesi ve her aile için çok sayıda weight dosyası kullanmak ağ isteğini ve font işleme maliyetini artırabilir. Üstelik font gelene kadar metnin gizlenmesi veya fallback fonttan özel fonta geçerken metnin ölçüsünün değişmesi FCP, LCP ve CLS üzerinde etkili olabilir.
Gerçekte kullanılmayan 100, 200, 300, 400, 500, 600, 700, 800 ve 900 ağırlıklarının tamamını yüklemek yerine gerekli ağırlıkların seçilmesi ve WOFF2 gibi modern formatların kullanılması daha sağlıklıdır.
Self-hosting her durumda otomatik olarak daha hızlı değildir. Cache header, preload, dosya boyutu ve kullanılan subset yapılandırması yanlışsa yerel font da kötü performans gösterebilir.
Cache, tekrar eden hesaplamaları ve veri transferini azaltabilir fakat yanlış cache kuralı e-ticaret sitelerinde sepet, kullanıcı hesabı veya kişiye özel fiyat gibi dinamik alanları bozabilir. Page cache, object cache, opcode cache ve browser cache aynı şey değildir.
LiteSpeed Cache gibi bir eklentinin tam faydası, arka tarafta gerçekten LiteSpeed / OpenLiteSpeed gibi uyumlu sunucu özellikleri ve doğru cache politikası olduğunda ortaya çıkar. Nginx veya Apache üzerinde farklı cache katmanları gerekebilir.
Cache temizlendiğinde site aniden çok yavaşlıyor ve ilk ziyaretler ağır çalışıyorsa warm-cache ile uncached performans arasında büyük fark vardır. Bu durumda uygulamanın cache olmadan neden pahalı olduğu da incelenmelidir.
Redis çoğunlukla object cache için kullanıldığında tekrar eden veritabanı sorgularının sonuçlarını bellekte tutarak uygulama yükünü azaltabilir. Özellikle WordPress ve WooCommerce gibi dinamik sistemlerde doğru kullanıldığında yönetim paneli ve cache dışı sayfalarda fayda sağlayabilir.
Ancak küçük ve zaten hızlı bir sitede Redis eklemek mucize yaratmayabilir. Yanlış yapılandırılmış persistent object cache, eski verilerin tutulması veya yetersiz bellek de yeni sorunlara yol açabilir.
Bu yüzden Redis ihtiyacı sorgu profili, dinamik trafik ve mevcut cache yapısına göre değerlendirilmelidir; yalnızca özellik listesinde Redis var diye sitenin hızlı olacağı varsayılmamalıdır.
WordPress çekirdeğinin kendisinden çok tema, eklenti kombinasyonu, veritabanı sorguları, autoload edilen seçenekler, dış API çağrıları, cron görevleri ve hosting kaynakları gerçek yükü belirler. Aynı WordPress sürümü iki farklı projede tamamen farklı performans gösterebilir.
Elementor ve benzeri page builder yapılarında DOM büyüklüğü, gereksiz widget assetleri ve çok sayıda nested container; ağır temalarda ise global CSS ve scriptler ölçülmelidir. Eklenti sayısı tek başına doğru metrik değildir; on hafif eklenti bir ağır eklentiden daha az maliyetli olabilir.
wp-admin yavaşlığı ile ziyaretçi tarafı yavaşlığı da ayrılmalıdır. Page cache ziyaretçi tarafını hızlandırırken admin AJAX, cron, veritabanı veya üçüncü taraf API sorunları yönetim panelini yavaş bırakabilir.
WooCommerce ürün, varyant, stok, sepet, oturum, vergi, kargo, kupon ve ödeme gibi dinamik işlemler yürüttüğü için tamamen statik bir kurumsal siteye göre daha fazla sunucu ve veritabanı işi üretir. Sepet ve checkout gibi sayfalar çoğu zaman klasik full-page cache’e uygun değildir.
Büyük varyasyonlu ürünler, gelişmiş filtre eklentileri, canlı stok sorguları, fiyat hesapları, çoklu para birimi, pazaryeri senkronları ve Action Scheduler görevleri performansı etkileyebilir. Sadece ana sayfayı test etmek mağazanın gerçek darboğazını saklayabilir.
Ücretsiz analizde ana sayfaya ek olarak kategori, ürün ve mümkünse dinamik sepet/checkout akışı performans açısından ayrı düşünülür. Ödeme sayfasında optimizasyon yapılırken ödeme sağlayıcısının gerekli scriptlerinin bozulmaması önceliktir.
Dinamik sayfa üretiminde uygulama onlarca hatta yüzlerce SQL sorgusu çalıştırabilir. Tek tek hızlı görünen sorguların toplam maliyeti veya indeks kullanmayan birkaç ağır sorgu TTFB’yi yükseltebilir.
WordPress tarafında revisions, transients, options autoload, Action Scheduler tabloları ve eklentilerin bıraktığı eski tablolar zamanla büyüyebilir. Ancak veritabanını körlemesine temizlemek risklidir; hangi kaydın uygulama tarafından kullanıldığı bilinmeden silme yapılmamalıdır.
Doğru yaklaşım slow query log, uygulama profiler veya kontrollü sorgu analizi ile gerçekten pahalı sorguları tespit etmek, indeks ve veri modeli ihtiyacını buna göre değerlendirmektir.
Güncel ve uygulamayla uyumlu PHP sürümleri genellikle eski sürümlere göre performans ve güvenlik avantajları getirir. Ancak canlı sitede PHP sürümünü yalnız hız için yükseltmek tema, eklenti veya özel kod uyumsuzluğu yaratabilir. Önce uyumluluk kontrolü gerekir.
OPcache, PHP dosyalarının her istekte yeniden derlenmesi yerine derlenmiş bytecode’un bellekte tutulmasına yardımcı olur. Kapalı veya çok düşük bellekle yapılandırılmış OPcache dinamik PHP uygulamalarında gereksiz CPU maliyeti oluşturabilir.
PHP-FPM veya benzeri worker mimarisinde worker sayısı çok düşükse eşzamanlı istekler kuyrukta bekleyebilir; çok yüksek ayarlanırsa RAM tükenebilir. Bu nedenle worker değeri trafik ve süreç başına bellek tüketimine göre hesaplanmalıdır.
Paylaşımlı hosting paketlerinde disk alanı ve trafik dışında CPU, fiziksel bellek, I/O, IOPS ve eşzamanlı giriş süreçleri gibi kaynak sınırları bulunabilir. cPanel, CloudLinux kullanılan ortamlarda CPU ve memory usage gibi istatistikleri gösterebilir.
CPU limiti PHP ve veritabanı işlerini ne kadar işlem gücüyle çalıştırabileceğinizi, I/O limiti diskten okuma-yazma hızını, Entry Process ise web uygulamasına aynı anda giren belirli işlem türlerinin sınırını etkileyebilir. Kaynak sürekli tavana vuruyorsa ziyaretçi tarafında bekleme ve 503 benzeri sorunlar görülebilir.
Inode ise dosya adediyle ilişkilidir. Çok yüksek cache, session, thumbnail, mail veya yedek dosyası sayısı inode limitini doldurabilir. Inode limiti doğrudan PageSpeed metriği değildir fakat dosya oluşturma, yedekleme ve uygulama çalışmasını bozduğunda performans ve kullanılabilirliği etkileyebilir.
CDN statik kaynakları kullanıcıya daha yakın noktadan sunarak ağ gecikmesini azaltabilir ve cache edilebilen içerikte origin yükünü düşürebilir. Ancak yanlış cache kuralları, gereksiz Worker işlemleri, ekstra redirect zincirleri veya origin bağlantı sorunları yeni gecikmeler yaratabilir.
Cloudflare açıkken yavaş, DNS only modunda hızlı gibi bir durum varsa edge-origin bağlantısı, cache hit oranı, TLS, firewall veya routing ayrı incelenmelidir. Aynı şekilde yalnız Cloudflare’ı kapatıp açarak sonuca varmak yerine hangi aşamanın süre eklediği waterfall üzerinden ölçülmelidir.
Dinamik HTML’in CDN’de cache edilmesi e-ticaret ve kullanıcı oturumlu sistemlerde dikkat ister. Sepet veya kişiye özel içerik yanlış cache edilirse hız artarken işlev bozulabilir.
Modern HTTP sürümleri bağlantı kullanımını iyileştirebilir fakat kötü optimize edilmiş bir uygulamayı tek başına hızlı hale getirmez. Sunucu 3 saniyede HTML üretiyorsa protokol değişikliği bu uygulama gecikmesini ortadan kaldırmaz.
Özellikle çok sayıda küçük statik dosyada bağlantı yönetimi fayda sağlayabilir. Bununla birlikte asıl kazanım için dosya sayısı, cache, sıkıştırma, kritik kaynak önceliği ve sunucu yanıt süresi birlikte değerlendirilmelidir.
HTTP/3 kullanılabilirliği istemci, CDN ve origin mimarisine bağlıdır. Analiz sırasında protokol desteği bir kontrol maddesidir; tek hedef değildir.
HTML, CSS, JavaScript, JSON ve SVG gibi metin tabanlı kaynaklar aktarım sırasında sıkıştırıldığında ağ üzerinden daha az veri taşınır. Sıkıştırmanın kapalı olması özellikle büyük CSS/JS paketlerinde gereksiz transfer süresi oluşturur.
Görsellerde ise Gzip uygulamak genellikle çözüm değildir; JPEG, WebP ve AVIF zaten kendi sıkıştırma biçimlerine sahiptir. Her kaynak türüne aynı yaklaşımı uygulamak yerine content-type bazlı doğru politika gerekir.
CDN ile origin ikisi de sıkıştırma yapıyorsa yanıt header’ları kontrol edilerek istemciye gerçekten hangi encoding’in gönderildiği doğrulanmalıdır.
Her ekstra redirect, tarayıcının gerçek hedefe ulaşmadan önce yeni bir HTTP turu yapmasına neden olabilir. Özellikle http → https → www → dil URL’si gibi zincirler ilk navigasyona gereksiz gecikme ekler.
Tek bir doğru 301 yönlendirmesi genellikle problem değildir; sorun gereksiz zincir ve loop oluşmasıdır. Canonical host, HTTPS ve trailing slash politikası aynı hedefe tutarlı biçimde yönlendirilmelidir.
Reklam kampanyası veya eski backlink URL’lerinde arka arkaya birkaç yönlendirme bulunuyorsa gerçek kullanıcıların LCP ölçümüne daha HTML gelmeden gecikme eklenmiş olur.
Kullanıcı ile sunucu arasındaki fiziksel ve ağ mesafesi round-trip gecikmesini etkiler. Türkiye ağırlıklı kullanıcıya çok uzak bir origin sunucu, özellikle cache dışı dinamik isteklerde ek ağ gecikmesi oluşturabilir.
CDN statik kaynaklarda mesafeyi azaltabilir ancak cache edilmemiş HTML, API ve ödeme istekleri hâlâ origin’e gitmek zorunda olabilir. Bu nedenle hedef kitle, origin lokasyonu ve CDN stratejisi birlikte ele alınmalıdır.
Lokasyon tek başına kalite ölçütü değildir. Yakındaki aşırı yüklü bir sunucu, daha uzaktaki iyi yapılandırılmış ve hızlı bir sunucudan kötü performans gösterebilir.
İlk aşamada herkese açık veriler üzerinden sayfanın mobil ve masaüstü davranışı, Core Web Vitals / Lighthouse göstergeleri, yanıt header’ları, temel TTFB, ağır kaynaklar, görsel boyutları, üçüncü taraf istekler ve belirgin cache sorunları değerlendirilebilir.
Bu analiz bir güvenlik taraması veya sunucu içi profiler yerine geçmez. Dışarıdan görülebilen bulgular sorunun uygulama veya hosting katmanında olduğunu düşündürüyorsa ikinci aşamada cPanel, Plesk, SSH, uygulama logu veya yönetim paneli gibi erişimlere ihtiyaç olup olmadığı belirtilir.
İlk analizde şifre istemememizin nedeni gereksiz erişim toplamamaktır. Bir sorun yalnız herkese açık ölçümle anlaşılabiliyorsa önce bunu kullanmak daha güvenli ve pratiktir.
Sorunları sadece “site yavaş” diye listelemek yerine mümkün olduğunca katmanlarına ayırmak gerekir: kullanıcı tarafı, frontend kaynakları, uygulama / PHP, veritabanı, web sunucusu ve hosting kaynağı. Böylece hangi değişikliğin kimin tarafından yapılacağı netleşir.
Öncelikler “yüksek etki / düşük risk”, “yüksek etki / test gerektirir” ve “ikincil iyileştirme” gibi gruplara ayrılabilir. Örneğin 4 MB hero görselini düzeltmek düşük riskli olabilirken ödeme sayfasındaki JavaScript birleştirme ayarını değiştirmek staging testi gerektirebilir.
Ücretsiz ön analizde kapsam dışarıdan ölçülebilen verilerle sınırlıdır. Kod veya sunucu erişimi gerektiren ileri seviye kök neden analizi ayrıca değerlendirilir.
Tüm JavaScript dosyalarını tek tuşla ertelemek, tüm CSS’i birleştirmek, her görsele lazy-load vermek veya veritabanındaki “gereksiz” görünen kayıtları topluca silmek hız uğruna site fonksiyonlarını bozabilir. Özellikle e-ticaret ve üyelik sistemlerinde optimizasyon sonrası fonksiyon testi şarttır.
Bir diğer hata yalnız ana sayfa skoruna odaklanmaktır. Kullanıcıların para kazandıran yolculuğu kategori → ürün → sepet → ödeme ise performans bu akışta incelenmelidir. Ana sayfanın 95 puan olması checkout’un hızlı olduğu anlamına gelmez.
100 puan hedefi de bağlama göre anlamsız olabilir. Üçüncü taraf ödeme, analytics veya harita gibi işlevsel scriptler gerekli olabilir. Amaç gerçek kullanıcı deneyimini iyileştirmek ve gereksiz maliyeti azaltmaktır.
Performans değişiklikleri yalnız Lighthouse tekrar çalıştırılarak teslim edilmemelidir. Menü, arama, form, üyelik, sepet, varyant, kupon, ödeme, callback, analytics eventleri ve mobil menü gibi işlevler kontrol edilmelidir.
Cache değişikliklerinde giriş yapmış ve yapmamış kullanıcı, farklı cihaz, farklı para birimi veya dil gibi varyasyonlar test edilmelidir. CDN cache purge sonrası ilk ziyaret ile sıcak cache sonucu da ayrı gözlenebilir.
Core Web Vitals saha verileri 28 günlük gerçek kullanıcı penceresi kullandığından yapılan düzeltmenin CrUX tarafına anında yansıması beklenmemelidir. Laboratuvar testi hızlı doğrulama sağlar; saha verisi zamanla güncellenir.
Ücretsiz ön analiz, dışarıdan ölçülebilen belirgin darboğazları ve olası nedenleri sınıflandırmak içindir. Kod değiştirme, sunucu ayarı, veritabanı optimizasyonu, eklenti düzenleme veya CDN kuralı uygulama işlemleri bu aşamanın parçası değildir.
Müdahale gerekiyorsa mevcut Web Sitesi Hızlandırma ve Performans Optimizasyonu hizmeti üzerinden kapsam ayrı belirlenir. Böylece analiz sayfası “neden yavaş?” sorusunu, hizmet sayfası ise “kim düzeltecek?” satın alma niyetini karşılar.
Site hızınız zaten yeterliyse sırf hizmet satmak için gereksiz işlem önermek doğru değildir. Ön analizde ciddi bir sorun görünmüyorsa bunun da açıkça belirtilmesi amaçlanır.
| Uyarı / Belirti | Olası neden | Doğru yaklaşım |
|---|---|---|
| PageSpeed mobil 20-40 | Büyük JS/CSS, ağır LCP kaynağı, üçüncü taraf script, yüksek TTFB veya birkaç sorunun birleşimi | Önce LCP/TBT/diagnostics ve waterfall ayrıştırılır; puan tek başına neden kabul edilmez. |
| LCP 4 saniyeden yüksek | Yüksek TTFB, büyük/ geç keşfedilen hero, render gecikmesi | LCP öğesi ve dört alt süre ayrı incelenir. |
| INP 500 ms üzeri | Uzun JavaScript görevleri veya yoğun main thread | Etkileşim sırasında çalışan handler ve long task profili kontrol edilir. |
| CLS 0,25 üzeri | Boyutsuz medya, reklam, font veya sonradan eklenen içerik | Kaymanın hangi elementten geldiği ölçülür ve alan önceden rezerve edilir. |
| Reduce initial server response time | Sunucu / uygulama HTML’i geç üretiyor | Cache hit-miss, dinamik PHP süresi, SQL, worker ve hosting kaynağı ayrılır. |
| Eliminate render-blocking resources | Kritik çizim öncesinde beklenen CSS/JS | Kritik kaynaklar belirlenir, güvenli erteleme stratejisi uygulanır. |
| Reduce unused JavaScript | Sayfada kullanılmayan büyük script paketleri | Asset hangi eklenti/tema/üçüncü taraftan geliyor bulunur, sayfa bazlı yükleme değerlendirilir. |
| Reduce unused CSS | Tema/builder global CSS yükü | Kullanılan ve kullanılmayan stil oranı incelenir; kritik CSS körlemesine üretilmez. |
| Properly size images | Ekranda küçük görünen çok büyük görseller | Responsive varyantlar ve gerçek render boyutu eşleştirilir. |
| Serve images in next-gen formats | JPEG/PNG dosyaları gereğinden büyük | Uygun görseller WebP/AVIF’e dönüştürülür, kalite ve uyumluluk test edilir. |
| Avoid enormous network payloads | Toplam sayfa transferi çok yüksek | Görsel, video, font, JS ve üçüncü taraf yükler en büyükten küçüğe ayrılır. |
| Avoid long main-thread tasks | Tarayıcı JavaScript yürütürken kullanıcı etkileşimi bekliyor | Long task kaynakları profillenir ve bölme/erteleme seçenekleri değerlendirilir. |
| Cache çalışıyor ama site hâlâ yavaş | Dinamik endpoint, cache miss veya frontend yükü | Sadece ana HTML değil ürün, API, AJAX ve üçüncü taraf istekleri kontrol edilir. |
| wp-admin çok yavaş | Cache dışı PHP/SQL, cron, API veya eklenti yükü | Admin istekleri frontend’den ayrı profillenir. |
| Sepet/checkout yavaş | Dinamik WooCommerce işlemleri, ödeme/kargo API’leri, session ve SQL | Checkout akışı cache dışı olarak ölçülür, harici API süreleri ayrıştırılır. |
| 503 / Resource Limit | CPU, RAM, Entry Process veya worker sınırı | CloudLinux/cPanel kaynak grafiği ve hata zamanı eşleştirilir. |
| İlk ziyaret yavaş, ikinci hızlı | Cold cache / cache warm-up farkı | Cache katmanları ve cache dışı gerçek uygulama süresi ölçülür. |
| Cloudflare açıkken yavaş | Origin bağlantısı, yanlış cache veya Worker/redirect yükü | Edge ve origin süreleri ayrı ölçülür; DNS-only testi tek başına kesin teşhis sayılmaz. |
| Mobil menü geç tepki veriyor | INP / JavaScript main-thread yükü | Etkileşim handler’ı ve aynı anda çalışan üçüncü taraf kodları kontrol edilir. |
| Font gelince sayfa kayıyor | FOIT/FOUT ve font metric farkı | Font-display, preload ve fallback metric stratejisi değerlendirilir. |
Site adresi veya sorun yaşanan tam URL
Sorun tüm sayfalarda mı belirli sayfada mı?
Mobilde mi masaüstünde mi daha belirgin?
Yavaşlık sürekli mi belirli saatlerde mi?
Yakın zamanda tema, eklenti, PHP, hosting veya CDN değişti mi?
WordPress / WooCommerce / OpenCart / PrestaShop / özel PHP gibi altyapı bilgisi
Varsa PageSpeed veya Search Console Core Web Vitals ekran görüntüsü
Varsa 503, timeout, resource limit veya sunucu hata mesajı
İlk analizde şifre göndermeyin; gerekirse daha sonra güvenli kanaldan istenir.
İlk dış analiz ücretsizdir. Herkese açık sayfa verileri ve performans ölçümleri üzerinden belirgin sorunları sınıflandırırız. Kod veya sunucu üzerinde müdahale gerekiyorsa yapılacak işlem ayrıca fiyatlandırılır.
Hayır. İlk aşamada site adresi yeterlidir. Dışarıdan görülemeyen PHP, SQL veya hosting kaynak problemi için ileri inceleme gerekirse hangi erişimin neden gerekli olduğu ayrıca bildirilir.
Hayır. Sabit 100 puan garantisi teknik olarak doğru değildir. Amaç gerçek darboğazları düzeltmek ve kullanıcı deneyimini iyileştirmektir. Üçüncü taraf gerekli scriptler ve uygulama işlevleri skoru etkileyebilir.
Hayır. Core Web Vitals ve sayfa deneyimi Google sistemlerinde kullanılan sinyaller arasındadır ancak iyi hız değerleri tek başına birinci sıra garantisi vermez. İçerik, alaka, bağlantılar ve birçok başka sinyal birlikte değerlendirilir.
Google ve web.dev rehberlerinde iyi LCP hedefi 75. yüzdelikte 2,5 saniye veya daha azdır. 2,5-4 saniye geliştirilmesi gereken, 4 saniye üzeri kötü aralıktır.
İyi INP hedefi 75. yüzdelikte 200 ms veya daha azdır. 200-500 ms geliştirilmesi gereken, 500 ms üzeri kötü kabul edilir.
İyi CLS hedefi 0,1 veya daha azdır. 0,1-0,25 arası geliştirilmesi gereken, 0,25 üzeri kötü aralıktır.
INP, Mart 2024 itibarıyla Core Web Vitals içindeki FID metriğinin yerini aldı. Güncel analiz LCP, INP ve CLS üçlüsünü esas almalıdır.
URL veya origin için Chrome UX Report’ta yeterli gerçek kullanıcı örneği olmayabilir. Bu durumda yalnız laboratuvar verisi görülebilir.
Mobil test daha sınırlı cihaz/ağ koşullarında ağır JavaScript, büyük görsel ve main-thread maliyetini daha görünür hale getirir. Ayrıca mobil özel widget ve scriptler de fark yaratabilir.
TTFB için tek başına evrensel SEO geçme-kalma eşiği yoktur; LCP teşhisinde mümkün olduğunca düşük olması hedeflenir. Değer ağ, lokasyon, cache ve dinamik üretim yapısına göre yorumlanmalıdır.
Hayır. Sorun ağır tema, SQL veya JavaScript ise daha güçlü hosting yalnız semptomu azaltabilir. Önce darboğazın hosting mi uygulama mı olduğu ölçülmelidir.
Hayır. Web sunucusu önemli bir katmandır fakat CPU/RAM/I/O limitleri, veritabanı, PHP, tema ve frontend yükü de sonucu belirler. LiteSpeed etiketi tek başına hız garantisi değildir.
Hayır. Dinamik ve sorgu ağırlıklı uygulamalarda faydalı olabilir. Küçük veya statik bir sitede etkisi sınırlı olabilir.
Her zaman değil. Doğru cache ve ağ koşullarında faydalıdır; yanlış yönlendirme, cache veya origin bağlantısı yapılandırması performansı bozabilir.
Hayır. Görselin fiziksel boyutu, responsive kullanımı, sıkıştırma seviyesi, lazy-load ve LCP kaynağı olup olmadığı da önemlidir.
Hayır. Viewport altındaki görseller için uygundur fakat LCP/hero görselini lazy-load etmek çoğu durumda LCP’yi geciktirebilir.
Modern HTTP/2 ve HTTP/3 ortamlarında körlemesine birleştirme her zaman avantajlı değildir. Bağımlılık ve cache davranışına göre karar verilmelidir.
Dosya boyutunu düşürebilir fakat kullanılmayan kodu ortadan kaldırmaz. Büyük performans sorununda tek başına minify genellikle yeterli değildir.
Sayının kendisinden çok eklentilerin yaptığı iş önemlidir. Bir ağır eklenti onlarca küçük eklentiden fazla SQL, JavaScript veya API yükü oluşturabilir.
Hayır; fakat büyük DOM, gereksiz widget assetleri, çok sayıda font ve animasyon kötü yapılandırılırsa maliyet artabilir. Tema ve içerik yapısı birlikte ölçülmelidir.
Sepet, kullanıcı, kupon, vergi, kargo ve ödeme bilgileri kişiye ve oturuma göre değişebildiği için klasik full-page cache yanlış veri gösterebilir. Dinamik optimizasyon ayrı yapılır.
Ne silindiği bilinmeden yapılan toplu temizlik risklidir. Önce yedek alınmalı ve gerçekten kullanılmayan/verimsiz kayıtlar veya sorgular belirlenmelidir.
Uygulamayla uyumluysa modern PHP sürümleri fayda sağlayabilir. Ancak tema, eklenti veya özel kod uyumsuzluğu varsa site bozulabilir; staging veya yedekli test yapılmalıdır.
PHP’nin derlenmiş bytecode’unu bellekte tutarak her istekte aynı dosyaların yeniden derlenme maliyetini azaltan cache katmanıdır.
CloudLinux ortamlarında web hesabına aynı anda giren belirli dinamik süreçleri sınırlayan kaynak metriklerinden biridir. Limit aşımı yoğun trafikte veya ağır isteklerde hata/kuşaklanmaya yol açabilir.
Uygulama diskten veri okurken veya yazarken bekleyebilir. Çok dosyalı cache, yedekleme, log veya yoğun veritabanı I/O senaryolarında etkisi görülebilir.
Doğrudan Core Web Vital değildir. Ancak limit dolduğunda cache, session, e-posta, upload veya log dosyaları oluşturulamayabilir ve uygulama sağlığı bozulabilir.
Cache edilen HTML veya edge’e yakın içerikte düşürebilir. Dinamik ve cache dışı isteklerde origin süresi hâlâ önemlidir.
Hayır. Hız ve Core Web Vitals sayfa deneyiminin bir parçasıdır; iyi teknik performans kaliteli ve ilgili içerik ihtiyacının yerini tutmaz.
Hayır. WooCommerce, OpenCart, PrestaShop, Laravel, özel PHP ve genel web uygulamalarında dış performans katmanı incelenebilir. Uygulama içi teşhis yöntemleri altyapıya göre değişir.
Evet. Ücretsiz dış analiz siteyi kim geliştirdiğinden bağımsızdır. Ücretli müdahale aşamasında kaynak koda veya API’ye erişim ve lisans koşulları ayrıca değerlendirilir.
Ana sayfa yanında kategori, ürün, sepet ve checkout akışı önemlidir. Trafiği yüksek landing page’ler de ayrıca test edilmelidir.
Laboratuvar testinde ağ, sunucu yükü, üçüncü taraf yanıtları ve cache durumu küçük değişiklikler yaratabilir. Tek test yerine birkaç koşuyu ve saha verisini birlikte değerlendirmek daha sağlıklıdır.
Lighthouse sonucu hemen değişebilir fakat PageSpeed/Search Console saha verileri gerçek kullanıcıların önceki 28 günlük penceresini kullandığı için değişimin görünmesi zaman alabilir.
Hayır. Ön analiz size sorunun yönünü göstermek içindir. Müdahale teklifini kabul etmek zorunda değilsiniz.
Site adresinizi ve varsa yavaşlık yaşadığınız sayfayı iletin. İlk aşamada şifre göndermenize gerek yoktur. Telefon ve WhatsApp: 0850 307 34 58.
Eka Sunucu bağımsız teknik destek ve analiz hizmeti sunar. Google, WordPress, WooCommerce veya Cloudflare’ın resmî destek ekibi ya da yetkili temsilcisi değildir.