Wix'te, milyonlarca sitenin web sitesi yükleme performansını iyileştirmek ve bu sitelerin iyi PageSpeed Insights ve Core Web Vitals puanları almasını sağlamak için yapılan bazı önemli değişiklikleri içeren bir örnek olay.
Web sitemizin çalışma zamanında yapılan büyük bir yeniden yazma çalışmasının yanı sıra endüstri standartlarından, bulut sağlayıcılarından ve CDN özelliklerinden yararlanma sayesinde, CrUX ve HTTPArchive verilerine göre, tüm Core Web Vitals metriklerinde iyi bir 75. yüzdelik dilim puanına ulaşan Wix sitelerinin yüzdesi yıldan yıla üç kattan fazla arttı.
Wix, performans odaklı bir kültür benimsedi ve kullanıcılara daha fazla iyileştirme sunmaya devam edecek. Performans TPG'lerine odaklandığımızda, Core Web Vitals eşiklerini aşan sitelerin sayısının artmasını bekliyoruz.
Genel Bakış
Performans dünyası, birçok değişken ve ince ayrıntıyla güzel bir şekilde karmaşıktır. 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 hızlandırmaya daha fazla önem veriyor. Mayıs 2021'den itibaren sayfa deneyimi sinyalleri Google Arama sıralamasına dahil edilecek.
Wix'in karşılaştığı benzersiz zorluk, bazıları yıllar önce oluşturulmuş ve o zamandan beri güncellenmemiş milyonlarca siteyi desteklemektir. Kullanıcılarımızın sitelerinin performansını analiz edip iyileştirmek için neler yapabileceklerini öğrenmelerine yardımcı olacak çeşitli araçlar ve makalelerimiz mevcuttur.
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 sunar ancak aynı zamanda ölçek ekonomilerinden yararlanarak her alanda önemli iyileştirmeler yapma fırsatları da sunar.
Ortak bir dil konuşma
Performansla ilgili temel zorluklardan biri, hem teknik hem de algılanan performansı göz önünde bulundurarak kullanıcı deneyiminin farklı yönlerini tartışmak için ortak bir terminoloji bulmaktır. Kuruluş içinde iyi tanımlanmış, ortak bir dil kullanmak, farklı teknik parçaları ve değiş tokuşları kolayca tartışmamızı ve kategorize etmemizi sağladı, performans raporlarımızı netleştirdi ve öncelikle hangi yönleri iyileştirmeye odaklanmamız gerektiğini anlamamıza büyük ölçüde yardımcı oldu.
Tüm izleme ve şirket içi tartışmalarımızı, aşağıdakiler gibi sektör standardı metrikleri içerecek şekilde düzenledik: Web Vitals
Site karmaşıklığı ve performans puanları
Yalnızca HTML kullanarak çok basit bir site oluşturmanız ve bu siteyi bir CDN üzerinden yayınlamanız koşuluyla anında yüklenen bir site oluşturmak oldukça kolaydır.
Ancak gerçek şu ki siteler giderek daha karmaşık ve sofistike hale geliyor, dokümanlardan ziyade uygulamalar gibi çalışıyor ve bloglar, e-ticaret çözümleri, özel kod gibi işlevleri destekliyor.
Wix, kullanıcılarının birçok işletme özelliğine sahip bir siteyi kolayca oluşturmasını sağlayan çok çeşitli şablonlar sunar. Bu ek özellikler genellikle bazı performans maliyetleriyle birlikte gelir.
Yolculuk
Başlangıçta HTML vardı
Bir web sayfası her yüklendiğinde, HTML belgesini almak için her zaman bir URL'ye ilk istek gönderilir. Bu HTML yanıtı, sitenizi çalıştırmak ve oluşturmak için tüm ek istemci isteklerini ve tarayıcı mantığını tetikler. Yanıtın başlangıcı gelene kadar hiçbir şey gerçekleşmediğinden bu, sayfa yüklemenin en önemli kısmıdır (TTFB - ilk bayta kadar geçen süre olarak bilinir).
Geçmiş: istemci tarafı oluşturma (CSR)
Büyük ölçekli sistemleri çalıştırırken performans, güvenilirlik ve maliyet gibi her zaman dikkate almanız gereken değişkenler vardır. Wix, birkaç yıl öncesine kadar istemci taraflı oluşturma (CSR) kullanıyordu.Bu yöntemde asıl HTML içeriği, istemci tarafında (yani tarayıcıda) JavaScript aracılığıyla oluşturuluyordu. Bu sayede, büyük arka uç işletme maliyetleri olmadan çok sayıda siteyi destekleyebiliyorduk.
CSR, temelde boş olan ortak bir HTML belgesi kullanmamızı sağladı. Tek yaptığı, istemci cihazda tam HTML'yi oluşturmak için kullanılan gerekli kodun ve verilerin indirilmesini tetiklemekti.
Bugünkü konumuz: sunucu tarafı oluşturma (SSR)
Birkaç yıl önce, hem SEO hem de performans açısından faydalı olduğu için sunucu tarafı oluşturmaya (SSR) geçtik. Bu geçiş, ilk sayfa görünürlük sürelerini iyileştirdi ve JavaScript çalıştırma konusunda tam destek sunmayan arama motorları için daha iyi dizine ekleme sağladı.
Bu yaklaşım, özellikle yavaş cihazlarda/bağlantılarda görünürlük deneyimini iyileştirdi ve daha fazla performans optimizasyonuna kapı açtı. Ancak bu, her web sayfası isteği için anında benzersiz bir HTML yanıtının oluşturulduğu anlamına da geliyordu. Bu durum, özellikle çok sayıda görüntülemeye sahip siteler için optimum olmaktan çok uzaktı.
Birden fazla konumda önbelleğe alma özelliğini kullanıma sunuyoruz
Her sitenin HTML'si çoğunlukla statik olsa da birkaç istisna vardı:
- Sık sık değişir. Bir kullanıcı sitesini her düzenlediğinde veya site verilerinde (ör. web sitesi mağaza envanterinde) değişiklik yaptığında.
- Ziyaretçiye özel belirli veriler ve çerezler içeriyordu. Yani aynı siteyi ziyaret eden iki kullanıcı biraz farklı HTML görürdü. Örneğin, ziyaretçilerin sepete eklediği ürünleri hatırlama veya ziyaretçinin işletmeyle daha önce başlattığı sohbeti hatırlama gibi ürün özelliklerini desteklemek için.
- Tüm sayfalar önbelleğe alınamaz. Örneğin, özel kullanıcı kodu içeren ve dokümanın bir parçası olarak mevcut saati gösteren bir sayfa önbelleğe alınmaya uygun değildir.
Başlangıçta, HTML'yi ziyaretçi verileri olmadan önbelleğe alma konusunda nispeten güvenli bir yaklaşım benimsedik ve ardından her önbelleğe alma isabeti için her ziyaretçi için HTML yanıtının yalnızca belirli bölümlerini anında değiştirdik.
Kuruluş içi CDN çözümü
Bunu, şirket içinde geliştirilmiş bir çözümü dağıtarak yaptık: Vekil sunucu ve önbelleğe alma için Varnish HTTP Önbelleği, geçersiz kılma mesajları için Kafka ve bu HTML yanıtlarının vekil sunuculuğunu yapan ancak HTML'yi değiştiren ve önbelleğe alınan yanıta ziyaretçiye özgü veriler ve çerezler ekleyen Scala/Netty tabanlı bir hizmet kullandık.
Bu çözüm, bu ince bileşenleri dünyanın dört bir yanındaki daha fazla coğrafi konumda ve 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 sayfa görüntülemelerimizin önbelleğe alınmaya uygun olan% 90'ından fazlası için önbelleğe almayı kademeli olarak etkinleştirdik. Siteleri ek konumlardan yayınlamak, içeriği web sitesinin ziyaretçilerine yaklaştırarak istemciler ile HTML yanıtını sunan sunucular arasındaki ağ gecikmesini azalttı.
Ayrıca, aynı çözümü kullanarak ve site içeriğinde herhangi bir değişiklik olduğunda önbelleği geçersiz kılarak belirli salt okunur API yanıtlarını önbelleğe almaya başladık. Örneğin, sitedeki blog yayınlarının listesi, bir yayın yayınlandığında/değiştirildiğinde önbelleğe alınır ve geçersiz kılınır.
Karmaşıklığı azaltma
Önbelleğe alma özelliğini uygulamak, performansı özellikle TTFB ve FCP aşamalarında ö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'yi değiştirme ihtiyacı, gereksiz bir karmaşıklık oluşturuyordu. Bu karmaşıklık ortadan kaldırılırsa daha fazla performans iyileştirmesi yapma fırsatı elde edilebilirdi.
Tarayıcı önbelleğe alma (ve CDN'ler için hazırlıklar)
~ 13%
Doğrudan tarayıcı önbelleğinden sunulan HTML istekleri, çok fazla bant genişliği tasarrufu sağlar ve tekrar görüntülemelerin yükleme sürelerini kısaltır.
Sonraki adımda, ziyaretçiye özgü bu verileri HTML'den tamamen kaldırmamız ve HTML geldikten sonra istemci tarafından bu amaç için çağrılan ayrı bir uç noktadan almamız gerekiyordu.
Bu verileri ve çerezleri, her sayfa yüklendiğinde çağrılan ancak yalnızca tam sayfa etkileşime ulaşmak için etkinleştirme işlemi için gereken küçük bir JSON döndüren yeni bir uç noktaya dikkatlice taşıdık.
Bu, HTML'nin tarayıcıda önbelleğe alınmasını etkinleştirmemize olanak tanıdı. Bu sayede tarayıcılar artık tekrarlanan ziyaretler için HTML yanıtını kaydediyor ve yalnızca içeriğin değişmediğini doğrulamak için sunucuyu çağırıyor. Bu işlem, temel olarak bir HTML kaynağının belirli bir sürümüne atanan bir tanımlayıcı olan HTTP ETag kullanılarak yapılır. İçerik aynıysa sunucularımız, istemciye gövde içermeyen bir 304 Değiştirilmedi yanıtı gönderir.
Ayrıca bu değişiklik, HTML'mizin artık ziyaretçiye özel olmadığı ve çerez içermediği anlamına gelir. Başka bir deyişle, temel olarak her yerde önbelleğe alınabilir. Bu da dünya genelinde yüzlerce konumda çok daha iyi coğrafi varlığa sahip CDN sağlayıcıları kullanmanın önünü açar.
DNS, SSL ve HTTP/2
Önbelleğe alma etkinleştirildiğinde bekleme süreleri kısaltıldı ve ilk bağlantının diğer önemli bölümleri daha önemli hale geldi. Ağ altyapımızı ve izlememizi iyileştirmek, DNS, bağlantı ve SSL sürelerimizi iyileştirmemizi sağladı.
HTTP/2 tüm kullanıcı alanları için etkinleştirildi. Bu sayede hem gereken bağlantı miktarı hem de her yeni bağlantıyla birlikte gelen ek yük azaltıldı. Bu, HTTP/2 ile birlikte gelen performans ve dayanıklılık avantajlarından yararlanırken dağıtılması nispeten kolay bir değişiklikti.
Brotli sıkıştırması (gzip ile karşılaştırma)
21 - 25%
Ortalama dosya aktarma boyutunun azaltılması
Geleneksel olarak tüm dosyalarımız, web'de en yaygın HTML sıkıştırma seçeneği olan gzip sıkıştırma kullanılarak sıkıştırılıyordu. Bu sıkıştırma protokolü ilk olarak yaklaşık 30 yıl önce uygulandı.
Yeni Brotli sıkıştırması, neredeyse hiçbir ödün vermeden sıkıştırma iyileştirmeleri sunar ve yıllık Web Almanağı Sıkıştırma bölümünde açıklandığı gibi yavaş yavaş daha popüler hale gelmektedir. Bu özellik bir süredir tüm büyük tarayıcılar tarafından desteklenmektedir.
Brotli'yi destekleyen tüm istemciler için kenarlardaki nginx proxy'lerimizde Brotli desteğini etkinleştirdik.
Brotli sıkıştırma özelliğini kullanmaya başladığımızda, ortalama dosya aktarım boyutlarımız % 21 ila%25 oranında azalarak bant genişliği kullanımının azalmasına ve yükleme sürelerinin iyileşmesine neden oldu.
İçerik yayınlama ağları (CDN'ler)
Dinamik CDN seçimi
Wix'te, kullanıcı web sitelerindeki tüm JavaScript kodlarını ve resimleri yayınlamak için her zaman CDN'leri kullandık.
Yakın zamanda, 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 bir çözümüyle entegrasyon yaptık. Bu sayede statik dosyaları her ziyaretçi için en iyi konumdan sunabilir ve belirli bir CDN'deki kullanılabilirlik sorunlarını önleyebiliriz.
Yakında: CDN'ler tarafından sunulan kullanıcı alanları
Bu sürecin son ve en önemli parçası, CDN üzerinden son kısmı (kullanıcı alanındaki HTML) yayınlamaktır.
Yukarıda açıklandığı gibi, siteye özgü HTML ve API sonuçlarını önbelleğe almak ve yayınlamak için kendi şirket içi çözümümüzü oluşturduk. Bu çözümü çok sayıda yeni bölgede sürdürmenin de operasyonel maliyetleri vardır. Ayrıca, yeni konumlar eklemek, yönetmemiz ve sürekli olarak optimize etmemiz gereken bir süreç haline gelir.
Şu anda, sunucularımızın dünya genelindeki dağıtımını iyileştirmek ve böylece yanıt sürelerini daha da kısaltmak için Wix sitesinin tamamını doğrudan CDN konumlarından yayınlamayı desteklemek üzere çeşitli CDN sağlayıcılarla entegrasyon yapıyoruz. Bu, sunduğumuz çok sayıda alan nedeniyle, uçta SSL sonlandırması gerektiren bir zorluktur.
CDN'lerle entegrasyon, Wix web sitelerini müşterilere her zamankinden daha yakın hale getirir ve HTTP/3 gibi daha yeni teknolojiler de dahil olmak üzere yükleme deneyiminde daha fazla iyileştirme sağlar.
Performans izleme hakkında birkaç söz
Wix sitesi kullanıyorsanız bu durumun Wix sitenizin performans sonuçlarına nasıl yansıdığını ve diğer web sitesi platformlarıyla karşılaştırmamızı merak ediyor olabilirsiniz.
Yukarıda bahsedilen çalışmaların çoğu geçtiğimiz yıl kullanıma sunuldu. Bazıları ise kullanıma sunulmaya devam ediyor.
HTTPArchive tarafından yayınlanan Web Almanac, kısa süre önce içerik yönetim sistemi kullanıcı deneyimi hakkında mükemmel bir bölüm içeren 2020 baskısını yayınladı. Bu makalede açıklanan sayıların çoğunun 2020'nin ortasına ait olduğunu unutmayın.
2021'de güncellenmiş raporu görmeyi heyecanla bekliyoruz ve sitelerimizle birlikte dahili performans metriklerimiz için CrUX raporlarını etkin bir şekilde izliyoruz.
Yükleme sürelerini sürekli olarak iyileştirmeye ve kullanıcılarımıza performanstan ödün vermeden hayallerindeki siteleri oluşturabilecekleri bir platform sunmaya kararlıyız.
DebugBear kısa süre önce, yukarıda bahsettiğim alanlardan bazılarını ele alan ve her platformda oluşturulan ç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şturuldu ve o zamandan beri değiştirilmedi. Ancak platform sürekli olarak gelişiyor ve site performansı da onunla birlikte gelişiyor. Bu durum, son bir buçuk yıl içindeki verilerine bakarak görülebilir.
Sonuç
Tecrübemizin, kuruluşunuzda performans odaklı bir kültür benimsemenize ilham vermesini ve yukarıdaki ayrıntıların platformunuz veya siteniz için yararlı ve uygulanabilir olmasını umuyoruz.
Özetlemek gerekirse:
- Sektör tarafından desteklenen araçları kullanarak tutarlı bir şekilde izleyebileceğiniz bir metrik grubu seçin. Core Web Vitals'ı öneririz.
- Tarayıcı önbelleğe alma ve CDN'lerden yararlanın.
- HTTP/2'ye (veya mümkünse HTTP/3'e) geçin.
- Brotli sıkıştırmasını kullanın.
Hikayemizi öğrendiğiniz için teşekkür ederiz. Twitter ve GitHub'da soru sormaya, fikirlerinizi paylaşmaya ve en sevdiğiniz kanallarda web performansı konulu sohbetlere katılmaya davet ederiz.