Bir Çevrimiçi Mağazanın Performansını İyileştirme (Örnek Olay)

Her ön uç geliştirici, aynı kutsal performans kasesinin peşindedir: Google Page Speed'de yeşil puanlar. İyi yapılmış işlerin somut işaretleri her zaman takdir edilir. Ancak kâse avı gibi, bunun gerçekten aradığınız yanıt olup olmadığını sorgulamanız gerekir. Kullanıcılarınız için gerçek hayattaki performans ve siteyi kullandığınızda web sitesinin nasıl "hissettirdiği", Sayfa Hızında size bir veya iki puana mal olsa bile, indirim yapılmamalıdır (aksi takdirde, hepimizin yalnızca bir arama çubuğu olur ve stilini değiştirmezdik). Metin).

Küçük bir dijital ajansta çalışıyorum ve ekibim çoğunlukla büyük kurumsal web sitelerinde ve mağazalarda çalışıyor - bir noktada sayfa hızı tartışmaya giriyor, ancak genellikle o zamana kadar cevap, gerçekten herhangi bir şeyi başarmak için büyük bir yeniden yazmanın gerekli olacağıdır. şirketlerde büyüklük ve proje yapısının talihsiz bir yan etkisi.

Mücevher kutusu ile çevrimiçi mağazasında çalışmak, bizim için hoş bir tempo değişikliği oldu. Proje, mağaza yazılımını kendi açık kaynak sistemimize yükseltmekten ve mağazanın ön ucunu sıfırdan yeniden yapmaktan oluşuyordu. Tasarım, HTML prototipini de (Bootstrap 4'e dayalı olarak) işleyen bir tasarım ve UX ajansı tarafından yapıldı. Oradan, onu şablonlara dahil ettik - ve bir kez olsun, web sitesinin performansına takıntılı bir müşterimiz oldu.

Lansman için, çoğunlukla yeni tasarımın kapıdan çıkarılmasına odaklandık, ancak web sitesinin yeniden başlatılması yayınlandığında, dikkatimizi kırmızı ve turuncu puanları yeşile çevirmeye odaklamaya başladık. Hangi optimizasyonların izlenmeye değer olduğu konusunda pek çok tartışmanın olduğu, zor kararlarla dolu çok aylı bir yolculuktu . Bugün, web sitesi çok daha hızlı ve çeşitli vitrin ve karşılaştırmalarda üst sıralarda yer alıyor. Bu yazıda yaptığımız işlerden bazılarını ve hızımıza nasıl ulaştığımızı anlatacağım.

Çevrimiçi Mağazalar Biraz Farklı

Ayrıntılara girmeden önce kısa bir süreliğine online mağazaların diğer birçok web sitesinden farkı hakkında konuşalım (bunu zaten biliyorsanız, bir sonraki bölümde sizinle buluşacağız). Bir e-ticaret sitesinden bahsettiğimizde, sahip olacağınız ana sayfalar:

• ana sayfa (ve "içerik" sayfaları),
• kategori ve arama sayfaları,
• ürün detay sayfaları,
• sepet ve ödeme (belli ki).

Bu yazı için ilk üçüne ve bunların performans ayarlamalarına odaklanacağız. Ödeme kendi canavarıdır. Orada fiyatları hesaplamak için çok fazla JavaScript ve arka uç mantığına ve ayrıca uygun nakliye sağlayıcısını almak için birkaç servis çağrısına ve sevk edilen ülkeye dayalı fiyat tahminlerine sahip olacaksınız.

Bu, fatura ve sevkiyat adreslerini kaydetmeniz gereken form alanlarının doğrulanmasına ek olarak açıktır. Buna ödeme sağlayıcısı açılır listesini ekleyin ve uygun şekilde test edildikten ve çalıştıktan sonra kimsenin dokunmak istemeyeceği bazı sayfalarınız olur.

Bir çevrimiçi mağaza hayal ettiğinizde aklınıza ilk gelen şey nedir? Görseller — çok sayıda ürün görseli. Temelde her yerdeler ve tasarımınıza hakim olacaklar. Ayrıca, insanların sizden satın almasını sağlamak için birçok ürün göstermek isteyeceksiniz - yani bir atlıkarınca. Fakat bekle! İnsanlar içindeki ürünlere tıklıyor mu? Atlıkarınca üzerine biraz takip koyarak öğrenebiliriz. Takip edersek, optimize edebiliriz! Ve aniden, sayfalarımızda yapay zeka destekli harici ürün karuselleri ortaya çıktı.

Mesele şu ki, bir atlıkarınca, daha fazla satış çekme umuduyla daha fazla ürün sergilemek için sayfaya eklediğiniz son hız cezalandırıcı unsur olmayacak. Elbette, bir mağazanın ürün görseli yakınlaştırma, bazı videolar, bugünün son teslim tarihine geri sayım veya müşteri desteğiyle iletişime geçmek için bir sohbet penceresi gibi etkileşimli öğelere ihtiyacı vardır.

Tüm bunlar, dönüşümleri doğrudan gelir olarak ölçtüğünüzde çok önemlidir. Ayrıca, her birkaç ayda bir, ekipten biri eklenebilecek bazı harika yeni işlevler görecek ve böylece, onu yalın tutmak için en iyi niyetle başlamış olsanız bile, karmaşıklık ve JavaScript birikmeye başlayacak.

Ve genellikle bir makalenin tam sayfasını önbelleğe alabilseniz de, aynı şey birçok mağaza sayfası ve öğesi için geçerli değildir. Başlıktaki veya istek listesindeki alışveriş sepeti gibi bazıları kullanıcıya özeldir ve verilerin kişisel doğası gereği hiçbir zaman önbelleğe alınmamalıdır. Ek olarak, fiziksel mallarınız varsa, canlı envanter ile uğraşıyorsunuz: Özellikle Noel telaşı sırasında, envanter bilgilerinin kesin ve güncel olması için ihtiyacınız olacak; bu nedenle, sunucu tarafı oluşturma sırasında sayfanın bölümlerini önbelleğe almanıza ve her şeyi yeniden birleştirmenize olanak tanıyan daha karmaşık bir önbelleğe alma stratejisine ihtiyacınız olacak.

Ancak planlama aşamalarında bile tuzaklar sizi bekliyor. Bir tasarımda - ve genellikle prototip aşamasında - incelikle hazırlanmış ürün adları ve açıklamaları, neredeyse aynı uzunlukta ve ideal ürün resimleriyle çalışacaksınız. Harika görünüyorlar! Tek sorun? Gerçekte, ürün bilgilerinin uzunluğu çok farklı olabilir ve bu da tasarımınızı bozabilir. Birkaç bin ürünle her birini kontrol edemezsiniz.

Bu nedenle, tasarımcıların veya prototip testini yapan kişilerin, tasarımın hala uygun olduğundan emin olmak için çok kısa ve çok uzun dizelerle yardımcı olur. Benzer şekilde, bilgilerin HTML'de bir kez masaüstü ve bir kez mobil için olmak üzere iki kez görünmesi bir mağaza için çok büyük bir sorun olabilir - özellikle ürün ayrıntıları, alışveriş sepeti veya bir ürün kategorisindeki filtrelerin özellikleri gibi karmaşık bilgilerse sayfa. Bunları senkronize halde tutmak zordur - bu yüzden lütfen bir geliştirici arkadaşınıza yardım edin ve bunu yapmayın.

Asla sonradan düşünülmemesi ve prototip aşamasından itibaren dahil edilmesi gereken başka bir şey de erişilebilirliktir. Bir işleve sahip tüm resimler ve simgeler için alternatif metne sahip olmaktan, renk kontrastına, hangi ARIA niteliklerinin nerede kullanılacağını (ve ne zaman kullanılmayacağını) bilmeye kadar, çeşitli araçlar size bazı temel konularda yardımcı olabilir. Bunu baştan dahil etmek, daha sonra olduğundan çok daha kolaydır ve herkesin üzerinde çalıştığınız web sitesinin keyfini çıkarmasını sağlar.

İşte size bir ipucu: İnsanların ekran okuyucu kullandığını veya yalnızca klavyeyle gezindiğini görmediyseniz, bununla ilgili videoları YouTube'da kolayca bulabilirsiniz. Bu konulardaki anlayışınızı değiştirecektir.

Performansa dönüş: Bir mağazanın performansını tekrar iyileştirmek neden bu kadar önemlidir? Açık cevap, insanların sizden satın almasını istediğinizdir . Bunu etkilemenin birkaç yolu var ve web sitenizin hızı çok büyük. Araştırmalar, yükleme süresinin her bir saniyesinin dönüşüm oranı üzerinde önemli bir etkisi olduğunu gösteriyor. Ek olarak, sayfa hızı, arama ve Google Reklamlarınız için bir sıralama faktörüdür. Bu nedenle, performansın iyileştirilmesi, alt satırda somut bir etkiye sahip olacaktır.

Yaptığımız Pratik Şeyler

Bazı performans darboğazlarını belirlemek kolaydır, ancak kapsamlı bir iyileştirme, birçok virajlı ve uzun bir yolculuktur. Kaynakların önbelleğe alınmasını yeniden kontrol etmek, neleri önceden getirebileceğimizi veya eşzamansız olarak yükleyebileceğimizi görmek, HTTP/2 ve TLSv1.3 kullandığımızdan emin olmak gibi olağan şeylerle başladık. Bunların çoğu CSS-Tricks'in faydalı genel bakışında ele alınmıştır ve Smashing Magazine harika bir PDF kontrol listesi sunar.

Önce İlk Şeyler: Tüm Sayfalara Yüklenen Şeyler

Sadece CSS veya JavaScript (daha sonra ele alacağız) değil, kaynaklar hakkında konuşalım. Her biri bir etkiye sahip olabilecek birden çok ekranda paylaşılan şeylere bakarak başladık. Ancak bundan sonra sayfa türlerine ve onlara özgü konulara odaklandık. Bazı ortak öğeler şunlardı.

Simge Yükleniyor

Pek çok web sitesinde olduğu gibi, tasarımımızda da birkaç simge kullanıyoruz. Prototip, gömülü SVG sembolleri olan bazı özel simgelerle geldi. Bunlar, daha sonra HTML'nin gövdesinde bağlantılı bir svg olarak kullanılan simgelerin her biri için bir sembolle birlikte sayfanın HTML başlığında büyük bir svg etiketi olarak depolandı. Bu, belge yüklendiğinde bunları doğrudan tarayıcının kullanımına sunma gibi hoş bir etkiye sahiptir, ancak açıkçası tarayıcı bunları tüm web sitesi için önbelleğe alamaz.

Bu yüzden onları harici bir SVG dosyasına taşımaya ve önceden yüklemeye karar verdik. Ek olarak, yalnızca gerçekten kullandığımız simgeleri dahil ettik. Bu şekilde dosya sunucuda ve tarayıcıda önbelleğe alınabilir ve gereksiz SVG'lerin yorumlanmasına gerek kalmaz. Ayrıca sayfada (JavaScript aracılığıyla yüklediğimiz) Font Awesome'in kullanımını da destekliyoruz, ancak isteğe bağlı olarak yüklüyoruz (herhangi bir <i> etiketini kontrol eden küçük bir komut dosyası ekliyor ve ardından herhangi bir SVG'yi almak için Font Awesome JavaScript'i yüklüyoruz) bulduğu simgeler). Ekranın üst kısmındaki kendi simgelerimize bağlı kaldığımız için, DOM yüklendikten sonra tüm komut dosyasını çalıştırabiliriz.

Ayrıca bazı yerlerde renkli simgeler için emoji kullanıyoruz, hiçbirimizin gerçekten düşünmediği, ancak içerik düzenleyicimiz Daena'nın istediği ve performans üzerinde hiçbir olumsuz etkisi olmayan simgeleri göstermenin harika bir yolu olan bir şey (tek uyarı şudur: farklı işletim sistemlerinde farklı tasarımlar).

Yazı Tipi Yükleme

Diğer pek çok web sitesinde olduğu gibi, tipografi ihtiyaçlarımız için web yazı tiplerini kullanıyoruz. Tasarım, gövdede iki yazı tipi (iki ağırlıkta Josefin Sans ), biri başlıklar için ( Nixie One ) ve biri özel olarak tasarlanmış metin için ( Moonstone Regular ) gerektirir. Başından beri, performans için bir içerik dağıtım ağı (CDN) ile bunları yerel olarak depoladık, ancak Simon Hearne'in yazı tipi yükleme ile düzen kaymalarından kaçınma hakkındaki harika makalesini okuduktan sonra, kalın sürümü kaldırmayı ve normal sürümü kullanmayı denedik.

Testlerimizde görsel fark o kadar azdı ki, testçilerimizden hiçbiri ikisini aynı anda görmeden anlayamadı. Böylece yazı tipi ağırlığını düşürdük . Bu makale üzerinde çalışırken ve bu bölüm için görsel bir yardım hazırlarken, Mac'te Chromium tabanlı tarayıcılarda ve yüksek çözünürlüklü ekranlarda WebKit tabanlı tarayıcılarda daha büyük farklılıklarla karşılaştık (hayır, karmaşıklık!). Bu, ne yapmamız gerektiği konusunda başka bir tartışma turuna yol açtı.

Biraz ileri geri gittikten sonra, sahteyi kalın tutmayı ve bu belirli tarayıcılara yardımcı olmak için -webkit-text-stroke: 0.3px kullanmayı seçtik. Gerçek ayrı yazı tipi ağırlığını kullanmaktan farkı azdır, ancak neredeyse hiç kalın yazı tipi kullanmadığımız, bir seferde yalnızca bir avuç kelime kullandığımız kullanım durumumuz için yeterli değildir (üzgünüz, yazı tipi meraklıları).

Ayrıca birçok ürün gravür ile kişiselleştirilebilir . Bu gravürler birden fazla yazı tipinde yapılabilir ve bazıları için yazı tipinin uygulandığı bir önizleme sunuyoruz. Bunlar için, açılır yazı tipi seçicide seçildiğinde yazı tipini istek üzerine indiririz. Açılır menüdeki önizlemeler, yazı tipinin nasıl göründüğüne dair örnek resimlerdir. Bu, 10 veya daha fazla ek yazı tipi dosyası indirmemizi engeller.

Miras yardımı

Bir gün CSS-Tricks, “2021'de Favicon Nasıl Yapılır” başlıklı bir makaleyle beni şaşırttı. Dünyadaki her dokunmatik simge boyutunu kullanıyorduk - makale gerçekten neye ihtiyacımız olduğunu yeniden değerlendirmemi sağladı ve bazen birkaç yıl önce doğru olanın artık gerekli olmayabileceğini gösterdi. Makaleye dayanarak, favicon ve touch ikon listelerimizi önerilen sürümlerle sınırladık.

Benzer şekilde, yalnızca WOFF sürümü olarak sahip olduğumuz bir yazı tipini de çok daha küçük olan WOFF2'ye dönüştürdük ve yazı tipleri için WOFF2 sağlamaya karar verdik (WOFF geri dönüş olarak kaldı). Ve artık gerekli olmayan CSS yönergelerini temizledik.

Tembel ve İsteğe Bağlı Yükleme

Birkaç metrik, kullanıcıların sayfayla ne kadar süre sonra etkileşime geçebileceğine odaklanır. Mantık, yüklenecek daha az öğeye sahip olmanın, bu noktaya daha erken ulaşılacağı anlamına geldiğini belirtir. Bunu hesaba katmak için, kendinize sayfanın hangi bölümlerinin gerekli olduğunu ve kullanıcının yalnızca daha sonra ihtiyaç duyacağını sormanız önemlidir. Bu konuda çok tartıştık, deneme yanılma yaptık.

Ağ etkinliğinin şelalesi burada çok yardımcı oldu, ancak kullanıcı akışlarını düşünmek de öyle. Örneğin, yakınlaştırılan ürün resmi, bir kullanıcı ürün resmiyle ilk etkileşim kurduğunda yüklenebilir ve alt bilgideki resimler genellikle ekranın üst kısmında gösterilmez ve daha sonra yüklenebilir. Yavaşlamalarla ilgili endişeleriniz varsa, önceden getirme kaynaklarıyla çalışmaya devam edebilirsiniz.

Çok erken fark ettiğimiz bir şey, sohbet istemcisinin büyük etkisiydi. Yalnızca 500 KB JavaScript'in üzerindeydi ve ne yazık ki artık bir grafiğim olmasa da yüklenmesi de yavaştı. JavaScript eşzamansız olarak yüklenecek şekilde ayarlanmış olsa da, Google onu etkileşim süresi ölçümlerine dahil ediyordu.

Durumun neden böyle olduğunu tam olarak izleyemedik, ancak üzerinde sınırlı kontrolümüz olan bir şeyi düzeltmeye çalışmak yerine, onun büyüklüğü ve büyüklüğü arasında alternatifler aramaya başladık. Jewellerybox'ı bunun yerine kendi kendine barındırılan bir açık kaynaklı sohbet widget'ını denemeye ikna ettik , bu da bize nasıl yüklendiği konusunda daha fazla kontrol sağlıyor ve hangisi daha küçük. Daha da geliştirmek için, başlangıçta yalnızca sohbetin simgesini yüklüyoruz; geri kalanı, açmak için tıkladığınızda yüklenir.

Görünmez Üçüncü Taraf Atlıkarınca

Jewellerybox, birkaç sayfadaki karusellerde ürün kişiselleştirmeyi geliştirmek için yapay zeka kullanan bir üçüncü taraf hizmeti denemek istedi. Bunun için API'sini arka uçtan çağırmaya karar verdik, böylece neyin yükleneceği (büyük JavaScript bağımlılıkları olmadan) ve hizmetlerinden ne kadar süre yanıt beklediğimiz (bazı yedekler tanımlı olarak) üzerinde daha fazla kontrole sahip olacaktık. Bu nedenle, karuseller kişiselleştirilmemiş olanlarla aynı şekilde yüklenir ve benzersiz bir önbellek anahtarıyla da önbelleğe alınabilir.

Ancak bir dezavantajı var: Bu, önbelleğe alınmadıkça sunucu tarafında ilk sayfa oluşturma işleminin daha yavaş olabileceği anlamına gelir. Bu nedenle, sayfa yüklendikten sonra sonuçları enjekte etmenin ve ilk başta bir yer tutucu oluşturmanın alternatif yolları üzerinde çalışıyoruz.

Second Up: JavaScript'i Optimize Etme — Dış Düşmanlara Karşı Zorlu Bir Savaş

Döngü bizi odaklandığımız ikinci büyük alana getiriyor: JavaScript. Sahip olduğumuz JavaScript'i denetledik ve çoğunluğu çok az özel kodla farklı görevler için kitaplıklardan. Kendimiz yazdığımız kodu optimize ettik, ancak genel kodunuzun yalnızca bir kısmıysa yapabileceğiniz çok şey var - büyük kazançlar kütüphanelerde yatıyor.

Kütüphanelerdeki öğeleri optimize etmek veya ihtiyacınız olmayan parçaları çıkarmak, büyük olasılıkla bir aptalın işidir. Bazı bölümlerin neden orada olduğunu gerçekten bilmiyorsunuz ve çok fazla manuel çalışma olmadan kitaplığı bir daha asla yükseltemeyeceksiniz. Bunu göz önünde bulundurarak bir adım geri attık ve hangi kütüphaneleri kullandığımıza ve onlara ne için ihtiyacımız olduğuna baktık ve her biri için ihtiyaçlarımıza da uyan daha küçük veya daha hızlı bir alternatif olup olmadığını araştırdık.

Birkaç durumda, vardı! Örneğin, Slick kaydırıcı kitaplığını daha az ama ihtiyacımız olan tüm özelliklere sahip, ayrıca yüklenmesi daha hızlı ve daha modern CSS desteğine sahip GliderJS ile değiştirmeye karar verdik! Ayrıca, ana JavaScript dosyasından bağımsız kitaplıkların çoğunu çıkardık ve istek üzerine yüklemeye başladık.

Bootstrap 4 kullandığımız için, proje için hala jQuery'yi dahil ediyoruz, ancak her şeyi yerel uygulamalarla değiştirmeye çalışıyoruz. Bootstrap'in kendisi için GitHub'da şu anda kullandığımız jQuery bağımlılığı olmayan bir bootstrap.native sürümü var. Boyut olarak daha küçüktür ve daha hızlı çalışır. Artı, ana JavaScript dosyamızın iki sürümünü oluşturuyoruz: biri çoklu dolgusuz ve bir tanesi dahil edilmiş ve tarayıcının ihtiyaç duyduğunda sürümü onlarla değiştiriyoruz, bu da çoğu kişiye basitleştirilmiş bir ana sürüm sunmamızı sağlıyor. "Talep üzerine çoklu doldurma" hizmetini test ettik, ancak performans beklentilerimizi karşılamadı.

jQuery konusunda son bir şey. İlk olarak sunucumuzdan yükledik. Google CDN aracılığıyla yüklerken test sistemimizde performans iyileştirmeleri gördük, ancak Page Speed ​​Insights performanstan şikayet etti (bunu kimin çözebileceğini merak ediyorum), bu yüzden barındırmayı tekrar kendimiz test ettik ve üretimde aslında daha hızlıydı. kullandığımız CDN'dir.

Alınan ders : Test ortamı bir üretim ortamı değildir ve biri için yapılan düzeltmeler diğeri için geçerli olmayabilir.

Üçüncü Sıra: Görüntüler — Formatlar, Boyutlar ve Caz Olan Her Şey

Görseller, bir çevrimiçi mağazayı oluşturan şeyin büyük bir parçasıdır. Farklı cihazlar için farklı sürümleri saymadan önce bile, bir sayfada genellikle birkaç düzine resim bulunur. Mücevher kutusu web sitesi yaklaşık 10 yıldır var ve çoğu ürün o zamanın çoğunda mevcuttu, bu nedenle orijinal ürün resimleri boyut ve stil açısından tek tip değildir ve ürün çekimlerinin sayısı da değişebilir.

İdeal olarak, farklı görüntüleme boyutları ve görüntüleme yoğunlukları için modern biçimlerde duyarlı görüntüler sunmak isteriz, ancak gereksinimlerdeki herhangi bir değişiklik, yapılması gereken çok sayıda dönüştürme çalışması anlamına gelir. Bu nedenle, şu anda optimize edilmiş boyutta ürün resimleri kullanıyoruz, ancak bunlar için duyarlı resimlerimiz yok. Bunu güncellemek yol haritasında var ama önemsiz değil. İçerik sayfaları daha fazla esneklik sunar ve burada farklı boyutlar oluşturup kullanırız ve hem WebP hem de yedek formatları içeririz.

Bu kadar çok görüntüye sahip olmak, ilk yüke çok fazla ağırlık katar. Böylece görüntülerin ne zaman ve nasıl yükleneceği çok büyük bir konu haline geldi. Tembel yükleme, çözüme benziyor, ancak evrensel olarak uygulanırsa, başlangıçta görünen görüntüleri doğrudan yüklemek yerine yavaşlatabilir (veya en azından kullanıcıya böyle hissettirir). Bu nedenle, yerel tembel yükleme ve bir komut dosyası kombinasyonunu kullanarak ilk birkaçını doğrudan yükleme ve geri kalanını tembel yükleme kombinasyonunu seçtik.

Web sitesi logosu için, istemciden ilk sürümünü aldığımız bir SVG dosyası kullanıyoruz. Logo, elle yapılan kusurlu bir baskıda olacağı gibi, harflerin bölümlerinin eksik olduğu karmaşık bir yazı tipidir. Büyük boyutlarda, ayrıntıları göstermeniz gerekir, ancak web sitesinde bunu asla 150'ye 30 pikselin üzerinde kullanmayız. Orijinal dosyanın boyutu 192 KB'dı, çok büyük değil ama süper küçük de değildi. SVG ile oynamaya ve içindeki detayları azaltmaya karar verdik ve sonunda sıkıştırılmamış 40 KB boyutunda bir sürüm elde ettik. Kullandığımız ekran boyutlarında görsel bir farklılık yoktur.

Son Ama Kesinlikle En Az Değil: CSS

Kritik CSS

CSS, Google'ın Chrome Kullanıcı Deneyimi Raporunda (CrUX) büyük ölçüde yer alır ve ayrıca Google Page Speed ​​Insights raporunda ve önerilerinde yoğun olarak yer alır. Yaptığımız ilk şeylerden biri, tarayıcının mümkün olan en kısa sürede kullanılabilmesi için doğrudan HTML'ye yüklediğimiz bazı kritik CSS'leri tanımlamaktı - bu, içerik düzeni değişiklikleriyle (CLS) mücadele etmek için ana silahınızdır. Bir prototip sayfasına dayalı olarak kritik CSS'nin otomatik olarak çıkarılmasının bir kombinasyonunu ve ayıklanacak sınıf adlarını (tüm alt kurallar dahil) tanımlayabileceğimiz bir mekanizmayı seçtik. Bunu, ilgili sayfa türlerine eklenen genel stiller, ürün sayfası stilleri ve kategori stilleri için ayrı ayrı yapıyoruz.

Bundan öğrendiğimiz ve arada bazı hatalara neden olan bir şey, CSS'nin sırasının bununla değişmemesine dikkat etmemiz gerektiğidir. Kodu yazan farklı kişiler, dosyaya daha sonra geçersiz kılma ekleyen biri ve şeyleri çıkaran otomatik bir araç arasında işler karışabilir.

CLS'ye Karşı Açık Boyutlar

Bana göre CLS, Google'ın şapkasından çıkardığı bir şey ve şimdi hepimizin onunla ilgilenmesi ve kolektif kafalarımızı onun etrafına sarmamız gerekiyor. Önceden, kapların boyutlarını içlerindeki öğelerden almasına izin verebilirdik, şimdi bu öğelerin yüklenmesi kutu boyutunu bozabilir. Bunu akılda tutarak, hangi öğelerin CLS'ye neden olduğunu görmek için Geliştirici Araçları'ndaki "Performans" sekmesini ve süper yararlı Düzen Kaydırma GIF Oluşturucusunu kullandık. Oradan, yalnızca öğelerin kendilerine değil, aynı zamanda üstlerine de baktık ve mizanpaj üzerinde etkisi olacak CSS özelliklerini analiz ettik. Bazen şanslıydık - örneğin, logonun düzen değişikliğini önlemek için mobil cihazlarda açık bir boyuta ayarlanması gerekiyordu - ancak diğer zamanlarda mücadele gerçekti.

Profesyonel ipucu: Bazen bir kayma, görünen öğeden değil, ondan önceki öğeden kaynaklanır. Olası suçluları belirlemek için boyut ve aralık olarak değişen özelliklere odaklanın. Kendinize sormanız gereken temel soru şudur: Bu bloğun hareket etmesine ne sebep olabilir?

Sayfada bu kadar çok resim olduğu için, bunların CLS ile doğru şekilde davranmasını sağlamak da biraz işimize yaradı. Barry Pollard, “Görüntülerde Yükseklik ve Genişlik Ayarlamak Yine Önemlidir” yazısında haklı olarak bize bunu hatırlatıyor. Her durumda resimlerimiz için doğru genişlik ve yükseklik değerlerini (artı en-boy oranlarını) bulmak ve onları tekrar HTML'ye eklemek için çok zaman harcadık. Sonuç olarak, tarayıcı bilgileri erken aldığı için artık görüntüler için bir düzen kayması yoktur.

Gizemli CLS Skoru Vakası

Sayfanın üst kısmına yakın birçok büyük CLS sorununu kaldırdıktan sonra bir barikatla karşılaştık. Bazen (her zaman değil) Page Speed ​​veya Lighthouse'a baktığımızda 0,3'ün üzerinde bir CLS puanı aldık, ancak “Performans” sekmesinde asla. Düzen Kaydırma GIF Oluşturucu bazen bunu gösteriyordu, ancak tüm sayfa kabı hareket ediyor gibi görünüyordu.

Ağ ve CPU kısma etkinken, sonunda ekran görüntülerinde gördük! Mobildeki başlık, içindeki öğeler nedeniyle 2 piksel yüksekliğinde büyüyordu . Başlık zaten mobil cihazlarda sabit bir yükseklik olduğundan, basit düzeltmeyi yaptık ve ona açık bir yükseklik ekledik - durum kapandı. Ancak bu bize çok fazla sinirlenmeye mal oldu ve buradaki aletlerin hala çok belirsiz olduğunu gösteriyor.

Bu Çalışmıyor - Hadi Yeniden Yapalım!

Hepimizin bildiği gibi, mobil puanlar Sayfa Hızı için masaüstünden çok daha serttir ve bizim için özellikle kötü oldukları alanlardan biri de ürün sayfalarındaydı. CLS puanı tavan yaptı ve sayfada da performans sorunları vardı (birkaç karusel, sekme ve önbelleğe alınamayan öğeler bunu yapacak). Daha da kötüsü, sayfanın düzeni, bazı bilgilerin karıştırıldığı veya iki kez eklendiği anlamına geliyordu.

Masaüstünde, içerik için temel olarak iki sütunumuz vardır:

• Sütun A : Ürün fotoğrafı atlıkarınca, bazen blogger alıntıları ve ardından ürün bilgilerini içeren sekmeli bir düzen.
• Sütun B : Ürün adı, fiyatı, açıklaması ve "sepete ekle" düğmesi.
• Satır C : Benzer ürünlerin ürün karuseli.

Ancak mobilde, önce ürün fotoğraf atlıkarıncasının, ardından B sütununun, ardından A sütunundaki sekmeli düzenin gelmesi gerekiyordu. Bu nedenle, HTML'de bazı bilgiler display: none ve sipariş veriliyordu. flex: order özelliği ile değiştirilir. Kesinlikle işe yarıyor, ancak CLS puanları için iyi değil çünkü temelde her şeyin yeniden düzenlenmesi gerekiyor.

CodePen'de basit bir deney yapmaya karar verdim: HTML'yi yeniden düşünerek ve flexbox yerine display: grid kullanarak masaüstünde ve mobilde aynı temel kutu düzenini elde edebilir miyim ve bu , ızgara alanlarını gerektiği gibi yeniden düzenlememe izin verir mi? Uzun lafın kısası, işe yaradı ve CLS'yi çözdü ve ürün adının artık HTML'de eskisinden çok daha erken gelmesi gibi ek bir avantajı var - ek bir SEO kazancı!

CLS İçin Bir Atlıkarınca Hackleme

"Atlıkarınca" kelimesi zaten birkaç kez ortaya çıktı - ve bunun iyi bir nedeni var. Sadece kullandığımız carousel kitaplığını değiştirmekle kalmadık (ve içindeki görüntülerin yükleme davranışını da değiştirdik), aynı zamanda CLS için de uğraşmak zorunda kaldık çünkü carousel'in ekranın üst kısmında olduğu birkaç sayfamız var ve bu nedenle, hız puanları üzerinde büyük bir etkisi olabilir.

Etkileşim süresini azaltmak için atlıkarıncayı daha sonra yükleyerek başladık, ancak bu JavaScript tetiklenene ve slaytlar birbirinin altında olmaktan tek sıraya geçene kadar gözle görülür bir gecikmeye neden oldu. Bunun olmasını önlemek ve yükleme bitene kadar tüm atlıkarıncayı gizlemek de dahil olmak üzere her şeyi tek bir satırda tutmak için CSS yazmanın birçok yolunu denedik. Hiçbir şey bize bir kullanıcı olarak bir mağazayı ziyaret ederken görmek istediğimiz türden bir çözüm vermedi.

Bu kısa rant için üzgünüm, ancak gerçekten, ürün ve kategori karuselleri, duyarlı bir mağazadaki esnek öğelerin mükemmel fırtınasıdır: Görseller evrensel bir yükseklikte olmayabilir, ürün adları birden fazla satıra yayılabilir ve etiketleriniz olabilir veya olmayabilir. Temel olarak, şuna indirgenebilir: Satır için sabit bir yükseklik mümkün değildir ve ayrıca genişliği de gerçekten bilmiyorsunuz. Eğlenceli zamanlar.

Sonunda, (birincisi hariç) tüm slaytları visibility: hidden , bu noktada tüm slaytları tekrar görünür olacak şekilde değiştirmek için atlıkarıncaya bir sınıf ekliyoruz. Bu, ilk başta ek yükseklik alma sorununu çözer.

Ek olarak, başlangıçta sarmasız bir esnek kutudaki slaytlar için flex-shrink: 0 ve flex-base: 340px olarak ayarladık. Bu, tek bir satırda olmalarına neden olur ve slaytlar için yaklaşık bir başlangıç ​​genişliği verir. Bu bulmacanın çözülmesiyle - ve evet, göründüğü kadar baş ağrısıydı - noktaların ve okların içine düşmesi için yer açmak için bazı düzeltmeler ekledik. Bununla birlikte, artık karuseller için neredeyse hiç CLS yok!

Gez ²⁰ ⁄ ₂₀

Sonunda, birkaç ay içinde puanlarımızı iyileştiren pek çok küçük değişiklik oldu ve henüz bitirmedik. Ön uç geliştirmelerinde çoğunlukla iki kişiyle çalıştık, ekibin geri kalanı ise arka ucu iyileştirmeye odaklandı. Bu şekilde muhtemelen biraz daha yavaş olsa da, çakışma olmamasını sağladı ve puanlardaki farklılıklar açıkça ilişkilendirilebildi. Çok yardımcı olan bazı kaynaklar, Smashing Magazine'de derginin kendi geliştirmeleriyle ilgili harika makalelerdi.

Bir noktada, denemeniz gereken şeyler aşikar hale gelir çünkü büyük bir fark yaratmaları gerektiğini düşünmüyorsunuz, ancak bir süre sonra yaptıklarını fark ediyorsunuz. Bunun da ötesinde, bu projenin bize tekrar öğrettiği şey, tasarımın tasavvur edilmesinden ve prototipin kodlanmasından şablonlarda uygulanmasına kadar en başından performansın ve metriklerin akılda tutulmasının ne kadar önemli olduğudur. Erken ihmal edilen küçük şeyler, daha sonra geri almak için tırmanmanız gereken devasa dağlara neden olabilir.

İşte öğrendiğimiz bazı önemli yönler :

• JavaScript'i optimize etmek, istek üzerine yüklemek kadar etkili değildir;
• CSS'yi optimize etmek, JavaScript'i optimize etmekten daha fazla puan kazanıyor gibi görünüyor;
• CLS ve kritik CSS'nin çıkarılmasını göz önünde bulundurarak CSS sınıfları yazın;
• CLS sorunlarını bulmaya yönelik araçlar henüz mükemmel değil. Alışılmışın dışında düşünün ve birkaç aracı kontrol edin;
• Dosya boyutu ve performans zamanlaması için entegre ettiğiniz her üçüncü taraf hizmetini değerlendirin. Mümkünse, her şeyi yavaşlatacak herhangi bir şeyin entegrasyonunu geri itin;
• CrUX değişiklikleri (ve özellikle CLS) için sayfanızı düzenli olarak yeniden test edin;
• Tüm eski destek girişlerinizin hala gerekli olup olmadığını düzenli olarak kontrol edin.

Hala yapılacak iyileştirmeler listemizde bazı şeyler var:

• Ana dosyada kaldırılabilecek hâlâ çok sayıda kullanılmayan CSS var;
• jQuery'yi tamamen kaldırmak istiyoruz. Bu, özellikle ödeme alanında kodumuzun bazı kısımlarını yeniden yazmak anlamına gelir;
• Harici kaydırıcıların nasıl dahil edileceği konusunda daha fazla deney yapılması gerekiyor;
• Mobil puan puanlarımız daha iyi olabilirdi. Özellikle mobil için daha fazla çalışmaya ihtiyaç duyulacak;
• Tüm ürün görselleri için duyarlı görseller eklenmelidir;
• İçerik sayfalarını özellikle ihtiyaç duyabilecekleri iyileştirmeler için özellikle CLS ile ilgili olarak kontrol edeceğiz;
• Bootstrap'in daraltma eklentisini kullanan öğeler, yerel HTML details etiketiyle değiştirilecektir;
• DOM boyutunun küçültülmesi gerekiyor;
• Daha hızlı ve daha iyi arama sonuçları için bir üçüncü taraf hizmeti entegre edeceğiz. Bu, entegre etmemiz gereken büyük bir JavaScript bağımlılığı ile gelecek;
• Hem otomatik araçlara bakarak hem de kendimiz ekran okuyucular ve klavye gezintisi ile bazı testler yaparak erişilebilirliği iyileştirmeye çalışacağız.

Diğer Kaynaklar

• “DevTools Hata Ayıklama İpuçları ve Kısayollar (Chrome, Firefox, Edge),” Vitaly Friedman, Smashing Magazine
• Chris Coyier, CSS-Tricks "Son zamanlarda Yer İşaretlerine Eklediğim ve Okuduğum Bazı Performans Blogu Gönderileri"
• “Önemli Web Verilerini Ölçmek İçin Derinlemesine Bir Kılavuz,” Barry Pollard, Smashing Magazine
• "Semantik CSS'den Tailwind'e: Netlify UI Kod Tabanını Yeniden Düzenlemek," Charlie Gerard ve Leslie Cohn-Wein, Netlify
• “CSS Denetim Araçları,” Iris Lješnjanin, Smashing Magazine
• “Bugün CSS ile Yapabilecekleriniz” Andy Bell, Smashing Magazine
• “CSS Performansı Nasıl İyileştirilir,” Milica Mihajlija, Calibre
• Alex Russell, “Mobil Performans Eşitsizliği Açığı, 2021”
• Malte Ubl, “2021'de Web İçin Görüntü Yüklemeyi Maksimum Olarak Optimize Etme”
• Addy Osmani, Smashing Magazine “Mütevazı <img> Öğesi ve Temel Web Verileri”