Site Yavaş Açılıyor: Nedenleri ve Adım Adım Teşhis Sırası

Bir site yavaş açılıyor ise neden neredeyse her zaman iki yerden birindedir: ya sunucu sayfayı geç üretiyordur ya da tarayıcı sayfayı oluşturan dosyaları geç indirip işliyordur. Hangisi olduğunu bilmeden yapılan her müdahale, örneğin rastgele bir önbellek eklentisi kurmak ya da paketi büyütmek, şansa kalır.

Aşağıdaki teşhis sırası en ucuz ve en sık görülen nedenlerden başlar, her adımda neye bakacağınızı ve hangi bulgunun hangi çözüme götürdüğünü gösterir. Kalıcı hız iyileştirme tekniklerinin tamamı web sitesi hızlandırma rehberi yazısındadır; burada amaç sorunun kaynağını bulmaktır. Yoğun trafikli kurumsal sitelerde ayrılmış kaynak sunan kurumsal hosting paketleri, paylaşımlı ortamdaki komşu etkisini ortadan kaldırarak teşhisi de kolaylaştırır.

Site yavaş açılıyorsa ilk olarak neyi ölçmelisiniz?

İlk ölçülecek değer TTFB’dir (Time To First Byte, ilk bayta kadar geçen süre); sunucunun isteği alıp yanıtın ilk baytını göndermesi için geçen zamanı gösterir ve sorunun sunucuda mı tarayıcıda mı olduğunu ayırır. Terminalde şu komut adım adım süreleri verir:

curl -o /dev/null -s -w 'dns: %{time_namelookup}\nbaglanti: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntoplam: %{time_total}\n' https://alanadiniz.com/

Komutu birkaç kez ve farklı saatlerde çalıştırın; tek ölçüm yanıltıcıdır. Değerleri yorumlarken şuna dikkat edin:

• TTFB, toplam sürenin büyük kısmıysa darboğaz sunucu tarafındadır: kaynaklar, PHP, önbellek ya da veritabanı.
• TTFB kısa, sayfa yine de geç doluyorsa sorun ön yüzdedir. Tarayıcının geliştirici araçlarındaki Network sekmesi ya da PageSpeed Insights, hangi dosyanın beklettiğini gösterir.
• dns ya da tls satırları uzunsa sorun sayfadan önce, ad çözümleme veya bağlantı kurulumundadır.

Yönetici olarak oturum açıkken ölçmeyin; çoğu önbellek oturum açmış kullanıcıya devre dışıdır ve size gerçek ziyaretçiden daha yavaş bir site gösterir.

Sunucu kaynakları ve hosting limitleri yavaşlığa neden olur mu?

Evet; paylaşımlı hostingde işlemci, bellek, eş zamanlı işlem (entry process) ya da disk G/Ç sınırına ulaşan hesap, istekleri sıraya alır ve sayfa saniyelerce bekler. Bu durum genellikle günün belirli saatlerinde, kampanya e-postasından sonra ya da bir arama motoru botu siteyi taradığında belirginleşir.

cPanel’de CloudLinux kullanan sunucularda Metrics bölümündeki Resource Usage ekranı, son günlerde hangi limite kaç kez dayandığınızı gösterir. Limit aşımı varsa önce nedeni arayın: aynı sayfayı dakikada yüzlerce kez çağıran bir bot, sık tetiklenen bir wp-cron.php ya da sonsuz döngüye giren bir eklenti, paket büyütmekten daha ucuz çözülür. Limitlerin ne anlama geldiği ve nasıl izlendiği hosting kaynak limitleri rehberinde ayrıntılı anlatılır.

Gerçek trafik büyümesi limitleri dolduruyorsa kaynak artırmak doğru adımdır. Sürekli yüksek yük, özel yazılım ya da arka plan işleri varsa tam kontrol sağlayan bir VPS sunucu daha uygun olabilir; orada top ya da htop ile hangi işlemin işlemciyi tükettiğini doğrudan görürsünüz.

PHP sürümü ve önbellek eksikliği nasıl anlaşılır?

Desteği bitmiş eski bir PHP sürümü ve sayfa önbelleğinin olmaması, TTFB’nin yüksek çıkmasının en sık iki nedenidir. Kontrol için üç adım yeterlidir:

1. PHP sürümünü görün: cPanel’de MultiPHP Manager, Plesk’te PHP Settings ekranı alan adının kullandığı sürümü gösterir. Güncel ve desteklenen bir sürüme geçiş çoğu zaman tek başına belirgin kazanç sağlar; önce bir kopyada uyumluluğu test edin. Adımlar cPanel PHP sürümü değiştirme rehberinde.
2. OPcache durumunu kontrol edin: Derlenmiş PHP kodunu bellekte tutan OPcache kapalıysa her istek dosyaları yeniden derler. PHP eklenti listesinde açık olup olmadığına bakın.
3. Sayfa önbelleğini doğrulayın: Yanıt başlıklarında önbellek isabetini gösteren bir alan (ör. x-litespeed-cache: hit ya da eklentinizin eklediği başlık) var mı bakın. Yoksa her ziyaretçi için sayfa PHP ve veritabanı üzerinden yeniden üretiliyordur.

WordPress sitelerde önbellek eklentisi seçimi ve ayarları WordPress hızlandırma yazısında ele alınır; burada yalnızca önbelleğin gerçekten çalışıp çalışmadığını bilmek yeterlidir.

Veritabanındaki yavaş sorgular nasıl bulunur?

Yavaş sorgular, MySQL ya da MariaDB’nin yavaş sorgu günlüğü (slow query log) veya uygulama içi sorgu izleme araçlarıyla bulunur; önbellek çalıştığı hâlde sepet, arama ve yönetim paneli gibi dinamik sayfalar yavaşsa ilk şüpheli veritabanıdır.

Root erişiminiz olan bir sunucuda günlüğü geçici olarak açabilirsiniz:

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 1;
SHOW VARIABLES LIKE 'slow_query_log_file';

Paylaşımlı hostingde bu ayar sizin yetkinizde değildir; WordPress için Query Monitor gibi bir eklenti hangi sorgunun ne kadar sürdüğünü sayfa bazında gösterir. Sık görülen bulgular şunlardır:

• Dizin (index) olmayan sütunlarda arama yapan sorgular.
• wp_options tablosunda otomatik yüklenen (autoload) şişkin kayıtlar.
• Yıllardır temizlenmemiş günlük, oturum ya da istatistik tabloları.

Tablo onarımı ya da dizin eklemeden önce mutlaka veritabanı yedeği alın.

Eklentiler, görseller ve üçüncü taraf betikler sayfayı nasıl yavaşlatır?

TTFB normal olduğu hâlde sayfa geç doluyorsa yük ön yüzdedir: tarayıcı çok sayıda ya da çok büyük dosya indiriyor veya JavaScript çalıştırmakla meşgul oluyordur. Teşhis için tarayıcının Network sekmesinde listeyi boyuta ve süreye göre sıralayın.

• Ağır eklentiler ve tema bileşenleri: Her sayfaya kendi CSS ve JavaScript dosyasını ekleyen form, kaydırıcı ya da sayfa oluşturucu eklentileri istek sayısını katlar. Bir kopya üzerinde eklentileri tek tek kapatıp ölçmek, suçluyu en hızlı bulan yöntemdir.
• Görseller: Telefondan yüklenmiş, birkaç megabaytlık fotoğraflar sık rastlanan bir nedendir. Görselleri gösterildikleri boyuta küçültün, WebP gibi modern biçimlere dönüştürün ve ekran dışındakileri geç yükleyin.
• Üçüncü taraf betikler: Canlı destek, reklam, ısı haritası ve sosyal medya bileşenleri sizin sunucunuzda değil başka sunucularda çalışır; onlar yavaşsa siteniz de yavaş görünür. Gerçekten kullanmadıklarınızı kaldırın, kalanları geciktirerek yükleyin.

Bu tür sorunlar Google’ın kullanıcı deneyimi ölçütlerine de doğrudan yansır; ayrıntılar için Core Web Vitals nedir yazısına bakın.

DNS ve CDN ayarları yavaşlığa yol açar mı?

Evet, ama etkileri sayfa içeriğinden önce, bağlantı aşamasında görülür; curl çıktısındaki dns ve tls süreleri uzunsa bu katmana bakın. Yavaş yanıt veren ya da yanlış yapılandırılmış ad sunucuları her yeni ziyaretçide gecikme ekler. dig alanadiniz.com komutundaki Query time değeri ve ad sunucularının tutarlı yanıt verip vermediği ilk kontrol noktasıdır.

CDN (içerik dağıtım ağı) doğru ayarlandığında statik dosyaları ziyaretçiye yakın noktalardan sunar; yanlış ayarlandığında ise her isteği önbelleğe almadan kaynak sunucuya iletir ve araya fazladan bir durak ekler. CDN arkasındaki bir sitede yanıt başlıklarındaki önbellek durumunu kontrol edin; sürekli “miss” ya da “bypass” görüyorsanız önbellek kuralları çalışmıyordur. CDN’in ne zaman fayda sağladığı CDN nedir yazısında anlatılır. Altyapı tarafında ise sağlayıcının ağ kapasitesi önemlidir: LIONFIN veri merkezimiz toplam 600G çıkış kapasitesiyle çalışır ve 7/24 NOC ekibince izlenir.

Belirtiye göre neden ve çözüm tablosu

Aşağıdaki tablo, site yavaş açılıyor şikâyetinde en sık görülen belirtileri olası nedenleri ve ilk müdahaleyle eşleştirir:

Kendi ölçümlerinizle sorunu daraltamazsanız curl çıktısını ve yavaşlığın görüldüğü saatleri müşteri panelinden açacağınız destek talebine ekleyin; somut veri, sorunun çok daha hızlı çözülmesini sağlar.