Milyonlarca sitenin web sitesi yükleme performansını iyileştirmek ve iyi PageSpeed Insights ve Önemli Web Verileri puanları almaya giden yolu açmak için Wix'te bazı önemli değişikliklerin yapıldığı bir örnek olay.
Endüstri standartlarından, bulut sağlayıcılardan ve CDN özelliklerinden yararlanmak ve web sitesi çalışma zamanımızda yaptığımız önemli yeniden düzenlemeler sayesinde Wix sitelerinin yüzdesi, CrUX ve HTTPArchive verilerine göre tüm Önemli Web Verileri metriklerinde yıldan yıla üç kattan fazla artış gösterdi. 75. yüzdelik dilime ulaştı.
Wix performans odaklı bir kültürü benimsedi ve daha fazla iyileştirme kullanıcılara sunulmaya devam edecek. Performans TPG'lerine odaklandıkça Önemli Web Verileri eşiklerini geçen sitelerin sayısının artmasını bekliyoruz.
Genel bakış
Performans dünyası, birçok değişken ve incelik içeren güzel bir şekilde karmaşık. Araştırmalar, site hızının işletmelerin dönüşüm oranları ve gelirleri üzerinde doğrudan etkisi olduğunu gösteriyor. Son yıllarda sektör, performans görünürlüğüne ve web'i daha hızlı hale getirmeye daha fazla önem verdi. Mayıs 2021'den itibaren sayfa deneyimi sinyalleri, Google Arama sıralamasına dahil edilecektir.
Wix'in benzersiz zorluğu milyonlarca siteyi desteklemektedir. Bunlardan bazıları yıllar önce oluşturulmuş ve o zamandan beri güncellenmemiştir. Kullanıcılarımıza sitelerinin performansını analiz etmek ve iyileştirmek için neler yapabilecekleri konusunda yardımcı olacak çeşitli araçlarımız ve makalelerimiz bulunmaktadır.
Wix, yönetilen bir ortamdır ve her şey kullanıcının elinde değildir. Ortak altyapıları paylaşmak, tüm bu siteler için birçok zorluk yaratsa da büyük ilerlemeler (ör. ölçek ekonomilerinden yararlanmak) için fırsatlar doğurur.
Ortak bir dilde konuşma
Performansla ilgili temel zorluklardan biri, hem teknik hem de algılanan performansı dikkate alırken kullanıcı deneyiminin farklı yönlerini ele alan ortak bir terminoloji bulmaktır. Kurum içinde iyi tanımlanmış, ortak bir dil kullanmak, farklı teknik parçaları ve dezavantajları kolayca tartışmamızı ve sınıflandırmamızı sağladı, performans raporlarımızı netleştirdi ve öncelikle iyileştirmeye odaklanmamız gereken yönleri anlamamıza büyük ölçüde yardımcı oldu.
Tüm izleme ve dahili görüşmelerimizi, Web Verileri gibi endüstri standardı metrikleri içerecek şekilde düzenledik. Bu metrikler:
Sitenin karmaşıklığı ve performans puanları
Yalnızca HTML kullanarak çok basit hale getirdiğiniz ve CDN aracılığıyla sunduğunuz sürece anında yüklenen bir site oluşturmak oldukça kolaydır.
Ancak gerçek şu ki siteler, giderek daha karmaşık ve gelişmiş bir hal alıyor, belge yerine uygulamalar gibi çalışıyor ve bloglar, e-ticaret çözümleri, özel kodlar gibi işlevleri destekliyor.
Wix çok çeşitli şablonlar sunarak kullanıcılarının birçok iş özelliğine sahip siteleri kolayca oluşturmalarını sağlar. Bu ek özellikler genellikle bazı performans maliyetlerine neden olur.
Yolculuk
Başlangıçta HTML,
Bir web sayfası her yüklendiğinde, HTML belgesini almak için her zaman bir URL'ye yapılan ilk istekle başlar. Bu HTML yanıtı, sitenizin çalıştırılması ve oluşturulması için tüm ek istemci isteklerini ve tarayıcı mantığını tetikler. Yanıtın başlangıcı gelene kadar (TTFB - ilk bayta geçiş süresi olarak bilinir) hiçbir şey olmadığı için bu, sayfa yüklemenin en önemli kısmıdır.
Geçmiş: istemci taraflı oluşturma (CSR)
Büyük ölçekli sistemler çalıştırırken performans, güvenilirlik ve maliyet gibi avantajları her zaman göz önünde bulundurmanız gerekir. Birkaç yıl kadar önce Wix, istemci tarafında oluşturma (CSR) yöntemini kullandı.Bu işlemde gerçek HTML içeriği, istemci tarafında JavaScript aracılığıyla (yani tarayıcıda) oluşturulurdu. Böylece, arka uç işlem maliyetleri yüksek olmadan yüksek ölçekte siteleri destekleyebiliriz.
CSR, ortak bir HTML belgesi kullanmamıza olanak sağladı. Bu belge aslında boştu. Bütün bu işlem, gerekli kodun ve verilerin indirilmesini tetiklemekteydi. Daha sonra, bu işlem daha sonra istemci cihazında tam HTML'yi oluşturmak için kullanılıyordu.
Bugün: sunucu tarafı oluşturma (SSR)
Birkaç yıl önce sunucu tarafı oluşturmaya (SSR) geçiş yaptık. Bu yöntem hem SEO hem de performans için faydalı oldu, ilk sayfa görünürlük sürelerini iyileştirdi ve JavaScript çalıştırmak için tam desteğe sahip olmayan arama motorları için dizine eklemeyi daha iyi hale getirdi.
Bu yaklaşım, özellikle yavaş cihazlarda/bağlantılarda görünürlük deneyimini iyileştirdi ve performansın daha fazla optimizasyonuna olanak tanıyacak bir fırsat sundu. Ancak bu aynı zamanda, her bir web sayfası isteği için anında benzersiz bir HTML yanıtının oluşturulması anlamına geliyordu. Bu, özellikle çok sayıda görüntülemeye sahip siteler için ideal olandan çok uzaktı.
Birden çok konumda önbelleğe almayla tanışın
Her sitenin HTML'si çoğunlukla statik olmakla birlikte, bazı dikkat edilmesi gereken noktalara sahipti:
- Sık sık değişir. Bir kullanıcı sitesini her düzenlediğinde veya site verilerinde değişiklik yaptığında (ör. web sitesindeki mağaza envanteri)
- Ziyaretçilere özel belirli veri ve çerezlere sahipti. Yani aynı siteyi ziyaret eden iki kişi biraz farklı HTML görecekti. Örneğin, bir ziyaretçinin alışveriş sepetine eklediği öğeleri veya ziyaretçinin işletmeyle daha önce başlattığı sohbeti hatırlamak gibi ürün özelliklerini desteklemek için bu özellikler kullanılabilir.
- Sayfaların tümü önbelleğe alınabilir değildir. Örneğin, geçerli zamanı dokümanın bir parçası olarak gösteren özel kullanıcı kodu bulunan bir sayfa, önbelleğe alınmaya uygun değildir.
Başlangıçta, HTML'yi ziyaretçi verileri olmadan önbelleğe alma gibi nispeten güvenli bir yaklaşım benimsedik ve sonra her bir önbellek isabeti için her ziyaretçi için HTML yanıtının yalnızca belirli bölümlerini anında değiştirdik.
Şirket içi CDN çözümü
Bunu şirket içi bir çözüm dağıtarak yaptık: Proxy kullanma ve önbelleğe alma için Varnish HTTP Önbelleği, geçersiz kılma mesajları için Kafka ve bu HTML yanıtlarını proxy olarak temsil eden ancak HTML'yi değiştirip önbelleğe alınan yanıta ziyaretçiye özel veriler ve çerezler ekleyen Scala/Netty tabanlı bir hizmet kullandık.
Bu çözüm, bu ince bileşenleri çok daha fazla coğrafi konumda ve dünyanın her yerine yayılan birden fazla bulut sağlayıcı bölgesinde dağıtmamızı sağladı. 2019'da 15'ten fazla yeni bölgeyi kullanıma sunduk ve önbelleğe almaya uygun olan sayfa görüntülemelerimizin% 90'ından fazlası için önbelleğe almayı kademeli olarak etkinleştirdik. Ek konumlardan sitelere reklam sunmak, içeriği web sitesini ziyaret edenlerle yakınlaştırarak istemciler ve HTML yanıtını sunan sunucular arasındaki ağ gecikmesini azalttı.
Aynı çözümü kullanarak belirli salt okunur API yanıtlarını önbelleğe almaya ve site içeriğinde yapılan tüm değişikliklerde önbelleği geçersiz kılmaya da başladık. Örneğin, sitedeki blog yayınlarının listesi önbelleğe alınır ve bir yayın paylaşıldığında/değiştirildiğinde geçerliliğini yitirir.
Karmaşıklığı azaltma
Önbelleğe almayı uygulamak, çoğu zaman TTFB ve FCP aşamalarında performansı önemli ölçüde iyileştirdi ve içeriği son kullanıcıya daha yakın bir konumdan sunarak güvenilirliğimizi artırdı.
Ancak, her yanıt için HTML'nin değiştirilmesi ihtiyacı, gereksiz bir karmaşaya yol açmıştı. Bu durum, kaldırılırsa daha fazla performans artışı için fırsat anlamına geliyordu.
Tarayıcı önbelleğine alma (ve CDN'ler için hazırlıklar)
%~13
Doğrudan tarayıcı önbelleğinden sunulan HTML istekleri sayesinde bant genişliğinden tasarruf edebilir ve yinelenen görünümler için yükleme sürelerini kısaltabilirsiniz
Bir sonraki adım, bu ziyaretçiye özel verileri HTML'den tamamen kaldırmak ve HTML geldikten sonra istemcinin bu amaçla çağırdığı ayrı bir uç noktadan geri getirmekti.
Bu verileri ve çerezleri, her sayfa yüklemesinde çağrılan yeni bir uç noktaya dikkatlice taşıdık. Ancak bu uç noktaya, tam sayfa etkileşimine ulaşmak için yalnızca hidrasyon sürecinde gerekli olan ince bir JSON dosyası döndürüldü.
Bu, HTML'nin tarayıcı önbelleğine alınmasını etkinleştirmemize olanak tanıdı. Diğer bir deyişle, tarayıcılar artık yinelenen ziyaretler için HTML yanıtını kaydediyor ve yalnızca içeriğin değişmediğini doğrulamak üzere sunucuyu çağırıyor. Bu işlem, temelde HTML kaynağının belirli bir sürümüne atanan bir tanımlayıcı olan HTTP ETag ile yapılır. İçerik hâlâ aynıysa sunucularımız tarafından istemciye gövde olmadan 304 Değiştirilmedi yanıtı gönderilir.
Ayrıca, bu değişiklik, HTML'mizin artık ziyaretçiye özel olmadığı ve çerez içermediği anlamına gelmektedir. Başka bir deyişle, temelde her yerde önbelleğe alınabilir. Bu sayede, dünya genelinde yüzlerce konumda coğrafi varlığı çok daha iyi olan CDN sağlayıcılarını kullanmaya başlayabilirsiniz.
DNS, SSL ve HTTP/2
Önbelleğe alma etkinleştirildiğinde bekleme süreleri azaldı ve ilk bağlantının diğer önemli kısımları da daha önemli hale geldi. Ağ altyapımızı ve izlemeyi geliştirmek DNS, bağlantı ve SSL sürelerimizi iyileştirmemizi sağladı.
Tüm kullanıcı alanları için HTTP/2 etkinleştirildi. Bu sayede, hem gereken bağlantı sayısı hem de her yeni bağlantıyla birlikte gelen ek yük azaltıldı. Bu, HTTP/2 ile birlikte gelen performans ve esneklik avantajlarından yararlanırken dağıtımı nispeten kolay bir değişiklikti.
Brotli sıkıştırması (gzip ile kıyaslandığında)
%21 - 25
Ortanca dosya aktarım boyutunun küçültülmesi
Geleneksel olarak, tüm dosyalarımız web'deki en yaygın HTML sıkıştırma seçeneği olan gzip sıkıştırması kullanılarak sıkıştırılırdı. Bu sıkıştırma protokolü ilk olarak neredeyse 30 yıl önce uygulanmıştır.
Yeni Brotli sıkıştırması, neredeyse hiçbir ödün vermeden sıkıştırma iyileştirmeleri sunmakta ve yıllık Web Almanağı Sıkıştırma bölümünde açıklandığı gibi giderek daha popüler hale gelmektedir. Bir süredir tüm popüler tarayıcılar tarafından desteklenmektedir.
Tüm istemciler için uçlarda nginx proxy'lerimizde Brotli desteğini etkinleştirdik.
Brotli sıkıştırma yöntemini kullanmaya geçiş yaparak ortalama dosya aktarım boyutlarımızı % 21'den%25'e azalttık. Bu sayede bant genişliği kullanımı azaldı ve yükleme süreleri kısaldı.
İçerik yayınlama ağları (CDN)
Dinamik CDN seçimi
Wix'te, tüm JavaScript kodunu ve resimlerini kullanıcı web sitelerinde sunmak için her zaman CDN'leri kullanırız.
Kısa bir süre önce, istemcinin ağına ve kaynağına göre en iyi performans gösteren CDN'yi otomatik olarak seçmek için DNS sağlayıcımızın sunduğu bir çözümü entegre ettik. Bu, statik dosyaları her ziyaretçi için en iyi konumdan sunmamızı ve belirli bir CDN'de kullanılabilirlik sorunlarını önlememizi sağlar.
Yakında... CDN'ler tarafından sunulan kullanıcı alanları
Bulmacanın son parçası, son ve en önemli kısmı bir CDN aracılığıyla sunmaktır: kullanıcı alanından gelen HTML.
Yukarıda açıklandığı gibi, siteye özgü HTML ve API sonuçlarını önbelleğe almak ve sunmak için kendi şirket içi çözümümüzü oluşturduk. Bu çözümü birçok yeni bölgede sürdürmenin işletme maliyetleri de var. Ayrıca yeni konumlar eklemek, yönetmemiz ve sürekli olarak optimize etmemiz gereken bir süreç haline geldi.
Şu anda sunucularımızın dünya genelindeki dağıtımını iyileştirmek ve yanıt sürelerini iyileştirmek amacıyla Wix sitesinin tamamının doğrudan CDN konumlarından sunulmasını desteklemek için çeşitli CDN sağlayıcılarıyla entegrasyon yapıyoruz. Bu, uçta SSL sonlandırma gerektiren çok sayıda alan adı sunduğumuz için büyük bir zorluk teşkil etmektedir.
CDN'lerle entegrasyon, Wix web sitelerini müşteriye her zamankinden daha yakın hale getirir ve yükleme deneyiminde herhangi bir ekstra çaba sarf etmeden HTTP/3 gibi yeni teknolojiler de dahil olmak üzere daha fazla iyileştirme sunar.
Performans izleme hakkında birkaç kelime
Bir Wix sitesi yönetiyorsanız bunun Wix site performansı sonuçlarınıza nasıl yansıdığını ve diğer web sitesi platformlarına kıyasla ne durumda olduğumuzu merak ediyor olabilirsiniz.
Yukarıda gerçekleştirilen işlerin çoğu geçen yıl dağıtılmıştır, bazıları ise hâlâ kullanıma sunulmaktadır.
HTTPArşiv'in sunduğu Web Almanağı, İYS kullanıcı deneyimi hakkında mükemmel bir bölüm içeren 2020 sürümünü kısa süre önce yayınladı. Bu makalede açıklanan rakamların çoğunun 2020 yılının ortasına ait olduğunu unutmayın.
2021'de güncellenmiş raporu görmeyi umuyor ve şirket içi performans metriklerimizin yanı sıra sitelerimiz için CrUX raporlarını aktif olarak izliyoruz.
Yükleme sürelerini sürekli iyileştirmeyi ve kullanıcılarımıza performanstan ödün vermeden düşündükleri web sitelerini oluşturabilecekleri bir platform sunmayı amaçlıyoruz.
DebugBear kısa süre önce, yukarıda bahsettiğim alanlardan bazılarına değinen ve her bir platformda derlenen çok basit sitelerin performansını inceleyen çok ilginç bir Web Sitesi Oluşturucu Performans İncelemesi yayınladı. Bu site yaklaşık iki yıl önce oluşturulmuş ve sonrasında değiştirilmemiştir. Ancak platform sürekli olarak iyileşmektedir ve bununla birlikte site performansı, geçtiğimiz bir buçuk yıldaki verilerini görüntüleyerek görünür.
Sonuç
Deneyimlerimizin, kuruluşunuzda performans odaklı bir kültür benimsemeniz için size ilham vermesini ve yukarıdaki ayrıntıların platform veya siteniz için yararlı ve uygulanabilir olduğunu umarız.
Özetlemek gerekirse:
- Sektör tarafından onaylanan araçları kullanarak sürekli olarak takip edebileceğiniz bir dizi metrik seçin. Core Web Vitals'ı öneririz.
- Tarayıcı önbelleğine alma ve CDN'lerden yararlanın.
- HTTP/2'ye (veya mümkünse HTTP/3'e) geçin.
- Brotli sıkıştırması kullanın.
Hikayemizi öğrendiğiniz için teşekkür ederiz. Sizi Twitter ve GitHub'da sorular sormaya, fikirlerinizi paylaşmaya ve favori kanallarınızda web performansı sohbetlerine katılmaya davet ediyoruz.