Önemli Olan Yavaş Sayfa Ana Sayfa Değildir

Özet

Patronunuz web sitesinin yavaş olduğunu söylediğinde, içgüdüsel olarak görselleri sıkıştırmaya ve ana sayfadan özür dilemeye başlarsınız. Daha faydalı hareket, hangi sayfayı hızlandırmanın gerçekten değerli olduğuna karar vermektir. Bu makale tek bir senaryoyu ele alıyor: Orta ölçekli bir B2B sitesi için "hızı düzeltmesi" istenen küçük bir pazarlama ekibi. Saha verileriyle Core Web Vitals ölçümünü, iş etkisine göre sayfa seçimini ve ucuz düzeltmelerden sonra yapılandırılmış veri eklemeyi kapsar. Sonuç, teknik bilgisi olmayan bir patrona mantıklı gelen kısa ve savunulabilir bir plandır.

Web sitenizdeki en yavaş sayfa, PageSpeed Insights'ın işaret ettiği sayfa değildir. Patronunuzun hiç açmadığı sayfadır—ücretli bir kampanyayla bağlantılı olan veya unutulmuş bir ürün bölümünde gömülü olan—ve bu ayki bütçenin bir şey üretip üretmediğini asıl belirleyen sayfadır. Üst düzey biri "site yavaş, düzeltin" dediğinde, bir web sitesi hızlandırma projesine ihtiyaç duymaz. Bir önceliklendirme çalışmasına ihtiyaç duyar.

Birçoğumuzun yaşadığı bir senaryoyu ele alalım. Orta ölçekli bir B2B yazılım şirketinin tüm pazarlama ekibisiniz. Sitede bir ana sayfa, bir blog, bir yardım merkezi ve belirli reklam kampanyalarına bağlı beş açılış sayfası var. Patronunuz Core Web Vitals hakkında bir makale okudu veya bir müşteri şikayeti duydu. Talimat açık: daha hızlı yapın.

Önümüzdeki saatte nasıl yanıt verdiğiniz, önümüzdeki ayı görselleri sıkıştırarak mı yoksa önemli olan sayıları değiştiren işler yaparak mı geçireceğinizi belirler.

Kazandıran sayfayla başlayın, utandıran sayfayla değil

İlke: hız çalışmasının bir getirisi vardır ve bu getiri trafiğe ve dönüşüm değerine bağlıdır. Düşük trafikli ancak yüksek dönüşümlü bir sayfa, ana sayfadan daha yavaş olsa bile işletme için daha önemli olabilir.

Bu yüzden ilk hareket, site haritasından değil analitikten bir sayfa listesi oluşturmaktır. Hangi sayfalar reklam tıklamaları şeklinde para alıyor? Hangi sayfalara lansmandan bu yana dokunulmadı? Bu senaryoda, iki aydır yayında olan ücretli bir arama reklamının arkasındaki en önemli açılış sayfası, büyük ve optimize edilmemiş ekran görüntüleriyle oluşturulmuştu. Ana sayfa ise bir yıl önce bir ajans tarafından optimize edilmişti.

Önce ana sayfayı düzeltmezsiniz. Para kazandıran sayfayı düzeltirsiniz. Bu teknik bir seçim değil, iş seçimidir. Tam bir teknik denetim doğru yanıt gibi görünüyorsa, bir an için direnin. Denetimler bir liste üretir; hangi maddeyle başlayacağınızı söylemezler. İyi kapsamlandırılmış bir teknik SEO denetimi bir karar aracıdır, panik tepkisi değil.

Çoğu zaman, az sayıda sayfanın trafiğin ve dönüşümlerin büyük kısmını ürettiğini; geri kalanının bilgilendirici veya kalıntı olduğunu görürsünüz. Bu, yavaş bilgilendirici sayfaları sonsuza dek görmezden gelmek için bir neden değildir. Onları gelirle doğrudan bağlantısı olan sayfalardan sonra sıralamak için bir nedendir. Ana sayfa hepsinden yavaş olabilir, ancak iş hedefi müşteri adaylarıysa, ana sayfa ziyareti sadece bir başlangıç noktasıdır—birinin gerçekten dönüşüm yaptığı yer açılış sayfasıdır.

"Hızlı"yı "ölçülen" ve "hissedilen" olarak ayırın

İkinci adım, performans testlerinin sayfanız hakkında söylediklerini gerçek kullanıcıların deneyimlediklerinden ayırmaktır. Google'ın Core Web Vitals belgeleri, arama sıralamalarına dahil edilen üç metriği adlandırır: En Büyük İçerikli Boya (yükleme), Sonraki Etkileşime Kadar Geçen Süre (yanıt verebilirlik) ve Kümülatif Düzen Kayması (görsel stabilite). Bunlar önemlidir çünkü birinin sayfayı gerçekten kullanıp kullanamayacağını etkileyen anları izlerler.

Senaryoda, açılış sayfasını bir performans test cihazında açarsınız ve makul bir puan alırsınız. Ancak bunu Google Search Console'daki saha verileriyle—ziyaretçilerin gerçek deneyimlerini yansıtan—karşılaştırdığınızda, sayfanın sık sık yavaş olduğu ortaya çıkar. Önemli olan sinyal budur. Laboratuvar testleri, bir değişiklikten sonra önceki ve sonraki karşılaştırmak için hâlâ kullanışlıdır. Ancak saha verileri, reklamınızı çeşitli cihaz ve bağlantılardan tıklayan insanlar için gerçeğin ta kendisidir.

Bunun yerine	Bununla başlayın	Neden
PageSpeed puanı tek bir sayı olarak	Core Web Vitals saha verileri	Saha verileri test sunucusundan değil gerçek kullanıcılardan gelir
"Site yavaş"	Hangi sayfalar iş hedeflerini destekliyor	Hızlı işe yaramaz sayfalar müşteri adayı üretmez
CMS'i yeniden oluşturun	Görselleri sıkıştırın ve betikleri temizleyin	Düşük riskli düzeltmeler faydanın çoğunu sağlar

Daha sonrası için daha derin bir referans isterseniz, bir Core Web Vitals rehberi her metriği adım adım anlatabilir. Ama şimdilik planı oluşturmak için yeterli bilgiye ihtiyacınız var. Önemli olan, üç metrikten hangisinin o belirli sayfada gerçekten soruna neden olduğunu adlandırmaktır. Metin geç görünüyorsa, görsellere ve sunucu yanıtına bakın. Düğmeler takılıyormuş gibi hissediliyorsa, uzun JavaScript görevlerine bakın. Düzen atlıyorsa, reklamlar ve gömmeler için ayrılmış alanlara bakın. Bu nüans, hedefli bir düzeltmeyi rastgele bir optimizasyondan ayıran şeydir.

Pahalı şeylerden önce ucuz şeyleri düzeltin

Üçüncü ilke: bir performans projesinin yeniden tasarıma dönüşmesine izin vermeyin. Kullanıcı deneyimini gerçekten etkileyen iyileştirmelerin çoğu gösterişsiz ve ucuzdur.

Açılış sayfasına bakın ve bariz sorunluları adlandırın. Görseller tam çözünürlüklü ekran görüntüleri. Sayfada artık kimsenin tanımlayamadığı bir üçüncü taraf betiği var. Bir web yazı tipi metnin işlenmesini engelliyor. Bunlar tanıdık sorunlardır.

Mükemmel bir dünyada, sayfayı modern bir çerçeveyle yeniden yazmak için bir hafta harcarsınız. Pratikte, yarım günlük görevlerle başlarsınız: görselleri sıkıştırın, kullanılmayan betiği erteleyin, kahraman görselini önceden yükleyin. Bu değişiklikleri bir öğleden sonra test edebilirsiniz ve onay komitesi gerektirmezler.

Uyarı: hız her zaman bu kadar basit değildir. Bazı sayfalar, kontrol edemediğiniz bir sunucu, veritabanı veya üçüncü taraf bağımlılığı nedeniyle yavaştır. Ancak ucuz düzeltmeleri kontrol etmediyseniz, pahalı olanı henüz haklı çıkaramazsınız. Birçok ekip, ekran görüntülerini asla sıkıştırmadıkları için yeniden yapıma bütçe harcar. Burada korumaya değer bir alçakgönüllülük var: bir performans puanı bir semptomdur, teşhis değil. Ucuz düzeltmeler kendi başlarına teşhis niteliğindedir. Görselleri sıkıştırdıktan sonra, darboğazın içeriğiniz mi yoksa altyapınız mı olduğunu öğrenirsiniz.

Zaten kodun içindeyken yapılandırılmış veri ekleyin

Bu, patronu şaşırtan katmandır. Ucuz düzeltmeleri yaptıktan sonra, zaten sayfanın içindesiniz. Hızla ilgisi olmayan bir şey eklemek için doğru an budur: yapılandırılmış veri.

Yapılandırılmış veri, arama motorlarının bir sayfanın ne içerdiğini anlamasına yardımcı olan işaretlemedir. Daha zengin arama sonuçlarına ve daha iyi görünürlüğe yol açabilen aynı HTML'dir—ve arama, yapay zeka tarafından üretilen yanıtlara kaydıkça giderek daha alakalı hale geliyor. Küçük bir ekip için bu, yeni içerik yazmayı gerektirmediği için az kullanılan bir kaldıraçtır. Zaten var olanı etiketliyorsunuz.

Senaryoda, açılış sayfasına hizmet odaklı bir şema eklersiniz. Tam tür, sayfanın ne hakkında olduğuna bağlıdır: bir hizmet sayfası, bir makale, bir ürün. Her türü aynı anda eklemeniz gerekmez. Bir tanesini dikkatlice eklemek, on tanesini özensizce eklemekten daha iyidir. Hiçbir sonuç garanti değildir; Google ne görüntüleyeceğine karar verir. Ancak risk düşük ve potansiyel fayda gerçektir. Daha derine inmeye karar verirseniz, bir yapılandırılmış veri uygulama rehberi pratik adımları kapsar.

Düzeltmeleri "para kazandırdı mı?" şeklinde çevirin

Zor olan teknik iş değil. Bunu teknik bilgisi olmayan bir patrone sunma şekliniz.

Patronunuz tek bir şey istedi: siteyi daha hızlı yapmak. "Açılış sayfasında LCP'yi iyileştirdik" derseniz, boş bir bakış alabilirsiniz. Bunun yerine, işi iş sonuçlarına çevirin.

Bu senaryoda, açılış sayfası ücretli bir kampanyanın hedefidir. Beklenen her saniye, harekete geçirici mesaj görünmeden önce ziyaretçinin ayrılabileceği bir saniyedir. Yani açıklarsınız: paranın el değiştirdiği sayfadaki bariz sürtünmeleri kaldırdık. Belirli bir sıralama sıçraması vaat edemezsiniz—bunu yapan herkes tahmin yürütüyordur—ancak makul ve dürüst bir argüman sunabilirsiniz. Bunu, patronunuzun zaten anladığı bütçeye de bağlayabilirsiniz. Aynı reklam harcaması bir ziyaret satın alır; fark, bu ziyaretin müşteri adayı olma şansına sahip olup olmamasıdır.

Jargon yoğun bir gösterge panelinden ziyade basit bir aylık rapor daha iyi çalışır. Üç şeyi gösterin: hangi sayfayı seçtiğinizi, hangi metriği ölçtüğünüzü ve neyi değiştirdiğinizi. Metrik iyileşirse, bu doğrulamadır. İyileşmezse, yeniden değerlendirmek için hâlâ net bir deneyiniz var. Tek bir puanı aydan aya kovalamayın; Core Web Vitals trafik karışımı, cihaz türleri ve hatta coğrafi bölgeyle dalgalanır. Eğilimi bildirin, sayıyı değil.

Gelecek Pazartesi ne yapmalı

Senaryodan alınan ders: "web sitesini" düzeltmezsiniz. Verilere dayanarak belirli bir sayfayı düzeltirsiniz ve tek seferlik bir proje yerine tekrarlanabilir bir süreçle bitirirsiniz. Güç sahibi biri "daha hızlı yap" dediğinde, en yararlı yanıt tek bir açıklayıcı sorudur: hangi sayfa ve kimin için?

Ardından saha verilerini ölçün, ucuz şeyleri düzeltin, zaten kodun içindeyseniz yapılandırılmış veri ekleyin ve sade bir dille raporlayın. Sonuçlar dramatik olmayabilir. Ancak hangi sayfanın neden hızlandığını, onu neden seçtiğinizi ve sırada ne yapacağınızı tam olarak bileceksiniz. Bu, bir hız puanıyla başlayıp kimsenin anlamadığı bir yeniden tasarımla biten belirsiz bir projeden daha iyi bir çıktıdır.