Web Sitesi Neden Yavaş Açılır? Sunucu Kaynaklı 10 Neden ve Çözüm

Web sitesi neden yavaş açılır?

Web sitesi yavaş açılır, çünkü sunucu ilk yanıtı geç üretir ya da bu yanıt tarayıcıya geç ulaşır. En sık nedenler yetersiz hosting kaynağı, eski PHP sürümü, yavaş veritabanı sorguları, eksik önbellek, DNS ve TLS gecikmesi, bot trafiği ve şişmiş eklentilerdir. Önce ölçün, sonra düzeltin.

Sayfa yavaşlığının iki ayrı kaynağı vardır. Birincisi sunucu tarafıdır: tarayıcı isteği gönderir, ama cevap geç gelir. İkincisi tarayıcı tarafıdır: cevap hızlı gelir, fakat görseller, betikler ve yazı tipleri ekranı geciktirir. Bu yazı yalnızca birincisini anlatır.

Görsel, JavaScript ve Core Web Vitals ayrıntısını burada tekrarlamıyoruz. Bunun için site hızının SEO etkisini, görsel optimizasyonunu ve JavaScript etkisini anlatan yazılara bakın.

Yavaşlığı ziyaretçi farklı hisseder, siz farklı ölçersiniz. Ziyaretçi için sayfa beyaz ekranda kalır. Sizin ölçümünüzde ise bu bekleme tek bir sayıya dönüşür. Dolayısıyla ilk iş, hissi ölçülebilir bir değere çevirmektir. Bu değer olmadan hiçbir düzeltmenin işe yarayıp yaramadığını anlayamazsınız.

Siteyi kendi VPS ya da cPanel hesabınızda yönetiyorsanız komutları adım adım uygulayabilirsiniz. Yönetimi hosting firmasına bırakmışsanız, hangi bulguyu sağlayıcınıza nasıl ileteceğinizi öğrenirsiniz. Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu nedenle anlatım resmi dokümanlara ve standartlara dayanır.

Web sitesi neden yavaş açılır: sorun sunucuda mı, tarayıcıda mı?

Önce sorunun nerede olduğunu ayırın. Tarayıcıda geliştirici araçlarını açın ve ağ panelinde ilk belge isteğine bakın. Bu isteğin zaman çizelgesinde sunucu yanıtını bekleme süresi ayrı görünür. Bu süre uzunsa sorun büyük olasılıkla sunucu tarafındadır.

Bekleme süresi kısa, ama sayfa yine geç görünüyorsa sorun tarayıcı tarafındadır. Örneğin ağır görseller ya da engelleyen betikler olabilir. Bu durumda doğru adres görsel ve JavaScript yazılarımızdır.

Bir de ikisini birden yaşayan siteler var. Üstelik bu çok yaygındır. Sunucu yavaş cevap verir, üstüne sayfa da ağırdır. Böyle bir durumda sırayla ilerleyin: önce sunucu tarafını düzeltin, çünkü diğer tüm yükleme adımları ilk baytın gelmesini bekler.

Tek bir ölçümle karar vermeyin. Aynı sayfayı farklı saatlerde ve farklı ağlardan deneyin. Gece hızlı, öğleden sonra yavaş bir site çoğu zaman kaynak limiti ya da trafik sorununa işaret eder. Sürekli yavaş bir site ise genellikle önbellek, veritabanı ya da yapılandırma sorunu taşır.

TTFB nedir ve hangi değer yavaş sayılır?

TTFB, yani ilk bayt süresi, sayfaya gitmeye başladığınız an ile yanıtın ilk baytının gelmeye başladığı an arasındaki süredir. web.dev bu süreye yönlendirmeleri, DNS sorgusunu, bağlantı ve TLS anlaşmasını ve sunucunun yanıt üretme aşamasını dahil eder.

Aynı kaynak eşikleri de verir: iyi TTFB değerleri 0,8 saniye ve altıdır, kötü değerler 1,8 saniyenin üzerindedir. Bu aralık genel bir hedeftir. Sunucuda üretilen bir sayfa ile tamamen istemcide oluşan bir sayfa aynı ölçüyle yorumlanmaz.

TTFB bir Core Web Vitals metriği değildir. Ancak LCP gibi metrikler ilk baytın gelmesini bekler. Yani TTFB kötüyse sonraki her adım geç başlar. Bu yüzden teşhise buradan başlıyoruz.

TTFB tek bir sayı olsa da içinde birkaç ayrı gecikme saklıdır. Aşağıdaki bölümler bu parçaları tek tek ayırır:

• Yönlendirme zinciri ve HTTP'den HTTPS'e geçiş.
• DNS çözümleme süresi.
• TCP bağlantısı ve TLS anlaşması.
• Sunucunun sayfayı üretme süresi: PHP, veritabanı, önbellek.

Web sitesi neden yavaş açılır sorusunda teşhise hangi sırayla başlamalısınız?

Rastgele ayar değiştirmek en pahalı yoldur. Çünkü hangi değişikliğin işe yaradığını bilemezsiniz. Aşağıdaki sıra, ucuz ve risksiz kontrolden pahalı ve riskli müdahaleye doğru ilerler:

1. Ana sayfanın ilk bayt süresini birkaç kez ölçün ve değerleri not edin.
2. DNS, bağlantı, TLS ve sunucu süresini birbirinden ayırın.
3. Yönlendirme zincirini sayın.
4. Önbellek başlıklarını ve sayfa önbelleğini kontrol edin.
5. PHP sürümünü ve bellek sınırlarını kontrol edin.
6. Yavaş veritabanı sorgularını kayda alın.
7. Erişim kayıtlarında bot ve saldırı trafiğini arayın.

İlk iki adım için tek bir komut yeterlidir. Aşağıdaki örnek, curl aracının zaman değişkenlerini kullanır. example.com yerine kendi adresinizi yazın:

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

Çıktıdaki değerler kümülatiftir. Yani ilk bayt değerinden TLS değerini çıkarırsanız sunucunun yanıt hazırlama süresini yaklaşık olarak bulursunuz. Örnek hesap: TLS 0,25, ilk bayt 1,45 görüyorsanız sunucu tarafında yaklaşık 1,2 saniye geçmiştir. Bu rakamlar yalnızca örnektir.

Komutu en az beş kez çalıştırın. İlk çalıştırma genellikle soğuk önbellekle gelir, sonrakiler daha hızlıdır. Bu fark bile başlı başına bir ipucudur.

Sunucu içinde zamanın nereye gittiğini nasıl görürsünüz?

Dıştan ölçüm, gecikmenin sunucuda olduğunu söyler, ama nerede olduğunu söylemez. Bunun için sunucu yanıtına Server-Timing başlığı ekleyebilirsiniz. MDN belgesine göre bu başlık, istek ve yanıt döngüsüne ait ölçümleri tarayıcıya iletir. Örneğin veritabanı okuma süresi ya da işlemci süresi bu yolla görünür.

Server-Timing: db;dur=53, app;dur=47.2

Örnek başlıkta db, veritabanı süresini milisaniye olarak gösterir. app ise uygulama kodunun süresidir. Bu değerleri tarayıcının ağ panelinde Timings bölümünde görürsünüz. web.dev de aynı başlığı veritabanı sorgularını, sayfa üretim süresini ve önbellek isabetlerini ölçmek için önerir.

Başlığı üretmek kod gerektirir. Dolayısıyla bu adım yazılımcınızın ya da eklenti geliştiricisinin işidir. Siz yalnızca ne istediğinizi bilin: sayfa üretimini en az üç parçaya bölen bir zaman ölçümü. Böylece tartışma tahminden çıkar, sayıya dönüşür.

Başlığı canlıya açarken dikkatli olun. Ölçüm adları sistem ayrıntısı sızdırabilir. Bu yüzden ayrıntıyı yalnızca test ortamında ya da kısıtlı bir erişimle açmayı düşünün.

1. Hosting kaynak limiti sitenizi nasıl yavaşlatır?

Paylaşımlı hosting, aynı makinenin işlemci, bellek ve disk gücünü birçok siteyle paylaşır. Sağlayıcılar hesap başına sınır koyar. Sınırı aşan bir site kısıtlanır, yani istekler kuyrukta bekler ve ilk bayt süresi uzar.

Tipik belirti zamana bağlı yavaşlıktır. Site sabah hızlıdır, kampanya saatinde ya da yedekleme sırasında yavaşlar. Birçok panelde kaynak kullanımı ekranı bulunur. Ekranın adı ve ayrıntısı sağlayıcıya göre değişir, bu yüzden panelinizde ilgili bölümü arayın.

web.dev de bu konuya değinir. Uygulamanın belleği yetersizse sayfaları hızlı sunmakta zorlanacağını belirtir. Yani sorun kodunuzda değil, aldığınız paketin tavanında olabilir.

Çözüm sırası şöyledir: önce gereksiz süreçleri azaltın, ardından önbellek ekleyin. Hâlâ sınıra çarpıyorsanız paket yükseltmeyi düşünün. Hosting seçerken nelere bakacağınızı hosting seçimi rehberimizde anlattık.

Dürüst olalım: kaynak limitini siz değiştiremezsiniz. Bu karar sağlayıcıdadır. Siz yalnızca kanıt toplarsınız: saat bazlı ölçümler ve panelden alınan kullanım ekranı görüntüleri destek talebinizi güçlendirir.

2. Eski PHP sürümü sitenizi yavaşlatır ve riske atar mı?

PHP projesi her sürüm dalına iki tür destek verir. php.net sayfasına göre ilk iki yıl hata ve güvenlik düzeltmeleri gelir, sonraki iki yıl yalnızca güvenlik düzeltmeleri gelir. Dört yılın sonunda sürüm yaşam sonuna ulaşır ve hiçbir yama yayımlanmaz.

Yani eski sürüm yalnızca yavaş değil, aynı zamanda savunmasızdır. Hız tarafında kesin bir kazanç rakamı vermiyoruz, çünkü kazanç uygulamaya göre değişir. Ancak güncel sürümlerin sürüm notlarında performans iyileştirmelerini okuyabilirsiniz.

Sürümünüzü öğrenmek için sunucuda şu komut yeterlidir:

php -v

cPanel kullanıyorsanız sürüm seçimi genellikle MultiPHP Manager ekranındadır. WordPress yönetim panelinde Araçlar altındaki Site Sağlığı sayfası da PHP sürümü hakkında uyarı verebilir.

Sürümü canlı sitede doğrudan değiştirmeyin. Önce bir test kopyasında deneyin, çünkü eski eklentiler ve temalar yeni sürümde hata verebilir. Hangi sürümün güncel kararlı sürüm olduğunu php.net sayfasından kontrol edin.

3. Yavaş veritabanı sorguları sayfayı nasıl geciktirir?

Dinamik bir sayfa üretilirken PHP veritabanına onlarca sorgu gönderebilir. Tek bir indekssiz sorgu, tablo büyüdükçe saniyelere çıkabilir. Böyle bir sorgu tüm sayfayı bekletir, yani ilk bayt süresi doğrudan etkilenir.

MySQL dokümanına göre yavaş sorgu günlüğü varsayılan olarak kapalıdır. long_query_time değişkeninin varsayılan değeri 10 saniyedir. Bu yüzden günlüğü açmakla yetinmeyin, eşiği de düşürün. Aşağıdaki ayarlar örnektir:

[mysqld]
slow_query_log = 1
long_query_time = 2
slow_query_log_file = /var/log/mysql/slow.log

Dosya yolu dağıtıma göre değişir. Günlük birikince mysqldumpslow aracı içeriği özetler. Şüpheli bir sorguyu EXPLAIN ile inceleyin:

EXPLAIN SELECT * FROM orders WHERE customer_id = 42;

Çıktıda tüm tablonun taranması görünüyorsa uygun bir indeks eksik olabilir. Ancak indeks eklemeden önce yedek alın. Yedekleme konusunda yedekleme stratejisi yazımıza göz atın. Sorgu mantığını tazelemek isterseniz SQL sorgu senaryoları yazısı da işinize yarar.

Paylaşımlı hostingte bu ayarlara erişiminiz çoğunlukla yoktur. Bu durumda sağlayıcıdan yavaş sorgu özetini isteyin.

4. Önbellek yoksa sunucu her ziyaretçi için sayfayı baştan mı üretir?

Evet, önbellek yoksa her ziyaret aynı işi yeniden yaptırır. PHP çalışır, veritabanı sorgulanır, HTML birleştirilir. Oysa blog yazısı ya da kategori sayfası gibi içerik günlerce aynı kalabilir. Bu işi her seferinde tekrarlamak kaynak israfıdır.

Üç katmanı ayırın:

• Sayfa önbelleği, hazır HTML'i doğrudan sunar.
• Nesne önbelleği, sık kullanılan veritabanı sonuçlarını bellekte tutar.
• PHP'nin kendi OPcache eklentisi, derlenmiş kodu saklar.

Tarayıcı tarafı için Cache-Control başlıkları da önemlidir. web.dev, statik ve yarı statik içerik için uygun Cache-Control başlıkları ayarlamayı ve önbellek geçersiz kılma stratejisi kurmayı önerir. Nesne önbelleği ayrıntısı için Redis ve Memcached yazımızı okuyun.

Dikkat edin: sepet, ödeme ve hesap sayfaları sayfa önbelleğinin dışında kalmalıdır. Aksi hâlde bir müşteri başkasının sepetini görebilir. E-ticaret sitelerinde bu ayarı uygulayan eklentinin istisna listesini mutlaka kontrol edin.

5. DNS gecikmesi ilk bayt süresini uzatır mı?

Evet, uzatır, ama çoğu sitede küçük bir pay oluşturur. Tarayıcı sunucuya bağlanmadan önce alan adını IP adresine çevirmek zorundadır. Bu çözümleme yavaşsa tüm istek gecikir. Alan adı sağlayıcınızın DNS sunucuları yavaş ya da kayıt zinciri uzunsa fark hissedilir.

Kontrol için dig komutunu kullanın. Çıktının sonundaki Query time satırı çözümleme süresini milisaniye olarak gösterir:

dig example.com

Tarayıcıdan bakmak isterseniz DNS sorgulama aracımız A, CNAME ve NS kayıtlarını listeler. Alan adının hangi sunucularda durduğunu görmek için WHOIS sorgulama ve IP sorgulama araçları da yardımcı olur.

Kayıtlar arasında gereksiz CNAME zincirleri, eski ve artık kullanılmayan alt alan adları ya da tutarsız NS kayıtları arayın. Ayrıca IPv6 desteğiniz varsa IPv6 testiyle iki protokolün de çalıştığını doğrulayın.

DNS kayıtlarını değiştirirken dikkatli olun. Yanlış bir kayıt e-postayı ve siteyi birlikte düşürebilir. Emin değilseniz değişikliği alan adı ya da hosting sağlayıcınıza bırakın.

6. TLS ve yönlendirme zinciri ilk baytı nasıl geciktirir?

Her yönlendirme ek bir istek turu demektir. Ziyaretçi http adresini yazar, sunucu https adresine yönlendirir, ardından www adresine yönlendirir. Üç adımlık bir zincir, ilk bayttan önce üç ayrı bekleme yaratır. web.dev de yönlendirmelerin gecikmeleri toplayarak artırdığını belirtir.

Zinciri görmek için şu komutu çalıştırın:

curl -sIL -o /dev/null -w "yonlendirme: %{num_redirects}\nson_adres: %{url_effective}\n" http://example.com/

Yönlendirme sayısı birden fazlaysa zinciri kısaltın. Hedef, her eski adresin doğrudan son adrese gitmesidir. Tarayıcıda görmek için yönlendirme denetleyici aracımız işinizi görür.

web.dev ayrıca HSTS başlığını önerir. Bu başlık, tarayıcının sonraki ziyaretlerde HTTP'den HTTPS'e yönlendirme turunu atlamasına yardım eder. Sertifikanızın geçerliliğini ve zincirini SSL sorgulama aracıyla kontrol edin. Sertifikanın ne işe yaradığını SSL sertifikası yazımızda bulabilirsiniz.

HSTS'i dikkatsiz açmayın. Bir kez yayılınca geri almak zordur, çünkü tarayıcılar kuralı saklar. Önce tüm alt alan adlarınızın HTTPS'e hazır olduğundan emin olun.

7. Bot ve DDoS trafiği siteyi nasıl yavaşlatır?

Her istek, ister insandan ister bottan gelsin, sunucuda iş yaratır. Sahte botlar, aşırı agresif tarayıcılar ya da saldırı trafiği kaynakları tüketince gerçek ziyaretçiler yavaşlıkla karşılaşır. Belirti genellikle ani ve açıklanamayan bir yük artışıdır.

Önce erişim kayıtlarına bakın. Aşağıdaki komut, kayıtta en çok istek gönderen adresleri sıralar. Kayıt dosyasının yolu kurulumunuza göre değişir ve ilk alanın IP olduğu varsayılır:

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -10

Kayıtları tarayıcıdan incelemek isterseniz log analizi aracımız kullanılabilir. Gelen her yoğun trafiği engellemeyin. Google, aşırı yük durumunda 500, 503 ya da 429 yanıtı vermeyi önerir, ancak uzun süren hata yanıtlarının sitenin Google'daki görünümüne zarar verebileceğini de tarama hızı dokümanında söyler.

Gerçek Googlebot'u sahtesinden ayırmak için Googlebot doğrulama yazımıza bakın. Taramanın neden yavaşladığını merak ediyorsanız tarama sıklığı yazımız devreye girer.

Büyük hacimli bir saldırıyı kendiniz durduramazsınız. Bu iş ağ seviyesinde koruma gerektirir. Hosting sağlayıcınızı ya da bir kenar koruma hizmetini hemen devreye alın.

8. Eklenti şişmesi WordPress sitesini nasıl yavaşlatır?

Her eklenti sayfa üretimine kod ve çoğu zaman ek sorgu ekler. Sorun eklenti sayısında değil, her birinin maliyetindedir. On temiz eklenti, tek bir özensiz eklentiden daha ucuz çalışabilir. Bu yüzden sayı saymayın, maliyeti ölçün.

WordPress.org üzerinde yayımlanan Query Monitor eklentisi, sayfa başına sorguları ve bunların hangi eklenti ya da temadan geldiğini gösterir. Önce test kopyasında kurun. Ardından yavaş sorguları ve tekrar eden istekleri bileşen bazında inceleyin.

Bir de veritabanı şişmesi var. WordPress seçenekler tablosundaki bazı kayıtlar her sayfa yüklemesinde otomatik okunur. Kaldırdığınız eklentilerin artıkları bu alanı büyütebilir. Böylece her sayfa gereksiz veri taşır.

Zamanlanmış görevler de bir başka kaynaktır. WordPress'in kendi zamanlayıcısı ziyaretlerle tetiklenir. Ağır görevler yoğun saatlere denk gelirse ilk bayt süresini uzatabilir.

Kural basittir: kullanmadığınız eklentiyi kaldırın, aynı işi yapan iki eklentiden birini bırakın. Temel yapı kararı vermeniz gerekiyorsa WordPress mi, özel kodlama mı yazımıza göz atın. Canlı sitede eklenti silmeden önce mutlaka yedek alın.

9. CDN ve sunucu mesafesi ilk baytı ne kadar etkiler?

Sunucunuz ile ziyaretçi arasındaki fiziksel mesafe gecikmeyi artırır. Sunucunuz Avrupa'da, ziyaretçiniz başka bir kıtadaysa her bağlantı turu daha uzun sürer. TLS anlaşması birkaç tur gerektirdiği için fark katlanır.

web.dev bu sorunun çözümü olarak CDN önerir. CDN, kaynakları ziyaretçiye daha yakın sunuculardan sunar. Ayrıca CDN sağlayıcıları genellikle hızlı DNS, HTTP/2, HTTP/3 ve modern TLS sunar.

Ancak CDN her şeyi çözmez. Önbelleğe alınamayan dinamik sayfalar yine kaynak sunucuya gider. Benzersiz sorgu parametreleri de CDN önbelleğini engelleyebilir. Örneğin her isteğe farklı bir izleme parametresi eklenirse önbellek isabeti düşer.

Kendi sitenizde bunu denemek için ziyaretçilerinizin çoğunun nerede olduğuna bakın. Hedef kitleniz tek ülkedeyse sunucuyu o ülkeye yakın seçmek, çoğu zaman CDN kadar etkilidir. Bu karar için hosting sağlayıcınızın veri merkezi listesine bakın.

10. VPS'te bellek ve işlemci neden tükenir?

Kendi VPS'inizde kaynak sınırını siz belirlersiniz, ama bu sorumluluk da size geçer. Bellek biterse sistem diske takas yapar ve her şey yavaşlar. web.dev bunu tam olarak böyle tarif eder: yetersiz bellekte uygulama zorlanır.

Üç komut hızlı bir fotoğraf verir:

free -h
uptime
ps aux --sort=-%mem | head -5

İlki bellek ve takas kullanımını, ikincisi yük ortalamasını, üçüncüsü en çok bellek yiyen süreçleri gösterir. Bellek yetersizliği nedeniyle bir sürecin sistem tarafından sonlandırılıp sonlandırılmadığını çekirdek kayıtlarında arayabilirsiniz.

PHP-FPM kullanıyorsanız eşzamanlı işçi sayısı belirleyicidir. Çok düşükse istekler kuyrukta bekler. Çok yüksekse bellek biter. İdeal değer, sunucunun belleğine ve sitenizin işlem boyutuna bağlıdır. Bu yüzden rastgele sayı yazmayın, PHP-FPM yapılandırma belgesini okuyun.

Bu aşamada dikkatli olun. Yanlış bir işçi sayısı siteyi tamamen durdurabilir. Güvenli bir yedeğiniz ve geri dönüş planınız yoksa değişikliği bir uzmana bırakın.

Hangi araçla neyi ölçersiniz?

Aşağıdaki tablo, bu yazıda geçen araçları tek bakışta toplar. Son sütun, hangisini ne zaman seçeceğinizi gösterir.

Tek araçla yetinmeyin. Dıştan ölçüm ile içeriden ölçümü birleştirdiğinizde teşhis hızlanır. Bu sayede sağlayıcınızla konuşurken elinizde somut veri olur.

10 nedeni tek tabloda nasıl özetleriz?

Aşağıdaki tablo her nedenin tipik belirtisini ve ilk doğrulama adımını yan yana koyar. Böylece teşhis sırasında hızlıca geri dönebilirsiniz. Web sitesi neden yavaş açılır sorusunun cevabı çoğu zaman tek satır değildir. Genellikle iki ya da üç neden üst üste biner, bu yüzden tabloyu baştan sona okuyun.

Ne zaman kendiniz yapmamalı, hosting sağlayıcınıza bırakmalısınız?

Her şeyi kendiniz çözmeye çalışmak çoğu zaman pahalıya patlar. Aşağıdaki durumlarda işi sağlayıcınıza ya da deneyimli bir sistem yöneticisine bırakın:

• Paylaşımlı hostingte sunucu ayarlarına erişiminiz yoksa.
• Saldırı trafiği ağ seviyesinde geliyorsa.
• Veritabanı yapısını yedeksiz değiştirmeniz gerekiyorsa.
• Canlı bir e-ticaret sitesinde PHP sürümünü test etmeden yükseltecekseniz.
• Sorun kaynak limitinden kaynaklanıyor ve paket değişikliği gerekiyorsa.
• Komutun ne yaptığından emin değilseniz.

Bu liste çekingenlik değil, risk yönetimidir. Yanlış bir komut siteyi, e-postayı ve verileri birlikte etkileyebilir. Destek talebi açarken ölçüm değerlerinizi ve ne zaman yavaşladığını ekleyin. Böylece sağlayıcı sorunu daha hızlı bulur.

Güvenlik tarafında da aynı dürüstlükle yaklaşın. Sunucu yavaşlığı bazen bir sızma belirtisidir. Bu şüphe varsa OWASP Top 10 yazımızı okuyun ve uzman desteği alın.

Sayfa yavaşlığı SEO ve satışları nasıl etkiler?

Yavaş sunucu iki yoldan zarar verir. Ziyaretçi sayfa açılmadan siteyi terk eder. Arama motoru botu da sunucu hata verdiğinde taramayı azaltır. Google'ın dokümanına göre yoğun 500, 503 ya da 429 yanıtları tarama hızını düşürür ve bu düşüş hostname'in tamamını etkiler.

E-ticarette etki doğrudan gelire döner. Sepete kadar giden yolda her gecikme bir kayıp fırsattır. Konunun ayrıntısını e-ticarette sayfa hızı yazımızda bulabilirsiniz.

Ölçüm tarafında Lighthouse testi ve Core Web Vitals yazılarımız, tarayıcı tarafındaki gecikmeyi anlamanıza yardım eder. Sunucu düzelince bu ölçümler de çoğu zaman birlikte iyileşir. Ancak hangi metriğin ne kadar düzeleceğini önceden vaat etmiyoruz.

Düzeltmeden sonra iyileşmeyi nasıl doğrularsınız?

Web sitesi neden yavaş açılır sorusuna tek bir kesin cevap aramayın. Her düzeltme, ölçümde kalan payı küçültür ve geriye yeni bir en büyük neden bırakır. Bu nedenle süreç bir döngüdür: ölç, tek şeyi düzelt, yeniden ölç.

Her değişiklikten önce ve sonra aynı ölçümü aynı koşullarda alın. Aynı sayfa, aynı saat aralığı, aynı komut. Değişiklikleri tek tek yapın. Aynı anda üç ayar değiştirirseniz hangisinin işe yaradığını bilemezsiniz.

Tek ölçüm yeterli değildir. Komutu en az beş kez çalıştırın, en yüksek ve en düşük değeri atmayın, ama genel eğilime bakın. Ayrıca önbelleğin ısınmış hâlini ve soğuk hâlini ayrı ayrı not edin.

Gerçek ziyaretçi verisi daha yavaş birikir. web.dev, alan verisi için Chrome Kullanıcı Deneyimi Raporu ve web-vitals kütüphanesini önerir. Bu veri günler içinde değişmeyebilir. Bu yüzden laboratuvar ölçümüyle başlayın, alan verisini sonra izleyin.

Ayrıca bir ölçüm günlüğü tutun. Tarih, yapılan değişiklik ve önceki sonraki değer yan yana dursun. Altı ay sonra sorun geri geldiğinde bu günlük size zaman kazandırır.

Ekibimiz bu süreçte nasıl yardımcı olur?

Biz hosting sağlayıcısı değiliz ve sunucu işletme hizmeti vermiyoruz. Dijital pazarlama ve web ekibi olarak yavaşlığın iş sonuçlarına etkisini ölçmenize, hangi sorunun sunucuya hangisinin siteye ait olduğunu ayırmanıza yardım ederiz.

Yeni bir site planlıyorsanız performansı en baştan hesaba katan bir yapı kurarız. Bunun için web tasarım hizmetimize bakabilirsiniz. Arama görünürlüğü tarafında SEO danışmanlığımız teknik bulguları içerik planıyla birleştirir. Mağazanız varsa e-ticaret danışmanlığı sayfamıza göz atın.

Küçük bir not: bu yazıdaki komutların hiçbiri sihirli değildir. Her biri yalnızca bir soruya cevap verir. Cevabı yorumlamak, yani hangi değerin sizin siteniz için normal olduğunu bilmek, zaman ve karşılaştırma ister. Bu yüzden ilk ölçümleri bugün alın, çünkü yarın elinizde kıyaslayacak bir referans olur.

Sunucu müdahalesi gerektiren bulguları sizin adınıza değil, sağlayıcınızla birlikte çözmenizi öneririz. Biz bulguyu net biçimde yazar, ne istemeniz gerektiğini birlikte netleştiririz. Böylece destek talebiniz belirsiz bir şikayet olmaktan çıkar.