Mutlu Kullanıcılar, Daha Yüksek Sıralamalar için Sunucu Yanıt Sürenizi Azaltın

Sayfa hızını artırma söz konusu olduğunda sunucu yanıt süresi genellikle gözden kaçar.

Ancak, sitenizin sıralamasını iyileştirebilir. Kullanıcılar hızlı siteleri sever, bu nedenle Google hızlı siteleri sever. Bu yazıda, sunucu yanıt sürenizi nasıl azaltacağınızı gösteriyorum. Ayrıca sayfa hızınızı artırmanın birkaç yolunu daha sunuyorum.

Sunucu yanıt süresi ne kadar önemlidir?

Sunucu Yanıt Süresi (SRT), bir web istemcisinin bir istekte bulunması (örneğin, bir bağlantıya tıklamak veya adres çubuğuna bir URL girmek) ile sunucunun bu isteğe yanıt vermesi arasındaki süredir.

İyi bir SRT ve hız için optimize edilmiş bir site ile web siteniz neredeyse anında yükleniyormuş gibi görünür. Onsuz, sayfanın yüklenmesi daha uzun sürer, bu da kullanıcı deneyimine ve nihayetinde arama motoru sıralamalarına zarar verebilir.

SRT, İlk Bayt Süresi (TTFB) olarak bilinen bir birimde ölçülür. TTFB, HTTP istemcisinin isteğini yapması ile ilk veri baytını alması arasındaki süreyi ölçer. Milisaniye cinsinden ölçülür.

İyi, kötü ve kabul edilebilir bir TTFB'yi oluşturan şey değişir. İşte bazı genel kurallar:

• 100ms'den daha hızlı mükemmel.
• 100-200ms iyidir. Google PageSpeed ​​Insights, SRT'nizi 200 ms'nin altında tutmanızı önerir.
• 200ms–1 saniye kabul edilebilir, ancak iyileştirme için yer var.
• 1 saniyenin üzerindeki herhangi bir şey bir problemdir.

Zamanda bu kadar küçük bir değişiklik büyük bir fark yaratabilir mi? Bir saniyelik gecikme bile bir e-ticaret sitesine yılda 25.000–125.000 ABD Doları arasında bir maliyete mal olabilir… veya daha fazla!

Sunucu yanıt süresi SEO'yu nasıl etkiler?

Google, SRT'yi yaklaşık on yıldır bir sıralama faktörü olarak kullandı. Daha yakın zamanlarda, Google Arama Konsolu, kullanıcı deneyimine odaklanan bir dizi web sitesi performans metriğini izleyen bir Önemli Web Verileri bölümünü kullanıma sundu.

Forrester Research tarafından yapılan bir araştırmaya göre, web kullanıcılarının yarısından fazlası bir sitenin iki saniye veya daha kısa sürede yüklenmesini bekliyor. Yüklemesi üç saniyeden uzun sürerse, kullanıcıların %40'ı vazgeçip ayrılacaktır.

Yüklenmesi daha uzun süren siteler genellikle daha yüksek hemen çıkma oranına ve daha kısa ortalama ziyaret süresine sahiptir. Bir Pingdom araştırmasının bulduğu gibi, "yüklenmesi üç saniyeden az süren web siteleri için hemen çıkma oranları %10'un altında seyrederken, bu sayı dört saniyelik yükleme süresi için %24'e ve beş saniyelik yükleme süresi için %38'e yükseldi. ”

Yavaş bir site, kötü bir kullanıcı deneyimi anlamına gelir ve arama motorları buna göre yanıt verir.

Sunucu yanıt sürenizi azaltmak üç adıma iner.

1. Sunucu yanıt sürenizi ölçün.
2. İyileştirilmesi gereken alanları belirleyin.
3. Bu alanları ele almak için ekibinizle birlikte çalışın.

SRT'nizi nasıl kontrol edebilirsiniz?

Kullanabileceğiniz birkaç araç var.

GTMetrix

GTMetrix'in hem ücretsiz hem de ücretli sürümleri vardır. SRT'nizi analiz etmenize, sayfalarınızı izlemenize ve sitenizin hızını bir mobil cihazda test etmenize olanak tanır. URL'nizi girmeniz yeterlidir; sayfa yükleme süresi için SRT verilerini de içeren genel bir puan görürsünüz.

Ardından, her öğeyi yükledikleri sırayla görmek için şelale grafiğini kullanabilirsiniz. Bu, tam olarak hangi isteklerin sitenizi yavaşlattığını göstererek sorunlu alanları belirlemenize ve hata ayıklamanıza olanak tanır.

Elbette, sunucu yanıt süresi, sayfa hızına katkıda bulunan birçok faktörün yalnızca bir parçasıdır.

Şelale Tablosundan, imleci tek bir öğenin üzerine getirerek her istek hakkında daha ayrıntılı bilgi alabilirsiniz. Orada, yükleme süresinin ne kadarının sunucunuzda beklemekten kaynaklandığını göreceksiniz:

Ücretsiz bir hesap oluşturursanız, Zamanlamalar sekmesini kullanarak çok önemli TTFB dahil diğer ilgili metrikleri görüntüleyebilirsiniz:

Google PageSpeed ​​Insights (PSI)

Bu ücretsiz araca URL'nizi girin, genel bir puan ve bazı yararlı metrikler göreceksiniz. İşte nasıl göründüğüne bir örnek:

PSI, sitenizin hem mobil hem de masaüstü sürümleri hakkında fikir verir ve neleri iyileştirebileceğiniz konusunda size hayati bilgiler verir. Sayfanın performansını tahmin etmek için Chrome Kullanıcı Deneyimi Raporuna dayalı gerçek dünya "alan" verileri ve Lighthouse'dan alınan laboratuvar verilerinin bir karışımını kullanır.

Google Page Insights'ın, özellikle SRT ile ilgili ölçtüğü metrikler aşağıda verilmiştir.

• First Contentful Paint (FCP): Bu metrik, sayfanın yüklenmeye başladığı andan sayfa içeriğinin herhangi bir bölümünün ekranda görüntülendiği ana kadar geçen süreyi ölçer.
• Kümülatif Mizanpaj Kayması : CLS, sayfanın tüm ömrü boyunca meydana gelen her beklenmedik mizanpaj kayması için tüm ayrı mizanpaj kaydırma puanlarının toplamını ölçer.
• Etkileşim Süresi (TTI): Bu, bir sayfanın tamamen etkileşimli hale gelmesinin ne kadar sürdüğünü ölçer. Google'a göre, bir sayfa yararlı içerik görüntülediğinde, olay işleyicileri çoğu görünür sayfa öğesi için kaydedildiğinde ve sayfa kullanıcı etkileşimlerine 50 milisaniye ile yanıt verdiğinde tamamen etkileşimlidir.
• Toplam Engelleme Süresi : Toplam Engelleme Süresi (TBT) metriği, giriş yanıt vermesini önlemek için ana iş parçacığının yeterince uzun süre engellendiği FCP ve TTI arasındaki toplam süreyi ölçer.

Yüksek bir puan için PSI, 200 ms'nin altında bir sunucu yanıt süresi bekler. SRT'niz bundan daha yavaşsa, "Fırsatlar" bölümünde bir bildirim alırsınız:

Sunucu yanıt sürenizi nasıl azaltabilirsiniz?

Sonuç olarak, sunucunuzun yanıtını yavaşlatabilecek düzinelerce olası faktör vardır: yavaş uygulama mantığı, yavaş veritabanı sorguları, yavaş yönlendirme, çerçeveler, kitaplıklar, kaynak CPU yetersizliği veya bellek yetersizliği.

Hepsini ele alamayabilirsiniz, ancak daha teknik alanları bulmak ve düzeltmek için geliştirme ekibinizle birlikte çalışabilirsiniz:

• Yavaş uygulama mantığı : Sitenizde hangi bağımlılıkların kullanıldığını ve bu bağımlılıkların her birinin yüklenmesinin ne kadar sürdüğünü belirlemeye yardımcı olması için bir kod profili oluşturma aracı kullanın.
• Yavaş veritabanı sorguları : Bunlar, veritabanı sorgularınız verimli bir şekilde tetiklenmediğinde oluşur. Daha da kötüsü, "kaputun altını" kontrol etmediğiniz sürece kötü performans gösterdiklerini bile bilmiyor olabilirsiniz. Yavaş veritabanı sorguları daha fazla çalışma gerektirir ve daha fazla CPU kaynağı kullanır.
• Yavaş yönlendirme : Genel olarak konuşursak, en çok ziyaret ettiğiniz sayfaları ve içeriği, bu konumları yüksek öncelikli hale getirmek için yönlendirme kuyruğunun en üstüne yerleştirmek istersiniz. Ayrıca, işler yavaş ilerliyorsa, herhangi bir belirli konuma daha fazla rota ekleyebilirsiniz.
• Kaynak CPU açlığı : Siteniz çok fazla eklenti veya komut dosyası çalıştırıyorsa, kaynak CPU açlığına yol açabilir. Sık kullanılmayan kaynak yoğun eklentileri kaldırmak ve gereksiz komut dosyalarını kaldırmak için ekibinizle birlikte çalışın.

Geliştirme ekibinizle bire bir görüşmeden sunucu yanıtınızı iyileştirmenize yardımcı olabilecek başka somut adımlar da vardır.

Hızlı, özel bir ana bilgisayar bulun

Mevcut SRT'niz daha yavaşsa, daha hızlı bir ana bilgisayar aramayı düşünün. Düşünülmesi gereken birkaç şey var.

Bütçeniz varsa, özel barındırmayı seçin. Bu, sunucuyu başka bir siteyle paylaşmadığınız anlamına gelir. Paylaşımlı barındırma harika bir başlangıç ​​olabilirken, bazı paylaşımlı barındırma sağlayıcıları sunucularını aşırı yükleyerek karlarını en üst düzeye çıkarır, ancak web siteniz için felakete yol açar.

Kararınızı vermeden önce yorumları okuyun ve tavsiye isteyin. Bir öneri alırsanız, bu siteler için SRT'yi kontrol etmek için GTMetrix veya PSI kullanın.

Satın almadan önce bir sağlayıcının sunucu hızlarını da kontrol edebilirsiniz. Bunu yapmanın birkaç yolu var:

Bir hız kontrol aracı kullanın. Pickuphost'un ücretsiz hız kontrol aracını beğendim:

Bir karşılaştırma sitesini kontrol edin. Birçok popüler web barındırıcısının ortalama yanıt süreleriyle ilgili Invital raporlar:

56 farklı ölçümde 4 barındırma sağlayıcısını karşılaştırmak için basit karşılaştırma aracını da kullanabilirsiniz:

Bitcatcha, dünyanın çeşitli yerlerindeki barındırma hızlarını karşılaştırmanıza olanak tanıyan başka bir araçtır, böylece bulunduğunuz yere en uygun olanı seçebilirsiniz.

Hedef kitlenize coğrafi olarak yakın sunucuları olan bir sunucu seçmelisiniz. Bunu bir CDN ile sağlamanın kolay bir yolu.

Bir CDN (İçerik Dağıtım Ağı) kullanın

İçerik Dağıtım Ağı (CDN), çevrimiçi içeriği daha hızlı sunmak için birlikte çalışan, coğrafi olarak dağıtılmış bir sunucu grubudur. İşletmenizin odağında aşırı yerel olmadıkça, dünyanın her yerinden bir anda veya başka bir zamanda içeriğinize erişmek isteyen insanlara sahip olmanız olasıdır.

Bir CDN kullanarak, site ziyaretçilerinizin nerede olurlarsa olsunlar en iyi kullanıcı deneyimini yaşamalarını sağlarsınız. Tüm dünyadaki internet trafiğinin yarısından fazlası bir CDN aracılığıyla sunulmaktadır.

Bir CDN, web sitenizin önbelleğe alınmış bir sürümünü dünyanın çeşitli yerlerinde depolar. Her alanın kendi sunucusu vardır ve kullanıcının bulunduğu yere en yakın sunucu istenen içeriği teslim edecektir. İşte nasıl çalıştığına dair bir görsel:

Web siteniz Amerika Birleşik Devletleri'nde barındırılıyorsa ancak Avustralya'daki bir kullanıcı siteye erişmek istiyorsa, SRT 0,2 ila 0,4 saniye daha yavaş olabilir. Bir CDN bu sorunu hafifletir ve coğrafi konumdan bağımsız olarak sürekli olarak hızlı bir SRT sağlar.

SRT'de yarım saniye çok fazla görünmese de, ziyaretçileriniz için algılanan yükleme sürelerini etkiler.

Kurulum için bir CDN seçmeniz ve sitenizi kaydetmeniz gerekir. Aralarından seçim yapabileceğiniz yüzlerce CDN sağlayıcısı var. CDN'nizi seçerken, beklenen trafik hacmi, sunduğunuz ana medya türleri ve bütçeniz gibi faktörleri göz önünde bulundurun.

Bir CDN sağlayıcısına kaydolduktan sonra, sizin veya web geliştiricinizin bunu web sitenizde etkinleştirmesi gerekir. Barındırma sağlayıcınıza ve içerik yönetim sisteminize (CMS) bağlı olarak, C-panelinizden veya bir eklenti kullanarak etkinleştireceksiniz.

Alanınızı sitenizi barındırmak için kullandığınız sağlayıcıdan farklı bir sağlayıcıdan satın aldıysanız, orada da bir güncelleme yapmanız gerekir. Alan adınızı CDN'nizin sunucularına yönlendirmek için sizin veya alan adı kayıt kuruluşunuzun DNS ad sunucusu kayıtlarınızı değiştirmeniz gerekecektir.

SRT'nizi optimize ettikten sonra, ancak geliştirici ekibinizin dikkatini çekmeye devam ederken, büyük etkisi olabilecek birkaç sayfa hızı sorununu daha çözmek isteyebilirsiniz.

Site hızınızı artırmanın daha fazla yolu (SRT'nin ötesinde)

Komut dosyalarınızı azaltın ve optimize edin

Sitenizin yüklenme süresini artırmanın en etkili yollarından biri, sitenizin çalıştırdığı komut dosyalarını denetlemektir. Hâlâ o izleme komut dosyasını mı kullanıyorsunuz? Bu verilerle bir şey yapan var mı?

Her küçük atık birikebilir. PSI, sitenizin hangi komut dosyalarını yüklediğini (ve hangilerinin yüklenmesinin en çok zaman aldığını) size gösterecektir. Genellikle komut dosyalarını kaldırmak, Google Etiket Yöneticisi'nde bir etiketi devre dışı bırakmak kadar basittir.

WordPress kullanıyorsanız, Komut Dosyalarını ve Stilleri Optimize Et veya Varlık Temizleme gibi gereksiz komut dosyalarını kaldırmaya yardımcı olacak birkaç eklenti vardır.

Görüntüleri ölçeklendirin ve optimize edin

Görüntüleri optimize etmenin en basit yollarından biri, görüntülerinizin doğru dosya biçiminde olmasını sağlamaktır. Genel olarak, bir PNG, bir JPEG dosyasına göre daha fazla yer kaplar. Basitlik adına, logolar ve çizelgeler gibi basit grafikler için PNG'yi ve diğer her şey için JPEG biçimini kullanmanızı öneririm.

Google, JPEG 2000 adlı bir biçim önermeye başladı. Ancak, henüz pek çok sistem veya tarayıcıyla (Chrome dışında) uyumlu olmadığı için bunu genellikle kullanmıyorum.

JPEG'den biraz daha küçük bir dosya boyutu sunan WEB.P adlı bir biçim de vardır. Ancak, fark ihmal edilebilir düzeydedir. Önbelleğe almayı etkinleştirdiğinizde (bir dakika içinde daha fazlası), gözle görülür bir fark yoktur.

Şu anda, çoğu durumda %60 sıkıştırmada varsayılan JPEG biçimini kullanıyorum. Bir JPEG'i %95 kaliteden %80'e, hatta %75'e düşürmek, görüntünün görünümünde çok az fark edilebilir fark yaratabilir. Görüntü kalitesi ve dosya boyutu arasında doğru dengeyi bulmak için deney yapın.

Birçok araç (bazıları ücretsiz), resimlerinizi yüklemeden önce optimize etmenize de yardımcı olabilir. Jpeg.io ve Compressor iki iyi seçenektir. WordPress, Smush veya Kraken.io eklentileri, resimlerinizi yüklerken optimize eder. Diğer CMS platformlarında da benzer seçenekler mevcuttur.

Önbelleğe almayı kullan

Önbelleğe alma, kalite veya içerik açısından hiçbir şeyden ödün vermeden sitenizin hızını artırmanın en iyi yollarından biridir.

Bir kullanıcı sitenizi ilk ziyaret ettiğinde, sunucunun JavaScript dosyalarını, resimleri, HTML belgesini ve daha fazlasını indirmesi gerekir. Önbelleğe alma, kullanıcının bir sonraki ziyaretinde içeriğin daha hızlı alınabilmesi için bu yönlerden bazılarını hatırlayan geçici depolamadır.

Önbelleğe almayı etkinleştirmek için web sitenizin .htaccess dosyasına küçük bir kod parçası eklemeniz gerekir. Bunu genellikle barındırma kullanıcı alanınızdaki dosya yöneticisi aracılığıyla yaparsınız. Bu kod, kullanıcılarınızın tarayıcılarına neyi önbelleğe alacaklarını ve ne kadar süreyle geri çağıracaklarını söyler.

İşte GTMetrix'ten bir kod örneği:

Kodu, sitenizin farklı yönlerini farklı sürelerde önbelleğe alacak şekilde değiştirebilirsiniz. Daha sık güncellenen dosya türleri için daha kısa bir önbelleğe alma süresi ayarlayın.

Oldukça statik olanlar için önbelleğe alma süresi daha uzun olabilir. Sık sık değişen veya güncellenen dosyalar için çok uzun olan önbelleğe alma süreleri, geri gelen kullanıcıların sitenizin önbelleğe alınmış daha eski bir sürümünü görmelerine neden olabilir.

(Dikkatli olun: .htaccess dosyasında bir şeyler ters giderse, tüm sitenizi bozabilir.)

Bazı CMS platformlarında, herhangi bir kodlama olmadan önbelleğe almayı etkinleştirmek için bir eklenti de kullanabilirsiniz. En popüler ve yüksek puan alanlardan bazıları, WordPress için W3 Total Cache ve WP Rocket ve Joomla için SpeedCache'dir.

CMS'nizi, eklentilerinizi ve temalarınızı güncel tutun

CMS'nizi, eklentilerinizi veya web sitesi temanızı güncellemenizi hatırlatan bu bildirimleri ne sıklıkla görüyorsunuz? Daha sonra öğreneceğinizi ve sonra her şeyi unutacağınızı düşünerek onları kapatıyor musunuz? Bunu yapmayı hemen bırak!

CMS'nizin, eklentilerinizin ve web sitesi temalarınızın eski sürümleri sayfa hızını önemli ölçüde azaltabilir. Bu araçların ve platformların yaratıcıları, güncellemeleri bir nedenden dolayı oluşturur; genellikle bunun nedeni, verimliliği ve hızı artırmaktır.

(Başka bir sorun daha var: Güncel olmayan CMS platformları, eklentiler ve temalar web sitenizi güvenlik ihlallerine karşı savunmasız bırakabilir. Malcare, güncel olmayan temaların ve eklentilerin WordPress sitelerine yönelik saldırıların en yaygın nedenlerinden biri olduğunu bildirdi.)

Sitenizdeki komut dosyalarında olduğu gibi, kayıtlı eklentilerinizi ve temalarınızı en son ne zaman temizlediniz? Muhtemelen, kullanmadığınız birkaç tane indirmişsinizdir. İndirdiğiniz ve yüklediğiniz her şeyi düzenli olarak hızlı bir şekilde denetleyin.

Çözüm

Sunucu yanıt sürenizi azaltmak, site ziyaretçilerinize daha iyi bir deneyim sunacak, hemen çıkma oranınızı azaltacak ve sonuç olarak arama sıralamalarınızı iyileştirecektir.

• Nereden çalıştığınıza dair bir temele sahip olmak için önce SRT'nizi kontrol edin.
• Doğru barındırma sağlayıcısını ve sunucuyu seçin.
• Kullanıcılara coğrafi olarak daha yakın sunuculardan içerik sunmak için bir CDN kullanın.
• Doğru dosya türünü seçerek, görüntü kalitesini biraz azaltarak ve dosya boyutlarını küçültmek için bir eklenti kullanarak görüntülerinizi optimize edin.
• Geri dönen ziyaretçilere daha iyi bir deneyim sağlamak için tarayıcı önbelleğini kullanın.
• CMS, eklentiler ve web sitesi temalarınızın güncel olduğundan emin olun.

SRT ve SEO, saniyelerin ve milisaniyelerin gerçekten önemli olduğu alanlardır. Kestiğiniz her saniye, ziyaretçileri sitenizde daha uzun süre tutacak, tekrar gelmelerini sağlayacak ve sitenizin sonuç sayfalarında gıptayla bakılan en üst sıralara çıkmasına yardımcı olacaktır.