Da 11’e 4 saniyeye: Render Free Tier ile bir sitenin hızını nasıl optimize ettim

İlk Aşamalar

Pazartesi sabahı. Normale bir 4G bağlantısıyla web sitemi açıyorum. Zihnimde zaman tutuyorum. Bir, iki, üç… dokuz… on bir saniye. On bir saniye, ana sayfanın kullanılabilir olması için gereken süre.

Ne denir ki, herhangi bir rekora imza atabilirim.

Sonuçta ücretsiz bir render ve ücretsiz bir veritabanı kullanıyorum. Kalitenin bir bedeli var, bunu biliyoruz.

Asıl problem, benim gibi her şeye alışkın olan nerdlerin sabrı değil. Sorun, Google’da “özelleştirilmiş yazılım” arayan bir müşterinin benim siteme tıklayıp, ilk üç saniyede güvenilir olup olmadığımı değerlendirip, eğer site yavaşsa hemen sekmeyi kapatması. Ben aslında bir fırsatı kaybettim, bunu dahi fark etmedim.

Müşteri yavaşlığın nedenini bilmiyor, ben biliyorum. Bu web uygulamasının arkasında, Wix benzeri bir sayfa oluşturma sistemi var, bu da veritabanının yalnızca birkaç string ve birkaç FK ile yüklenmediği, aksine karmaşık bir payload gönderdiği anlamına geliyor.

Google’ın araştırmalarından biliyoruz ki kullanıcıların %50’sinden fazlası, yüklenmesi üç saniyeden fazla süren bir sayfayı terk ediyor. Ayrıca hız, üst sıralarda yer almanın onaylanmış bir faktörüdür. Yine de en az bir yerde hepimizin on bir saniyelik bir sitesi var; benimki de onlardan biriydi.

Ne Yapmaya Karar Verdım

Yeniden tasarım değil. Yeni grafik değil. Yeni teknoloji değil.

Gözlemlemek istediğim çok spesifik bir şey vardı: Neden nispeten basit, düzgün yazılmış bir site bu kadar yavaş olabiliyor?

Bazı insanlar bunun, ayda 7 veya 24 Euro harcamaktan kaçındığım için olduğunu düşünebilir. (Aslında doğru, neden bir VPS alıp her şeyi benim için barındırmayayım ki?).

Ama durum sadece bu değil. Benim için bu bir meydan okuma haline geldi.

Ücretsiz bir veritabanı ve 0.1 CPU’ya sahip bir sunucuda bir sistemi optimize etme isteği.

Bu, “Başardım, çünkü imkansızı optimize ettim” demenin verdiği bir heyecan.

Bir kural koydum. Hiçbir sezgi yok. Sadece sayılar.

Tarayıcı geliştirme araçlarını açtım, her isteği ölçtüm, ne kadar zaman geçtiğini hesapladım. Hiçbir kod satırına dokunmadan önce aynı ölçümü yaptım ve her müdahale sonrasında tekrarladım. Önce ve sonra ölçüm olmadan optimize edilmez; tahmin yürütmek gerekir.

Bulduğum Şeyler

Üç Suçlu, Her Biri Bağımsız

İlk suçlu, sunucunun kodu nasıl yorumladığıdır. Varsayılan olarak, her istek, günün ilk isteğiymiş gibi sıfırdan başlar. Sunucunun daha önce yaptığı işleri hatırlamasını sağlayan bir kısayol vardır, ancak standart yapılandırmada bu kapalıdır. Bu, her yeşil ışıkta el frenini çekip bekleyen bir arabaya benziyor.

İkincisi, sitenin veritabanından gösterilecek bilgileri nasıl talep ettiğidir. Üç seviyeli bir menüyü oluşturmak için, site her bir başlık için veritabanına bir soru sorar, ardından her alt başlık için tekrar bir soru sorar ve bu şekilde devam eder. Sonuç: Bunun yerine, iyi formüle edilmiş tek bir sorunun yeterli olacağı yerde onlarca soru sorulmaktadır.

Üçüncüsü, tarayıcının yüküydü. Site, görünen sayfanın sadece onda birini kullanan butonlar, simgeler, metin editörlerinin kodunu yüklüyordu. Bu, markete süt almak için her seferinde barbekü, aşçının motosikleti ve tüm tencere koleksiyonunu yanınıza almanız kadar abes.

Üç Problem, Üç Müdahale

Değişiklikleri Anlatmak

Sunucunun “kısa süreli hafızasını” açtım ve karmaşık bir caching sistemi kurdum. Site, bir isteğe yanıt verdiğinde, yaptığı işi hatırlar. Sonraki istekler %60’lık bir mesafeden başlar.

Tarayıcının yükünü azalttım: Artık site, sadece gördüğünüz sayfada gerekli olan öğeleri yüklüyor, tıpkı telefonunuzda bir uygulamayı açtığınızda olduğu gibi. Sayfa ziyareti başına yüklenecek dosya sayısını 519’dan 247’ye düşürdüm. Yüzde elliden fazla bir azalma.

Ve yan müdahaleleri de ekledim. Görseller artık, görünür kalite açısından %40 daha düşük ağırlıkta modern bir formatta iletiliyor. Tarayıcı, değişmeyen her şeyi yerel ön belleğe almak için talimat alıyor, böylece bir kullanıcının ikinci ziyareti sırasında birçok dosya sunucudan bile talep edilmiyor.

Sonuçlar, süslü kelimeler olmadan:

Önce: 11,5 saniye yüklenme süresi. 519 istek. 1,84 megabayt trafik.

Sonra: 4 saniye yüklenme süresi. 247 istek. 1,6 megabayt trafik.

Yüklenme süresi %65 azaldı. İstekler %52 azaldı. Bunlar, gerçek bir blog makalesinde, temiz bir tarayıcıda, üretimde ölçülen sayılardır. Bu, bir “en iyi senaryo” değil; herhangi bir ziyaretçinin gerçekliği.

Dört saniye, hala istediğim değer değil. Hedefim, bir buçuk saniyenin altında. Ancak on bir saniyeye göre çok daha iyi bir noktadayım ve bu durumun zıplama oranına etkisini önümüzdeki otuz gün boyunca analiz ederek göreceğim.

Neden Hızlı Bir Site Teknik Bir Detay Değildir

Üç Neden, Her Bir Stakeholder için

Kimler için satıcıysa, hızlı bir site gizli bir vaat taşır: “bu şirket titizlikle çalışıyor” der. Fiyat aralıklarında iki tedariçinin bulunduğu bir durumdaysanız ve biri üç saniyede yükleniyorsa diğeri on saniyede, hangi “teklif isteme” butonuna tıklarsınız?

Pazarlama metriklerini görüntüleyenler için hız, iki numarada doğrudan bir etkiye sahiptir. Birincisi, Google’daki konumdur: Core Web Vitals, yıllardır resmi sıralama faktörlerinin bir parçasıdır. Hızlı bir site yükselir, yavaş bir site düşer. İkincisi, dönüşüm oranıdır: yüklenme sürelerinde her kazanılan saniye, Amazon ve Walmart’ın kamu verilerinde daha yüksek satış yüzdelerine dönüşüyor.

Altyapıyı yönetenler için, optimizasyon aynı zamanda daha az ödeme yapmayı da ifade eder.

Daha Az Çalışan Sunucular, Daha Az Trafik, Daha Az Alan Kaplayan Görseller

Bu, P&L’de görülmeyen bir maliyet kalemidir, ancak baktığınızda tasarruf edebileceğinizi anlarsınız.

Kalan darboğaz

Dürüst olayım: mevcut 4 saniyenin yaklaşık 3’ü sunucunun yanıt üretmesine gider. Sadece 1 saniye gerçek indirme ve görüntüleme süresidir. Bu, bir sonraki optimizasyon turunun artık frontend üzerinde değil, backend neden 3 saniye sürdüğünü anlamakla geçeceği anlamına gelir.

Artık ölçüm yapmak için araçları kurdum. Sayıları elde ettiğimde, bu hikayenin ikinci bölümünü yazacağım, tam olarak buradaki gibi önce ve sonra ile.

Bu makaleden ne çıkarıyorsunuz?

Eğer sitenizin hızıyla hiç ilgilenmediyseniz, bu gün yapın. pagespeed.web.dev‘e girin, ana sayfanızın URL’sini yapıştırın ve puanı okuyun. Yeşil ise, tebrikler. Sarı veya kırmızı ise, elinizde somut bir araç var: ölçülebilir bir başlangıç noktası ve sitenizi yönetenle konuşulacak bir konu.

Eğer sayılardan memnun değilseniz ve bağımsız bir denetim istiyorsanız, iletişim formu aracılığıyla benimle iletişime geçin.

Özelleştirilmiş projelerde, daima gerçek verilere göre çalışırım ve asla gösterişli metriklere dayanmam.

İkinci bölüm, backend’deki üç saniyeyi de aştığımda gelecek. Bizi izlemeye devam edin.

👉 Tam makaleyi iadicola.it’de okuyun