Yavaş sayfa yükü? Artık değil - Sunucu Tarafındaki İşlemenin Gücü

Web sitelerinin yavaş yüklenmesinden bıktınız mı? SEO ve teknoloji ekibiniz sonsuza dek sayfa hızı için doğru mimarinin ne olduğu hakkında tartışıyor mu? Bunları Pickyourtrail'de de yaptık ve bunun için bir çözümü daralttık.

JS uygulamaları web dünyasına başlatılmadan önce, HTTP çağrısına cevap olarak HTML iade edildi. Bu, statik bir HTML içerik dosyası oluşturularak ve bazen PHP, Python veya Java gibi sunucu tarafındaki dilleri kullanarak yanıtı onaylayarak ve buna daha etkili bir süreçte cevap vererek gerçekleştirildi. Bu nedenle, düşük sayfa hızı ve yarım sayfa yükleme gibi sorunlar devam etti. Çoğunlukla, bu davalar Müşteri Tarafındaki Rendering'in bir yan etkisi olmuştur.

Müşteri tarafı oluşturma nasıl çalışır?

Tamam, eğer teknik açıdan süpernova iseniz, renderleme kavramlarına aşina olduğunuzdan eminiz. Diğerleri için, işte açıklaman!

İstemci tarafı oluşturma, bir JS dosyasıyla birlikte HTML belgesinin web sitesinin geri kalanını tarayıcı kullanımıyla oluşturmasıdır. React gibi modern web çerçeveleri ile, tarayıcı java-script bağlantıları ile boş bir belge aldı ve ardından oluşturma başladı, böylece sayfa yükleme tutarsız hale geldi. İlk sayfa yükleme işlemi yavaş olacaktır ve ağ hızı kumar oynayabileceğimiz bir şey olmadığından, doldurulacak her yükleme için, içeriğin kullanıcıya gösterilmesinden önce sunucunun sonuna iki tur kadar yakın bir zaman alır. Fakat. akılda tutulması gereken şey şudur: İlk yükten sonra (daha uzun süreli yük) sonraki yükler süper hızlı olacaktır.

Daha da parçalamak:

1. Adım: Tarayıcı bir sayfa istiyor

Adım 2: Tarayıcı, JS’mizi ister

Adım 3: Uygulama önyüklemelerini yanıtlayın, arka uçtan veri ister

Adım 4: Ekranda yakalanan içerik

İlk sunucu isteği, dış dosyalar oluşturulmak üzere alınmadan önce boş bir HTML dosyası döndürür. Bu nedenle, tarayıcıların sayfayı boş olarak yorumlayabilmeleri için büyük bir olasılık vardır. Ayrıca, kullanıcılar için bekleme süresi, ilk oluşturma işlemi için daha uzun süre beklemeleri gerektiğinden daha fazla olacaktır.

Daha fazla bekleme süresi = Kullanıcılar ilgisini kaybeder ve sayfadan ayrılır

Ortalama seans süresinin düşük olması doğru değil mi?

Pickyourtrail'in Tek Sayfa Uygulaması (SPA) olması - Müşteri Tarafındaki Render (CSR) uygulamasıyla daha önce web sitemizi uygulamamız, yavaşlık ve tutarsız SEO performansı ile sonuçlandı. Buna ek olarak, sayfalarımızın meta başlıkları ve açıklamaları taranmadı, bu da sayfamız boyunca uygun olmayan bir şekilde gösteriliyordu.

Google, bu yılın başlarında sonuçlandırdıkları bir rapor yayınladı:

“Ortalama mobil açılış sayfasını tam olarak yüklemek için geçen ortalama süre 22 saniyedir. Ancak araştırmalar, insanların% 53'ünün yüklenmesi 3 saniyeden uzun sürerse mobil sayfadan ayrılacağını da gösteriyor. ”

Sunucu tarafı oluşturma nasıl çalışır?

Müşterilerin tercih ettiği faaliyetler gibi - makine öğrenmesi ve API'lerin kullanımıyla ürüne entegre faaliyetler, uçuşlar, oteller, transferler ve diğer temel unsurlar aracılığıyla yakalananlar gibi en büyük menfaatlerimiz var. Pickyourtrail sitemiz, Node konseptini kullanarak ön uçtaki React üzerine kuruludur. Ancak, yavaş sayfa yükleme sorunları nedeniyle bundan en iyisini alamadık.

‘Results Over Reasons’ ile temel değerlerimizden biri olduk. Yavaş sayfa efsanesine daha geniş bir perspektiften baktık ve sunucu tarafı sunumu üzerinde durduk.

Çözümler Pickyourtrail performans darboğazlarını belirlemek için geldi

  • Uygulamanın, tarayıcıların gerçek içeriği taraması için yeterince hızlı hale getirilmesi amacıyla CSR'yi optimize etmek.
  • Uygulamanın ilk işlenmesi için SSR uygulamak ve daha ileri etkileşimler için müşteri tarafı üzerinde hidrat oluşturmak.

Çoklu tartışmalardan ve A / B testlerinden sonra, Sunucu tarafı oluşturma (SSR) için yeşil bayrak salladık.

Sunucu tarafı oluşturma, bir kullanıcı veya bir arama motoru tarayıcısının ilk olarak tarayıcımızı talep etmesi ve ilk oluşturma işleminin başlatılmasıdır. Sunucu isteği aldığında, gerekli öğeleri bir HTML dizgisine getirir ve ardından müşteriye bir yanıt olarak atar. Daha sonra, web sitesinde farklı bir sayfayı ziyaret etmeyi seçerseniz, tarayıcınız yeni bilgileri almak için başka bir talepte bulunacaktır. Bu, bir sayfaya her basışınızda gerçekleşecek, tarayıcınızın önbelleğe alınmış bir çeşidi yok.

Yine, bunu okuyan bir teknoloji süpernova'sınız, bir sonraki bölüme geçmek isteyebilirsiniz. Ancak diğerleri için SSR’nin çalışması

  • Tarayıcı bir sayfa istiyor
  • Sunucu, React’i hafızaya yükler.
  • Sunucu gerekli verileri alıyor
  • Sunucu, React uygulamasını oluşturuyor
  • Sunucu, tarayıcıya oluşturulan HTML'yi gönderir
  • Tarayıcı / kullanıcı içeriği görüntüler
  • JS dosyasını çağırır
  • Uygulama açılışında tepki verir, arka uçtan veri ister
  • Uygulama ekranda yeniden işler (nemlendirir).

SSR uygulaması bize nasıl yarar sağladı?

  • İlk sayfa oluşturma için daha hızlı yükleme süresi
  • Tamamen endekslenebilir HTML sayfaları.
  • Müşterilerimiz için artan performans
  • SEO metriklerinde tutarlılık

En iyi haber şu ki, tarayıcılar artık web sitemizi web'deki diğer statik siteler gibi görecek ve sunucuda oluşturulan tüm içeriği dizine ekleyecektir. Artık kullanıcı JS'nin yüklenmesini beklemek zorunda değildir ve bunun yerine tamamen işlenmiş bir HTML alır.

Tam sayfa gösterimi sadece 7 saniyede, bekleme süresi 4 saniyeye düştü. Sihirli? Nah teknoloji;)

Önerilen çözümün bazı potansiyel tuzakları

Evet, burada dürüst olmak gerekirse! Çim her zaman diğer tarafta daha yeşil değildir: /

SSR, beklenen performans artışını sağlar ve içeriği geleneksel bir React Uygulaması kullanmaktan daha hızlı bir şekilde kullanıcılarımıza geçireceğimiz doğrudur. İşin püf noktası, ölçeklenebilir bir performans artışı değil.

SSR isteğinde, sunucu ve istemci neredeyse benzer şekilde çalışır. React'i çalıştırır, uygulamayı oluşturur ve HTML'yi tükürür. Ayrıca, React'in JSX kodunu HTML'ye dönüştürmek için kullandığı renderToString () yöntemi yavaş ve senkronizedir. Bu, sunucuyu daha fazla yük altına sokar ve sunucudan gelen ilk yanıt, geleneksel React App uygulamasından sonra planlanan HTML'den daha sonra gelir.

Uygulamanın ilk olarak, örneğin, "pencere" ve "belge" nin tanımlanmadığı bir Düğüm ortamında çalışacağından fazla dikkatli olmanız gerekir. Bunları `componentDidMount` dışında veya` if (typeof window! = 'Undefined') dışında kullanmaktan alıkoymalısınız.

Ancak SSR'nin neden olduğu karmaşıklıklara gümüş astar, Next.js. gibi aletlerle düzeltilebilecekleridir.

Pasta üzerine krema? - Artık sayfa yüklerimizi daha hızlı bir şekilde yapmakla kalmayıp, ekipler arasında bitmeyen tartışmalar da durdu. Yani bizim için tipik bir kazan-kazan durumu;)

Yalnızca teknik sorunları çözmekle kalmayıp, çözümünüzle ilgili müşteri geri bildirimlerini anında görebileceğiniz bir ekipte çalışmak ister misiniz? Gemide olmanı isteriz. E-postaları careers@pickyourtrail.com adresine bırakın, sizinle temasa geçelim. Ayrıca, seyahate çıkmayı bekleyen gezginler için Pickyourtrail'i ziyaret edin ve mutlu tatillerinizi planlamaya başlayın!