Bir web sitesine girmek için ne yapıyoruz?
Tarayıcıyı açıyoruz, adres çubuğuna bir adres yazıyoruz ve Enter tuşuna basıyoruz. Çoğu zaman birkaç saniye bile geçmeden karşımıza bir sayfa çıkıyor. Başlıkları okuyor, görsellere bakıyor, bağlantılara tıklıyor ve internetin günlük hayatımızın sıradan bir parçası olduğunu düşünerek yolumuza devam ediyoruz.
Oysa bu basit hareketin arkasında oldukça karmaşık bir süreç var.
Tarayıcı önce hangi bilgisayarla iletişim kuracağını bulmak zorunda. Ardından güvenli bir bağlantı kuruluyor. İstek doğru sunucuya ulaştırılıyor. Sunucu sayfayı hazırlıyor veya önceden hazırlanmış bir kopyasını gönderiyor. Tarayıcı gelen HTML, CSS, JavaScript ve görselleri işleyerek ekranda gördüğümüz sayfayı oluşturuyor.
Bütün bunlar biz herhangi bir şey fark etmeden gerçekleşiyor.
Dahası, aynı web sitesi bir bilgisayarda anında açılırken başka bir telefonda neden bekletiyor? İnternet bağlantısı hızlı olduğu hâlde bazı sayfalar neden ağır çalışıyor? Bir sayfanın görüntüsü gelmişken neden düğmelerine basamıyoruz? Tarayıcı bazen neden sitenin eski hâlini gösteriyor?
Bu soruların cevabı da aynı görünmeyen yolculuğun içinde saklı.
İnternetin çalışma mantığını anlamak için yazılımcı olmak gerekmiyor. Birkaç temel kavramın nasıl birbirine bağlandığını öğrendiğimizde hem kullandığımız web sitelerine hem de internet bağlantısında yaşadığımız sorunlara çok daha farklı bakmaya başlıyoruz.
PratikTekno olarak bu kez bir sorunu çözmekten önce, her gün kullandığımız webin perde arkasını anlamaya çalışacağız.
Adres çubuğuna yazdığımız şey aslında nedir?
Bir web adresi yalnızca sitenin ismi değildir. Tarayıcıya hangi kaynağı, hangi yöntemle ve nereden istemesi gerektiğini anlatan bir bilgidir.
Örneğin https://ornek.com/makale/ biçiminde bir adres düşünelim.
Buradaki https, tarayıcının sunucuyla güvenli iletişim kurmak için kullanacağı protokolü belirtir. ornek.com alan adıdır. /makale/ ise aynı alan adı altında istenen kaynağın yolunu gösterir.
Tarayıcı, bu bilgileri kullanarak isteğin nereye gönderileceğini belirler.
Fakat bir sorun var.
Biz web sitelerini isimleriyle tanıyoruz. İnternet üzerindeki iletişim ise büyük ölçüde IP adresleri üzerinden yönlendiriliyor.
Bu yüzden tarayıcının öncelikle alan adının hangi IP adresine karşılık geldiğini öğrenmesi gerekir.
İşte burada DNS devreye girer.
DNS: İnternetin görünmeyen adres sistemi
DNS, Domain Name System ifadesinin kısaltmasıdır.
En basit anlatımla alan adlarının IP adresleriyle ilişkilendirilmesini sağlayan sistemdir. Ancak onu yalnızca internetin telefon rehberi olarak düşünmek, yapabildiklerinin tamamını anlatmaz.
DNS kayıtları bir alan adının hangi sunucuya yönlendirileceğini, e-postaların nereye teslim edileceğini veya belirli hizmetlerin nasıl bulunacağını belirlemeye de yardımcı olabilir.
Bir web sitesine girdiğimizde tarayıcı ihtiyaç duyduğu adres bilgisinin daha önce öğrenilip öğrenilmediğini kontrol edebilir. İşletim sistemi ve DNS çözümleyicileri de kendi önbelleklerini kullanabilir.
Bilgi zaten eldeyse her ziyaret için baştan uzun bir DNS sorgulama sürecine gerek kalmayabilir.
Ancak bilgi yoksa veya geçerliliğini yitirmişse DNS çözümlemesi yapılır.
Burada önemli bir ayrıntı bulunuyor: Aynı alan adı farklı zamanlarda veya farklı ağlardan sorgulandığında aynı IP adresini vermek zorunda değildir. Büyük web hizmetleri trafik dağıtımı, erişilebilirlik ve coğrafi yakınlık gibi nedenlerle farklı sunuculara yönlendirme yapabilir.
Yani bir web sitesinin tek bir fiziksel bilgisayarda durduğunu varsaymak her zaman doğru değildir.
Tarayıcının ilk başarısı, bir web sitesini göstermek değil; o siteye ulaşabileceği yolu bulmaktır.
HTTPS bağlantısı neden bu kadar önemli?
Tarayıcı nereye bağlanacağını öğrendikten sonra sıra iletişimin kurulmasına gelir.
Modern webde bağlantı çoğunlukla HTTPS üzerinden yapılır. HTTPS, HTTP iletişiminin TLS ile korunmuş biçimidir.
Bu koruma, tarayıcı ile bağlantı kurulan karşı taraf arasında aktarılan verilerin şifrelenmesini ve iletişimin bütünlüğünün korunmasını sağlar. Ayrıca sertifika doğrulaması, beklenen alan adıyla iletişim kurulup kurulmadığının değerlendirilmesine yardımcı olur.
Fakat burada sık karşılaşılan bir yanlış anlamayı düzeltelim.
Tarayıcıda HTTPS kullanılması, ziyaret edilen sitenin mutlaka dürüst, güvenilir veya zararsız olduğu anlamına gelmez.
Dolandırıcılık amacıyla hazırlanmış bir web sitesi de geçerli HTTPS sertifikası kullanabilir.
HTTPS bize iletişim kanalının güvenliği hakkında bilgi verir; sitenin içeriğinin doğruluğunu veya işlettiği hizmetin güvenilirliğini tek başına kanıtlamaz.
Bir diğer ayrıntı da bağlantının nasıl kurulduğudur.
Webin her zaman aynı bağlantı teknolojisini kullandığını düşünmemek gerekiyor. HTTP/1.1 ve HTTP/2 bağlantıları yaygın olarak TCP üzerinde çalışırken HTTP/3, QUIC adı verilen ve UDP üzerinde çalışan farklı bir taşıma sistemi kullanır.
Bu teknik farkların önemli bir amacı, veri iletimini daha verimli ve gecikmelere karşı daha dayanıklı hâle getirmektir.
Kullanıcının bütün bu protokolleri ezberlemesine gerek yok.
Ancak şu ayrımı bilmek yararlıdır:
İnternet bağlantısının var olması, belirli bir web sitesiyle hızlı ve güvenli iletişimin hemen kurulacağı anlamına gelmez.
Bağlantı hazırlanırken yaşanan gecikmeler, sayfanın henüz tek satır HTML göndermediği bir aşamada bile beklemeye neden olabilir.
Tarayıcı ilk isteği gönderdiğinde sunucuda ne oluyor?
DNS çözümlemesi ve gerekli bağlantı işlemleri tamamlandığında tarayıcı web sayfasını istemeye hazırdır.
Çoğu sıradan sayfa ziyaretinde bir HTTP GET isteği gönderilir.
Bu isteğin anlamı kabaca şudur:
“Bu adresteki kaynağı bana gönder.”
İsteği alan sistem gelen adresi, yöntemi, başlık bilgilerini ve varsa gerekli diğer bilgileri değerlendirir.
Ama isteği karşılayan ilk sistem her zaman web sitesinin asıl sunucusu olmayabilir.
Arada CDN, önbellek sunucusu, ters vekil sunucu veya yük dengeleyici bulunabilir.
Dolayısıyla internet üzerinde ziyaret ettiğimiz her site için doğrudan tek bir sunucuya ulaştığımızı düşünmek yanıltıcıdır.
İstek bazen ziyaretçiye yakın bir CDN noktasında karşılanır. Bazen başka bir sunucuya yönlendirilir. Bazen de içeriğin üretilmesi için uygulamanın çalışması gerekir.
Bir sunucunun isteğe yanıt vermesi de yalnızca dosya göndermekten ibaret değildir.
İstenen sayfa kullanıcıya özel olabilir. Oturum bilgisi kontrol edilmesi, veri tabanından kayıt getirilmesi, erişim yetkisinin doğrulanması veya farklı bileşenlerin bir araya getirilmesi gerekebilir.
İşte aynı web sitesinin farklı sayfalarının farklı hızlarda açılmasının nedenlerinden biri budur.
Ana sayfa birkaç saniyede hazır olurken oldukça karmaşık bir arama sayfası daha uzun sürebilir.
İkisi aynı sunucuda bulunabilir.
Ancak sunucunun ikisi için yaptığı iş aynı değildir.
İlk yanıtın gecikmesi bize ne anlatır?
Web performansında kullanılan önemli kavramlardan biri TTFB’dir: Time to First Byte.
Bu ölçüm, gezinme isteğinin başlamasından yanıtın ilk baytının gelmesine kadar geçen süreyi ifade eder. Yönlendirmeler, DNS çözümlemesi ve bağlantı kurulması gibi aşamalar da bu süreye katkıda bulunabilir.
TTFB yüksek olduğunda kullanıcı henüz sayfanın içeriğini almaya başlamadan bekliyor olabilir.
Ancak TTFB değerini yalnızca sunucunun işlemci gücüne bağlamak doğru değildir.
Yavaş DNS çözümlemesi, uzun yönlendirme zincirleri, bağlantı gecikmeleri veya sunucu tarafındaki işlemler birlikte etkili olabilir.
Google’ın TTFB açıklamasında da vurgulandığı gibi, ilk yanıtın gelme süresi önemli olsa da tek başına web sitesinin bütün kullanıcı deneyimini açıklamaz.
Çünkü sunucu hızlı yanıt verse bile tarayıcının önünde hâlâ yapılacak işler vardır.
WordPress bir sayfayı ziyaretçiye nasıl hazırlıyor?
Şimdi yolculuğumuzun WordPress bölümüne gelelim.
Bir ziyaretçinin WordPress sitesindeki makaleyi açtığını düşünelim.
WordPress, sunucu tarafında çalışan PHP tabanlı bir içerik yönetim sistemidir. İçerikleri, ayarları ve birçok site bilgisini veri tabanıyla birlikte yönetir.
Uygun şekilde önbelleğe alınmamış bir istekte WordPress’in çalışması, istenen içeriğin bulunması ve kullanılan tema aracılığıyla sayfa çıktısının hazırlanması gerekebilir.
Temanın üst alanı, menü, yazı başlığı, makale içeriği, yan sütun ve alt bilgi gibi bölümler bu süreçte bir araya getirilebilir.
Eklentiler de çeşitli aşamalarda devreye girebilir.
Örneğin iletişim formu, arama özelliği veya özel bir içerik alanı eklenti aracılığıyla oluşturuluyor olabilir.
Bununla birlikte WordPress’in her ziyaret sırasında mutlaka aynı veri tabanı sorgularını tekrar yaptığını düşünmek de doğru değildir.
Önbellek mekanizmaları sayesinde bazı işlemlerin yeniden yapılması engellenebilir.
Hatta uygun yapılandırılmış bir sayfa önbelleği varsa ziyaretçiye önceden hazırlanmış HTML yanıtı sunulabilir. Böylece WordPress’in bütün sayfayı her defasında sıfırdan üretmesi gerekmez.
Bu fark, bir web sitesinin performansını ciddi biçimde etkileyebilir.
Eklenti sayısı mı, eklentinin yaptığı iş mi önemli?
WordPress performansıyla ilgili çok yaygın bir iddia vardır:
“Çok eklenti kurarsan site yavaşlar.”
Bu ifadede gerçeklik payı olsa da yalnızca eklenti sayısına bakmak doğru bir ölçüm değildir.
Bir eklenti çok az kaynak kullanırken başka bir eklenti her sayfada karmaşık veri tabanı sorguları, uzak sunucu bağlantıları veya büyük JavaScript dosyaları çalıştırabilir.
Dolayısıyla az sayıda ama verimsiz eklenti, daha fazla sayıda ve iyi hazırlanmış eklentiden kötü sonuç verebilir.
Üstelik eklentinin performansı yalnızca sunucu tarafında ölçülmez. Sayfaya eklediği CSS, JavaScript veya dış kaynaklar tarayıcı tarafındaki işi de artırabilir.
Bu nedenle WordPress sitesinde sorun çıktığında yalnızca eklenti sayısına bakmak yerine hangi eklentinin hangi işleme etki ettiğini anlamak daha doğru bir yaklaşımdır.
Eklenti güncellemesi sonrasında bir site bozulduğunda izlenecek güvenli yolu, WordPress Eklentisi Siteyi Bozduysa Nasıl Geri Dönülür? yazımızda ayrıca ele alıyoruz.
Buradaki temel çıkarım ise şu:
WordPress ziyaretçiye bir sayfa göndermeden önce çeşitli işler yapabilir; fakat iyi bir önbellek ve doğru yapılandırma, bu işlerin her ziyaret için tekrarlanmasını azaltabilir.
Not: Görsel süreci anlaşılır kılmak için basitleştirilmiş bir akış sunar. Gerçekte CDN ve önbellek, bazı istekleri ana web sunucusuna ulaşmadan karşılayabilir; her ziyaret aynı sırayı izlemek zorunda değildir.
Gelen HTML nasıl gördüğümüz web sayfasına dönüşüyor?
Sunucu isteğe yanıt verdi.
Tarayıcı HTML içeriğini almaya başladı.
Peki neden karşımıza doğrudan HTML kodları çıkmıyor da renkli düğmeleri, görselleri, menüleri ve sütunları olan bir web sayfası geliyor?
Çünkü tarayıcı gönderilen kodu yorumlayarak görünür bir arayüz oluşturuyor.
Bu süreç webin en ilginç aşamalarından biridir.
HTML sayfanın içeriğini ve yapısını tanımlar. CSS görsel sunumu belirler. JavaScript ise gerektiğinde davranışları ve etkileşimleri yönetir.
Bir makalenin başlığı HTML içinde tanımlanabilir.
O başlığın yazı tipi, rengi ve boyutu CSS ile belirlenebilir.
Kullanıcının menü düğmesine basınca mobil menünün açılması ise JavaScript aracılığıyla gerçekleştirilebilir.
Ancak tarayıcı bu üç teknolojiyi birbirinden tamamen bağımsız kullanmaz.
HTML işlenirken belgeyi temsil eden DOM yapısı oluşturulur. CSS kuralları da tarayıcı tarafından değerlendirilir. Görüntülenecek öğeler için stiller hesaplanır, yerleşim belirlenir ve ekrana çizim yapılır.
Bu adımlar sırasında JavaScript de belge üzerinde değişiklikler yapabilir.
Örneğin JavaScript bir içeriği sonradan ekleyebilir, görünürlüğünü değiştirebilir veya düğmeye basıldığında yeni bilgiler gösterebilir.
Tarayıcı bütün bu işleri çok kısa sürelerde gerçekleştirebilir.
Fakat sayfa gereğinden fazla karmaşık hâle gelirse işlemci üzerindeki yük büyür.
Özellikle düşük güçlü telefonlarda veya çok sayıda işlem yürüten tarayıcılarda bu durum daha belirgin hissedilebilir.
Burada önemli bir nokta var:
Web sitesinin sunucudan hızlı gelmesi, tarayıcıda hızlı çizileceğini garanti etmez.
Bu yüzden bir site güçlü masaüstü bilgisayarda sorunsuz görünürken daha eski bir telefonda ağır hissedilebilir.
Aynı veri geliyor olabilir.
Ama onu ekrana dönüştüren cihazların kapasitesi farklıdır.
Tarayıcıların bu süreci nasıl yürüttüğüne ilişkin teknik açıklamalar MDN’nin kritik oluşturma yolu belgesinde bulunuyor.
Sayfa göründüğü hâlde neden henüz hazır olmayabilir?
Bir web sitesini açtığımızda bazen ilginç bir durum yaşarız.
Ekranda başlık görünür. Arka plan rengi gelmiştir. Hatta bazı görseller de açılmıştır.
Ancak bir düğmeye bastığımızda hiçbir şey olmaz.
Bir süre sonra aynı düğme çalışmaya başlar.
Kullanıcı açısından site açılmıştır ama tam olarak hazır değildir.
Bunun nedeni, web sayfasının görüntülenmesiyle bütün etkileşimlerinin kullanılabilir hâle gelmesinin farklı süreçler olabilmesidir.
Tarayıcı HTML’in ilk bölümlerini aldıktan sonra içerik göstermeye başlayabilir.
Bu sırada başka görseller indiriliyor, yazı tipleri hazırlanıyor veya JavaScript işlemleri devam ediyor olabilir.
Örneğin sayfadaki büyük bir görselin yüklenmesi biraz zaman alabilir. Kullanıcı metni okuyabilirken görsel henüz görünmüyor olabilir.
Başka bir sayfada büyük bir JavaScript işlemi ana iş parçacığını meşgul edebilir. Düğme görünür durumdadır fakat kullanıcı etkileşimi gecikir.
Bu yüzden yalnızca sayfanın ilk görüntüsüne bakarak “site hızlı” demek yeterli değildir.
Kullanıcı açısından üç soru daha önemlidir:
Sayfanın asıl içeriğini ne zaman görebiliyorum?
Bir düğmeye bastığımda ne kadar hızlı tepki alıyorum?
İçerik yüklenirken sayfa düzeni yerinden oynuyor mu?
Modern web performansının temel ölçümleri de büyük ölçüde bu sorularla ilgilenir.
İnternet hızımız yüksekken bir web sitesi neden yavaş olabilir?
Bir kullanıcı internet hız testi yapar.
Sonuç oldukça iyidir.
Ardından bir web sitesine girer ve sayfanın açılmasını bekler.
Doğal olarak şöyle düşünür:
“İnternetim hızlıysa bu site neden açılmıyor?”
Buradaki karışıklığın nedeni bağlantı hızıyla gecikmenin aynı şey olmamasıdır.
İnternet bağlantısının indirme hızı, belirli koşullarda ne kadar veri aktarılabileceği hakkında bilgi verir.
Fakat bir web sitesinin açılması yalnızca büyük miktarda veri indirmekten oluşmaz.
DNS sorgulaması, bağlantının kurulması, sunucunun yanıt vermesi ve tarayıcının işlemleri tamamlaması da zaman gerektirir.
Bunu bir yolculuğa benzetebiliriz.
Çok geniş bir otoyolunuz olabilir. Ancak yolun başındaki geçiş noktasında bekliyorsanız otoyolun kapasitesi tek başına sizi daha erken hedefe ulaştırmaz.
Aynı şekilde yüksek hızlı internet bağlantısı, uzak veya yavaş yanıt veren bir sunucunun bütün gecikmelerini ortadan kaldırmaz.
Bazı web siteleri çok sayıda farklı sunucudan kaynak indirir.
Bir sayfanın yazı tipleri başka sunucuda, analiz hizmetleri başka bir yerde, videolar farklı bir içerik sağlayıcıda olabilir.
Bunların her biri için ayrı bağlantılar veya istekler gerekebilir.
Tarayıcı birçok isteği paralel yürütebilse de bağlantı sayısı, kaynakların önceliği ve bazı dosyaların birbirine bağımlılığı performansı etkileyebilir.
İşte bu yüzden 100 Mbps bağlantıyla çok iyi çalışan bir site, daha hızlı bağlantı kullanan başka bir cihazda mutlaka daha hızlı açılmayabilir.
CDN ve önbellek interneti nasıl hızlandırıyor?
Bir web sitesinin asıl sunucusunun başka bir ülkede olduğunu düşünelim.
Türkiye’deki her ziyaretçinin bütün görselleri ve diğer dosyaları doğrudan o sunucudan alması gerekirse coğrafi uzaklık ve ağ koşulları gecikmeye katkıda bulunabilir.
CDN, yani içerik dağıtım ağı, belirli içerikleri ziyaretçiye daha yakın ağ noktalarından sunmayı mümkün kılar.
Örneğin bir görselin kopyası uygun koşullarda ziyaretçiye yakın bir CDN sunucusunda tutulabilir.
Böylece görselin her ziyaret için dünyanın başka bir bölgesindeki asıl sunucudan getirilmesi gerekmez.
Ancak CDN kullanmak bütün içeriğin otomatik olarak önbelleğe alınacağı anlamına gelmez.
Görseller, CSS ve JavaScript gibi statik dosyalar önbellekleme için genellikle uygundur. Kullanıcıya özel HTML sayfaları veya oturum bilgisi taşıyan yanıtlar ise farklı kurallar gerektirir.
Örneğin herkesin okuyabildiği bir blog yazısıyla kullanıcının özel hesap bilgilerini gösteren sayfa aynı önbellek politikasına sahip olmamalıdır.
Önbelleğin yanlış yapılandırılması hâlinde güncel olmayan içerik gösterilebilir; daha ciddi hatalarda kişiselleştirilmiş verilerin uygunsuz biçimde paylaşılması riski de doğabilir.
Bu yüzden önbellek yalnızca hızlandırma ayarı değildir.
Doğru içeriğin doğru kullanıcıya gönderilmesini koruyarak gereksiz işlemleri azaltma yöntemidir.
Tarayıcı önbelleği ile sunucu önbelleği aynı şey değildir
Önbellek kelimesini sık duyuyoruz ama aslında farklı katmanlardan söz ediyoruz.
Tarayıcı önbelleği daha önce alınmış bazı kaynakları cihazda tutabilir.
CDN önbelleği uygun içerikleri dağıtık sunucularda saklayabilir.
Sunucu tarafındaki sayfa önbelleği önceden oluşturulmuş HTML çıktısını sunabilir.
WordPress nesne önbelleği ise bazı verilerin veya veri tabanı sorgusu sonuçlarının tekrar kullanılmasına yardımcı olabilir.
Bu yöntemlerin hepsine önbellek diyoruz ama aynı işi yapmıyorlar.
Örneğin WordPress’te içerik güncellenmiş olduğu hâlde eski görselin görünmesi, sorunun mutlaka WordPress veri tabanında olduğu anlamına gelmez.
Tarayıcıda, CDN’de veya başka bir önbellek katmanında eski kaynak bulunuyor olabilir.
Bu farkın nasıl anlaşılacağını Tarayıcı Önbelleği Ne Zaman Temizlenmeli? yazımızda daha uygulamalı biçimde inceliyoruz.
Önemli olan her sorunda bütün önbellekleri gelişigüzel silmemektir.
Çünkü önbelleği tamamen temizlemek, sonraki ziyaretlerde daha önce saklanmış dosyaların yeniden indirilmesine ve bazı sayfaların geçici olarak daha yavaş açılmasına da neden olabilir.
Aynı web sitesi iki kişide neden farklı davranır?
Bir kişi siteye girer ve her şey anında açılır.
Başka biri aynı adreste sayfanın geç yüklendiğini söyler.
Üçüncü kişi ise sayfanın eski görünümünü görür.
Bu durum ilk bakışta çelişkili görünse de teknik açıdan oldukça normal olabilir.
Çünkü web sitesinin deneyimi yalnızca sunucunun özelliklerine bağlı değildir.
Ziyaretçinin konumu, internet servis sağlayıcısı, kullanılan ağ, cihazın işlemci gücü, tarayıcı sürümü, önbellek durumu ve yüklü tarayıcı eklentileri sonucu etkileyebilir.
Örneğin güçlü bir masaüstü bilgisayar karmaşık bir sayfayı kolayca işleyebilir. Aynı sayfa düşük güçlü bir telefonda belirgin biçimde daha ağır çalışabilir.
Başka bir örnekte ziyaretçilerin biri daha önce sayfayı açtığı için bazı dosyaları önbellekten kullanırken diğer ziyaretçi bütün kaynakları ilk kez indiriyor olabilir.
Mobil veri üzerinden bağlanan kullanıcıyla evdeki Wi-Fi üzerinden bağlanan kullanıcının ağ gecikmeleri farklı olabilir.
Zayıf Wi-Fi sinyali de özellikle kayıp paketler ve bağlantı kararsızlığı nedeniyle deneyimi kötüleştirebilir. Böyle bir şüphede Wi-Fi Sinyali Zayıfsa Ne Yapmalı? rehberimiz bağlantı tarafını değerlendirmeye yardımcı olur.
Ayrıca web siteleri bazen ziyaretçiye göre farklı içerikler oluşturur.
Dil, oturum durumu veya kişisel tercihler farklı sayfa çıktıları oluşturabilir. Bu nedenle aynı adresin her kullanıcıya birebir aynı içeriği göstermesi de garanti değildir.
Bütün bunları düşündüğümüzde önemli bir sonuca ulaşıyoruz:
Bir web sitesinin hızı, sunucunun tek başına sahip olduğu bir özellik değil; sunucu, ağ ve kullanıcı cihazının birlikte oluşturduğu deneyimdir.
Bir web sitesinin gerçekten hızlı olduğunu nasıl anlarız?
Eskiden bir web sitesi için “iki saniyede açılıyor” gibi tek bir ölçüm yeterliymiş gibi düşünülebilirdi.
Oysa sayfanın hangi aşamada açılmış sayılacağı önemlidir.
İlk metnin görünmesiyle büyük görselin görünmesi farklı zamanlarda olabilir.
Bütün dosyaların indirilmesiyle kullanıcının düğmelere hızlı tepki alması da aynı şey değildir.
Google’ın Core Web Vitals yaklaşımı bu nedenle farklı kullanıcı deneyimi özelliklerini ayrı ayrı değerlendirir.
LCP: Asıl içerik ne zaman görünüyor?
Largest Contentful Paint, sayfanın görünür alanındaki en büyük uygun içerik öğesinin ne zaman çizildiğini ölçer.
Bu öğe büyük bir görsel veya metin bloğu olabilir.
Google’ın iyi kullanıcı deneyimi için önerdiği LCP hedefi 2,5 saniye veya daha azdır.
Ancak bunun bütün ziyaretlerde gerçekleşmesi beklenmez; değerlendirmelerde gerçek kullanıcı verilerinin dağılımı, özellikle yüzde 75’lik dilim dikkate alınır.
INP: Sayfa etkileşime ne kadar hızlı cevap veriyor?
Interaction to Next Paint, kullanıcının tıklama, dokunma ve klavye etkileşimlerine sayfanın verdiği görsel yanıtın gecikmesini değerlendiren ölçümdür.
İyi INP için önerilen eşik 200 milisaniye veya daha azdır.
Bir sayfa görsel olarak hızlı açılabilir ama yoğun JavaScript işlemleri nedeniyle kullanıcıya geç tepki verebilir.
İşte INP böyle bir problemi anlamamıza yardımcı olur.
CLS: Sayfa yüklenirken öğeler yerinden oynuyor mu?
Cumulative Layout Shift, sayfada beklenmedik yerleşim kaymalarını değerlendirir.
Bir yazıyı okumaya başladığınızda üst tarafa sonradan görsel veya reklam eklenmesi ve metnin aşağı kayması buna örnek olabilir.
Özellikle kullanıcı bir bağlantıya basmak üzereyken sayfanın yer değiştirmesi kötü bir deneyim oluşturur.
İyi CLS için önerilen değer 0,1 veya daha düşüktür.
Bu üç ölçüm birbirini tamamlar.
Bir site içerikleri hızlı gösterebilir ama etkileşimlerde gecikebilir.
Başka bir site hızlı tepki verirken yükleme sırasında sürekli kayabilir.
Bu nedenle gerçek performans tek bir puandan ibaret değildir.
Google’ın güncel tanımları ve önerilen eşikleri Web Vitals belgesinde bulunuyor.
Bir web sitesi açılmadığında hata nerede olabilir?
Şimdi görünmeyen yolculuğumuzu tersinden düşünelim.
Tarayıcıya adresi yazdık ama site açılmadı.
Bunun tek bir açıklaması yok.
Alan adı çözümlenemiyorsa DNS veya alan adı yapılandırmasıyla ilgili sorunlar bulunabilir.
Güvenli bağlantı kurulamıyorsa sertifika ya da bağlantı doğrulamasıyla ilgili problem yaşanıyor olabilir.
Sunucuya erişiliyor ama istenen sayfa bulunamıyorsa HTTP 404 yanıtı görülebilir.
Sunucu isteği işlerken beklenmedik bir hatayla karşılaşırsa HTTP 500 yanıtı oluşabilir.
Bir ara sunucu, asıl sunucudan zamanında yanıt alamazsa 504 gibi bir durum kodu döndürebilir.
Bunların her biri farklı anlam taşır.
Örneğin 404, çoğu durumda adresin karşılığındaki kaynağın bulunamadığını anlatır. Bu nedenle kullanıcıya görünen her 404 hatası için sunucunun tamamen çöktüğünü söylemek doğru değildir.
Benzer şekilde bir sitede 500 hatası görülmesi, mutlaka internet bağlantısının bozuk olduğu anlamına gelmez.
Bu ayrımı bilmek özellikle web sitesi sahipleri için değerlidir.
Çünkü yanlış aşamada çözüm aramak hem zaman kaybettirir hem de gereksiz değişikliklere yol açabilir.
DNS ile ilgili bir problem varken WordPress temasını değiştirmek genellikle çözüm getirmez.
Tarayıcının CSS dosyasını eski önbellekten gösterdiği bir durumda sunucu değiştirmek de sorunun kaynağına yönelik bir müdahale değildir.
Doğru çözüm, hatanın hangi aşamada oluştuğunu belirlemekle başlar.
Web sitesi sahipleri bu görünmeyen yolculuktan ne öğrenebilir?
Bir web sitesi kurmak yalnızca güzel bir tasarım seçmek değildir.
Kullanıcının görebildiği tasarım, aslında daha büyük bir sistemin son aşamasıdır.
Arka planda alan adı, DNS, hosting, web sunucusu, uygulama, veri tabanı, önbellek, güvenlik ve tarayıcı bulunur.
Sitenin sahibi bu bileşenlerin tamamını ayrıntılı biçimde yönetmek zorunda olmayabilir. Ancak aralarındaki temel farkları bilmek büyük avantaj sağlar.
Örneğin bir sitenin yavaş olduğunu düşünelim.
Sorunu çözmek için hemen daha pahalı hosting satın almak ilk akla gelen seçenek olabilir.
Fakat gecikmenin büyük bölümü tarayıcıdaki JavaScript işlemlerinden kaynaklanıyorsa hosting yükseltmesi beklenen sonucu sağlamayabilir.
Başka bir durumda sunucu yanıtı gerçekten çok yavaştır. O zaman tema üzerindeki küçük görsel değişikliklerinden önce sunucu tarafının incelenmesi daha mantıklı olabilir.
Bir başka örnekte site yalnızca ilk ziyarette yavaştır. Sonraki ziyaretler hızlanıyordur.
Bu durumda önbellek davranışı ve ilk yüklemede indirilen kaynaklar önemli birer ipucu olabilir.
WordPress üzerinde çalışan bir siteyi yayına almadan önce yerel ortamda denemek de bu nedenle yararlıdır. LocalWP Nedir? rehberimiz, değişiklikleri canlı ziyaretçileri etkilemeden test etmenin pratik bir yolunu anlatıyor.
Ancak yerel ortamda hızlı çalışan bir sayfanın internette de aynı hızda açılacağı garanti değildir. Gerçek ağ gecikmeleri, CDN davranışı ve hosting ortamı farklı olabilir.
Böylece web performansına daha sağlıklı yaklaşabiliriz:
Önce yavaşlık nerede oluşuyor?
Sunucu yanıtında mı?
Kaynakların indirilmesinde mi?
Tarayıcının sayfayı oluşturmasında mı?
Yoksa kullanıcı etkileşimlerinde mi?
Bu soruların cevabını bulmak, rastgele optimizasyon ayarları değiştirmekten çok daha değerlidir.
Webin başarısı biraz da karmaşıklığını gizleyebilmesinde
Buraya kadar bir web sitesinin açılması sırasında ne kadar çok sistemin iş yaptığını gördük.
Alan adları çözümleniyor. Güvenli bağlantılar kuruluyor. İstekler doğru sunuculara yönlendiriliyor. Gerekirse veri tabanları sorgulanıyor. HTML hazırlanıyor. CSS ve JavaScript işleniyor. Görseller çiziliyor ve kullanıcıya etkileşimli bir sayfa sunuluyor.
Bütün bunların yanında önbellekler, içerik dağıtım ağları ve tarayıcının kendi optimizasyonları devreye giriyor.
Oysa kullanıcı bunların hiçbirini görmek zorunda değil.
Bir ziyaretçinin beklentisi son derece basittir:
Adresi yazdığımda sayfa açılsın.
Tıkladığımda karşılık versin.
Okumaya başladığımda içerik yerinden oynamasın.
Bilgilerim güvenli biçimde aktarılsın.
Modern webin başarısı, karmaşık altyapısını kullanıcıya mümkün olduğunca hissettirmemesidir.
Fakat bu görünmezlik bazen yanlış düşünmemize neden oluyor.
İnternet yavaş dediğimizde aslında sunucunun yanıtını bekliyor olabiliriz.
Site bozuk dediğimizde tarayıcı eski bir dosya gösteriyor olabilir.
Hosting kötü dediğimizde esas sorun sayfaya yüklenen ağır JavaScript olabilir.
Bunların hepsi kullanıcıya benzer bir his verir.
Ama her birinin çözümü farklıdır.
İşte web teknolojilerini anlamanın gerçek faydası burada ortaya çıkar.
Yalnızca teknik terimleri öğrenmiş olmayız.
Sorunların hangi noktada ortaya çıkabileceğini ve bir web sayfasının neden göründüğünden çok daha karmaşık olduğunu da anlarız.
Kısaca
Bir web sitesinin açılması tek bir işlem değildir.
Adres çubuğuna yazdığımız alan adı çözülür, uygun bağlantı kurulur, web sunucusuna istek iletilir ve sayfanın içeriği hazırlanarak tarayıcıya gönderilir.
Tarayıcı HTML, CSS, JavaScript ve görselleri işleyerek gördüğümüz sayfayı oluşturur.
Bu süreçte DNS, HTTPS, CDN, önbellek, hosting, WordPress ve tarayıcı birbirinden farklı görevler üstlenir.
Bu nedenle bir web sitesinin yavaş olması her zaman internet bağlantısının veya hosting hizmetinin yavaş olduğu anlamına gelmez.
Gecikme yolculuğun herhangi bir aşamasında oluşabilir.
Webin perde arkasını anlamak bize iki önemli şey kazandırır: Ziyaret ettiğimiz sitelerin nasıl çalıştığını daha iyi kavrarız ve bir sorun yaşadığımızda nerede araştırma yapacağımızı daha doğru belirleriz.
Çünkü ekranda gördüğümüz bir web sayfası, uzak bir sunucudan gönderilmiş basit bir görüntü değildir.
Birbirinden farklı sistemlerin aynı isteğe cevap vermek için birlikte oluşturduğu canlı bir sonuçtur.
Ve bütün bu karmaşık yolculuğun sonunda kullanıcıya kalan şey, yalnızca bir tıklamadır.
Yeni rehberleri kaçırmayın
Yeni teknoloji rehberleri ve pratik çözümler e-postanıza gelsin.
