İçerik
- Yavaşlamanın bedeli
- İçerik dağıtım ağları
- Diğer teknikler
- Ön yükleme ve önceden oluşturma ile ilgili hususlar
- Ajax içeriği yükleniyor
Bu makale ilk olarak web tasarımcıları ve geliştiricileri için dünyanın en çok satan dergisi olan .net dergisinin 231. sayısında yayınlandı.
Her web sitesi için hız önemli olmalıdır. Google'ın site hızını arama sonuçları için bir sıralama ölçütü olarak kullandığı bilinen bir gerçektir. Bu bize ziyaretçilerin hızlı web sitelerini tercih ettiğini söylüyor - burada sürpriz yok!
Jakob Nielsen 1993'te yanıt sürelerinin üç sınırı hakkında yazdı; Araştırma internet standartlarına göre eski olmasına rağmen, aradan geçen 19 yıl içinde psikolojimiz pek değişmedi. Bir sistem 0,1 saniyenin altında yanıt verirse anlık olarak algılanacağını, bir saniyeden daha hızlı yanıtların ise kullanıcının düşünce akışının kesintisiz kalmasını sağladığını belirtiyor. 0.1 saniyede bir web sayfasının yüklenmesi muhtemelen imkansızdır; Yaklaşık 0,34 saniye, Google İngiltere'nin en iyi yükleme süresini temsil eder, bu nedenle bu, daha gerçekçi (iddialı olsa da) bir kıyaslama işlevi görür. 0.34 ila 1 saniye aralığında bir yerde bir sayfa yüklemesi elde edilebilir ve önemlidir.
Yavaşlamanın bedeli
Bu tür hedeflerin web siteniz ve işiniz için gerçek dünya etkileri vardır. Google’dan Marissa Mayer, 2006 yılında, arama motorunun döndürdüğü sonuç sayısının 30'a çıkarıldığı bir denemeden bahsetti. Bu, sayfa yükleme süresini yaklaşık 500 ms yavaşlattı ve buna bağlanan trafikte% 20 düşüş oldu. Bu arada Amazon, sayfa yüklemesini yapay olarak 100 ms'lik artışlarla geciktirdi ve "çok küçük gecikmelerin bile gelirde önemli ve maliyetli düşüşlere neden olacağını" buldu.
Yavaş web siteleriyle bağlantılı diğer olumsuz ilişkiler, daha az güvenilirlik, daha düşük algılanan kalite ve sitenin daha az ilgi çekici ve çekici görülmesini içerir. Artan kullanıcı hayal kırıklığı ve artan kan basıncı, muhtemelen hepimizin bir noktada deneyimlediğimiz diğer iki etkidir! Ancak web sitelerimizin bu sorunları önlemek için yeterince hızlı yüklendiğinden nasıl emin olabiliriz?
İlk bakmanız gereken şeylerden biri, HTML kodunuzun boyutudur. Bu muhtemelen en çok gözden kaçan alanlardan biridir, belki de insanlar bunun artık modern geniş bant bağlantılarıyla o kadar alakalı olmadığını varsaydığı içindir. Bazı içerik yönetim sistemleri, ortaya çıkardıkları miktar konusunda oldukça liberaldir - kendi sitelerinizi elden geçirmenin daha iyi olmasının bir nedeni.
Bir kılavuz olarak, çoğu sayfayı 50 KB'lik HTML koduna kolayca sığdırabilmelisiniz ve 20 KB'nin altındaysanız, o zaman çok iyi gidiyorsunuzdur. Açıkça istisnalar var, ancak bu oldukça iyi bir kuraldır.
İnsanların artık mobil cihazlarda tam web sitelerine daha sık göz attığını da unutmamak gerekir. Bir mobil cihazdan görüntülenen siteler arasındaki hız farklılıkları, kablolu bağlantılara göre daha yavaş aktarım hızlarına sahip olmaları nedeniyle genellikle daha belirgindir. Sayfa başına 100 KB boyut farkına sahip iki rakip web sitesi, bazı yavaş mobil ağlarda, Jakob Nielsen tarafından belirtilen "kesintiye uğramış düşünce akışı" bölgesinde bir saniyeden fazla yükleme süresi farkı anlamına gelebilir. Düzeltici, daha hızlı web sitesi, gezinmek için çok daha az sinir bozucu olacak, daha şişman web sitelerine göre belirgin bir rekabet avantajı sağlayacak ve tekrar ziyaretleri teşvik etme yolunda uzun bir yol kat edecek.
Çoğu web sunucusunun önemli bir özelliği, HTML'yi sıkıştırılmış bir biçimde sunma yeteneğidir. HTML doğası gereği çok sayıda tekrar eden veri içerdiğinden, onu sıkıştırma için mükemmel bir aday yapar. Örneğin, bir ana sayfanın 18,1 KB HTML'si, sıkıştırılmış biçimde sunulduğunda 6,3 KB'a düşürülür. Bu yüzde 65 tasarruf! Sıkıştırma algoritmaları, çalışmak zorunda oldukları metin gövdesi ne kadar büyükse verimliliği artırır, böylece daha büyük HTML sayfalarında daha büyük tasarruflar elde edersiniz. Popüler bir forumdaki 138,1K bir sayfa, sıkıştırılmış olarak sunulduğunda 25,7K'ya düşürülür, bu da yüzde 80'in üzerinde bir tasarruf sağlar - bu da kaynakların toplam aktarım sürelerini önemli ölçüde artırabilir.
Bu biçimde HTML sunmanın neredeyse hiçbir olumsuz yanı yoktur; herkes tüm HTML içeriği için bunu etkinleştirmelidir.Bazı web sunucuları, statik ve dinamik olarak oluşturulmuş içeriği sıkıştırmak için farklı ayarlara sahiptir, bu nedenle, mümkünse her ikisi için de sıkıştırılmış içerik sunmanızı sağlamaya değer.
İçerik dağıtım ağları
İçerik dağıtım ağları (CDN'ler olarak bilinir), web sitenizin yükleme sürelerini de önemli ölçüde iyileştirebilir. CDN'ler, tüm dünyaya dağıtılmış ve içeriğinizin kopyalarını tutan sunucular koleksiyonudur. Bir kullanıcı, web sitenizden bir CDN'de barındırılan bir görüntü istediğinde, görüntüyü sunmak için coğrafi olarak kullanıcıya en yakın CDN'deki sunucu kullanılır.
Çok sayıda CDN hizmeti mevcuttur. Bunlardan bazıları çok maliyetlidir, ancak daha ucuz CDN'lerden daha iyi performans sunacaklarının reklamını yapar. Ücretsiz CDN hizmetleri de büyümeye başladı ve web sitenizdeki performansı iyileştirip iyileştiremeyeceklerini görmek için denemeye değer olabilir.
Bir CDN kullanırken göz önünde bulundurulması gereken önemli bir nokta, herhangi bir SEO değerini kaybetmemek için doğru şekilde kurduğunuzdan emin olmaktır. Web sitenizin yapısına bağlı olarak alanınızda barındırılan resimlerden çok fazla trafik alıyor olabilirsiniz ve bunları harici bir alana taşıyarak trafiğinizi olumsuz etkileyebilir. Amazon S3 hizmeti, bir alt alan adını CDN'de oldukça tercih edilen bir özellik olan CDN'sine yönlendirmenize olanak tanır.
İçeriği farklı bir alan adında (CDN gibi) veya kendi alan adınızda, çerezleri ayarlamayan bir alt alan adında sunmanın başka bir önemli faydası daha vardır. Bir etki alanında bir tanımlama bilgisi ayarlandığında, tarayıcı her istekle birlikte aynı alandaki her kaynağa tanımlama bilgisi verilerini gönderir. Çoğunlukla çerez verileri, resimler, CSS veya JavaScript dosyaları gibi statik içerik için gerekli değildir. Web kullanıcılarının yükleme hızları genellikle mevcut indirme hızlarından çok daha yavaştır ve bu, bazı durumlarda sayfa yükleme sürelerinde önemli ölçüde yavaşlamaya neden olabilir. Statik içeriğinizi sunmak için farklı bir etki alanı adı kullanarak, tarayıcılar bu gereksiz çerez verilerini göndermezler çünkü bunlar katı etki alanları arası politikalara sahiptirler. Bu, her kaynak için istek sürelerini önemli ölçüde hızlandırabilir.
Web sitelerindeki tanımlama bilgileri de bir HTTP isteğinin çoğunu alabilir; 1.500 bayt, büyük ağlar için en sık kullanılan tek paket sınırı civarındadır, bu nedenle HTTP isteklerinizi bu sınırın altında tutabiliyorsanız, HTTP isteğinin tamamı tek bir pakette gönderilmelidir. Bu, sayfa yükleme sürelerinde iyileştirmeler sağlayabilir. Google, çerezlerinizin boyutunun 400 bayttan küçük olmasını önerir - bu, web sitelerinizin HTTP isteklerini tek paket / 1.500 bayt sınırının altında tutmanın uzun bir yoludur.
Diğer teknikler
Sitenizin hızına büyük yararlar sağlayabilecek, uygulanması daha kolay başka teknikler de vardır. Birincisi, JavaScript dosyalarınızı HTML belgenizin sonuna, kapanış gövde etiketinin hemen öncesine koymaktır, çünkü tarayıcıların aynı ana bilgisayardan paralel olarak kaç kaynak indirebilecekleri konusunda sınırları vardır.
1999'da yazılan orijinal HTTP 1.1 spesifikasyonu, tarayıcıların her bir ana bilgisayar adından yalnızca paralel olarak en fazla iki kaynak indirmesini önerir. Ancak modern tarayıcıların varsayılan olarak altı civarında bir sınırı vardır. Web sayfanızda altıdan fazla harici kaynak varsa (resimler / JavaScript / CSS dosyaları gibi), tarayıcıyı garantilemek için bunları birden çok etki alanından (ana etki alanı adınızdaki bir alt etki alanı veya bir CDN gibi) sunmak için iyileştirilmiş performans sunabilir. paralel indirmelerde maksimum sınırına ulaşmaz.
Birden fazla isteği farklı etki alanlarına bölmek yerine, bunları birleştirmeyi düşünebilirsiniz. Her HTTP isteğinin kendisiyle ilişkili bir ek yükü vardır. Web sitenizdeki simgeler gibi ayrı kaynaklar olarak sunulan düzinelerce görsel, çok fazla israf yaratacak ve web sitenizde genellikle önemli bir yavaşlamaya neden olacaktır. Resimlerinizi "hareketli grafik sayfası" olarak bilinen tek bir resimde birleştirerek, gereken istek sayısını azaltabilirsiniz. Görüntüyü görüntülemek için, bir öğenin genişliğini ve yüksekliğini, görüntülemek istediğiniz görüntününkine ayarlayarak ve ardından arka planı hareketli grafik sayfasına ayarlayarak CSS'de tanımlarsınız. Kullanarak arka plan konumu özelliği, web sitenizde amaçlanan görüntü olarak görünmesi için arka plan hareketli grafik sayfasını bir konuma taşıyabiliriz.
Sprite sayfaları başka faydalar da sunar. Fareyle üzerine gelinen görüntüleri kullanıyorsanız, bunları aynı model sayfasında depolamak, fareyle üzerine gelme başlatıldığında, fareyle üzerine gelinen görüntü model sayfasına zaten yüklendiğinden gecikme olmadığı anlamına gelir! Bu, kullanıcının algılanan yükleme süresini önemli ölçüde iyileştirebilir ve çok daha duyarlı bir web sitesi oluşturabilir.
İçindeki diğer görüntülerin boyutlarını belirleme img /> etiketler ayrıca web sayfanızın algılanan yükleme süresini artırmada önemli bir faktördür. Sayfalardaki resimler için genişlik ve yüksekliği açıkça ayarlamayan geliştiriciler yaygındır. Bu, her görüntü (kısmen) yüklenirken sayfanın boyutunun atlayarak genişlemesine ve işlerin yavaşlamasına neden olabilir. Açık boyutlar ayarlanırsa, tarayıcı yüklenirken resim için yer ayırabilir, bu da sayfa boyutunun değişmesini durdurabilir ve bazen kullanıcının algılanan yükleme süresini önemli ölçüde iyileştirebilir.
Peki bunu iyileştirmek için başka ne yapabiliriz? Ön getirme, HTML5'te bulunan böyle bir özelliktir. Önceden getirme, sayfaların ve kaynakların, kullanıcı fiilen talep etmeden önce yüklenmesini sağlar. Desteği şu anda Firefox ve Chrome ile sınırlıdır (alternatif bir sözdizimi ile). Ancak, uygulama kolaylığı ve web sayfanızın algılanan yükleme süresini iyileştirmedeki kullanışlılığı o kadar büyüktür ki, uygulamayı düşünmeniz gereken bir şeydir.
! —Firefox Önceden Getirme -> link rel = "prefetch" href = "http://www.example.com/page2.html">! - Chrome Prerender -> link rel = "prerender" href = "http: / /www.example.com/page2.html">!—Hem tek satırda -> bağlantı rel = "ön getirici ön oluşturucu" href = "http://www.example.com/page2.html">
Önceden getirme ve önceden oluşturma arasında davranışsal bir fark vardır. Mozilla'nın önceden getirmek belirli bir URL için en üst düzey kaynağı, genellikle HTML sayfasının kendisini yükler ve yükleme burada durur. Google'ın önceden oluşturucu alt kaynakları da yükler ve Google'ın ifadesiyle "sayfayı kullanıcıya göstermek için gereken tüm işi, kullanıcı tıklayana kadar gerçekten göstermeden yapar".
Ön yükleme ve önceden oluşturma ile ilgili hususlar
Ancak bu özelliği kullanmak aynı zamanda önemli hususları da beraberinde getirir. Çok fazla öğeyi veya sayfayı önceden oluşturursanız / önceden yüklerseniz, kullanıcının tüm göz atma deneyimi zarar görebilir; herhangi bir sunucu tarafı istatistikleriniz varsa, bunlar büyük ölçüde çarpık olabilir. Kullanıcı önceden yüklenmiş kaynağı tıklamaz ve web sitenizden çıkarsa, istatistik izleyiciniz ziyareti gerçek değil iki sayfa görüntüleme olarak sayabilir. Bu, hemen çıkma oranları gibi önemli ölçümler için yanıltıcı olabilir.
Chrome’un önceden oluşturucu geliştiricilerin bilmesi gereken başka bir uyarı var, çünkü önceden oluşturulmuş sayfa JavaScript'i çalıştıracak. Önceden oluşturucu, sayfayı, bağlantı kullanıcı tarafından tıklanmış gibi hemen hemen aynı şekilde yükleyecektir. Önceden oluşturucu ile Chrome tarafından özel HTTP üstbilgileri gönderilmez; ancak, Sayfa Görünürlüğü API'si, sayfanın önceden oluşturulup oluşturulmadığını ayırt etmenize olanak tanır. Bu, reklam komut dosyaları ve istatistik izleyiciler gibi kullandığınız tüm üçüncü taraf komut dosyaları için yine çok önemlidir (Google Analytics zaten Sayfa Görünürlüğü API'sını kullanmaktadır, bu nedenle bu konuda endişelenmenize gerek kalmaz). Bu varlıkların Page Visibility API ile tekrar yanlış şekilde kullanılması, önemli metrikleri çarpıtma riskini almanıza neden olur.
Kullanma önceden getirmek ve önceden oluşturucu sayfalara ayrılmış içerik muhtemelen güvenli ve yararlı bir uygulamadır - örneğin, birden çok bölüme ayrılmış bir eğitici web sayfasında. Özellikle öğreticiler gibi içeriklerde, Nielsen’ın "kesintisiz düşünce akışı" sınırları içinde kalmak muhtemelen önemlidir.
Google Analytics, hangi sayfaları önceden oluşturmak / önceden getirmek isteyebileceğiniz konusunda da değerli ipuçları verebilir. Sayfa İçi Analizini kullanarak, ana sayfanızdaki hangi bağlantının tıklanma olasılığının en yüksek olduğunu belirleyebilirsiniz. Yüksek tanımlı harekete geçirici mesajların olduğu bazı durumlarda, bu yüzde son derece yüksek olabilir ve bu da onu önceden yükleme için mükemmel bir aday yapar.
Hem önceden getirme hem de önceden oluşturma etki alanları arası çalışır - tarayıcılar için alışılmadık derecede liberal bir duruş ve etki alanları arası erişimde genellikle son derece katıdır. Ancak, bu muhtemelen Google’ın ve Mozilla’nın lehine çalışmaktadır çünkü kullanıcıları için çeşitli şekillerde daha hızlı bir göz atma deneyimi oluşturabilirler ve bu tür özellikleri henüz desteklemeyen diğer tarayıcılara göre önemli bir rekabet avantajı sağlarlar.
Önceden yükleme ve özellikle önceden oluşturma, web sayfalarının algılanan yükleme sürelerinde önemli iyileştirmeler sağlayabilen güçlü araçlardır. Ancak, kullanıcının tarama deneyiminin doğrudan ve olumsuz etkilenmemesi için nasıl çalıştıklarını anlamak önemlidir.
Ajax içeriği yükleniyor
Yükleme sürelerini iyileştirmenin bir başka yolu da, Ajax'ı tüm sayfayı yeniden yüklemenin aksine içeriği yüklemek için kullanmaktır - daha verimli, çünkü her seferinde içeriği çevreleyen standart metni değil, yalnızca değişiklikleri yüklüyor.
Çok sayıda Ajax yüklemesinin sorunu, doğal olmayan bir göz atma deneyimi gibi hissettirmesidir. Düzgün bir şekilde çalıştırılmazsa, geri ve ileri düğmeleri kullanıcının beklediği gibi çalışmaz ve sayfalara yer işareti koymak veya sayfayı yenilemek gibi eylemler de beklenmedik şekillerde davranır. Web sitelerini tasarlarken, bunun gibi düşük seviyeli davranışlara müdahale etmemeniz tavsiye edilir - bu, kullanıcılar için çok rahatsız edicidir ve dostça değildir. Bunun en iyi örneği, bazı web sitelerinin telif hakkı ihlallerini önlemek için beyhude bir girişim olarak web sayfalarına sağ tıklamayı devre dışı bırakma çabaları olabilir. Ajax'ın uygulanması tarayıcının çalışmasını sağ tıklamayı devre dışı bırakmakla aynı niyetle etkilemese de, efektler benzerdir.
HTML5, Geçmiş API ile bu sorunları çözmek için bir yol kat ediyor. Tarayıcılarda iyi desteklenmektedir (Internet Explorer dışında, ancak IE10'da desteklenmesi planlanmaktadır). HTML5 geçmiş API'siyle çalışarak, Ajax ile içerik yüklerken aynı zamanda kullanıcılar için "normal" bir göz atma deneyimini simüle edebiliyoruz. Düzgün kullanıldığında geri, ileri ve yenileme düğmelerinin tümü beklendiği gibi çalışır. Adres çubuğu URL'si de güncellenebilir, yani yer imi artık tekrar düzgün çalışmaktadır. Doğru bir şekilde uygulanırsa, çok sayıda tekrarlanan kaynak yüklemesini ortadan kaldırabilir ve JavaScript devre dışı bırakılmış tarayıcılar için zarif geri dönüşlere sahip olabilirsiniz.
Ancak büyük bir dezavantajı var: Oluşturmaya çalıştığınız sitenin karmaşıklığına ve işlevine bağlı olarak, Ajax içerik yüklemesini Geçmiş API ile kullanıcıya görünmeyecek şekilde uygulamak zordur. Site aynı zamanda sunucu tarafı komut dosyası kullanıyorsa, kendinizi iki kez bir şeyler yazarken bulabilirsiniz: bir kez JavaScript'te ve yine sunucuda - bu da bakım sorunlarına ve tutarsızlıklara yol açabilir. Mükemmelleştirmek zor ve zaman alıcı olabilir, ancak amaçlandığı gibi çalışırsa, kullanıcı için gerçek ve algılanan yükleme sürelerini önemli ölçüde azaltabilirsiniz.
Sitenizin hızını artırmaya çalışırken bazı çözülemeyen sorunlarla karşılaşabilirsiniz. Bu makalenin başında belirtildiği gibi, Google'ın sayfa hızını bir sıralama ölçütü olarak kullandığı bir sır değil. Bu, sitenizin hızını artırmak için önemli bir motivasyon olmalıdır. Ancak, Google Web Yöneticisi Araçları’nın sayfa hızı raporları gibi kaynakları kullandığınızda, beklediğinizden daha yavaş yükleme süreleri bildireceklerini fark edebilirsiniz.
Nedeni, Facebook Beğen düğmeleri veya Tweet düğmeleri gibi üçüncü taraf komut dosyaları olabilir. Bunlar genellikle yüzlerce milisaniye bölgesinde bekleme sürelerine sahip olabilir ve bu da tüm web sitenizin yükleme süresinin önemli ölçüde düşmesine neden olabilir. Ancak bu, bu komut dosyalarını kaldırmak için bir argüman değildir - muhtemelen web sitenizde sosyal medya düğmelerine sahip olmak daha önemlidir. Bu düğmeler genellikle sayfanızda nispeten küçük alanlar kaplar, bu nedenle ziyaretçinin algılanan yükleme süresini önemli ölçüde etkilemeyecektir - bu, hız optimizasyonları yaparken öncelikli olarak hizmet vermemiz gereken şeydir.
Kardeş sitemiz Creative Bloq'da 101 CSS ve Javascript öğreticisini keşfedin.
