Meningkatkan Kinerja Toko Online (Studi Kasus)

Setiap pengembang front-end mengejar cawan suci kinerja yang sama: skor hijau di Google Page Speed. Tanda-tanda nyata dari pekerjaan yang dilakukan dengan baik selalu dihargai. Seperti berburu cawan, Anda harus mempertanyakan apakah ini benar-benar jawaban yang Anda cari. Performa nyata untuk pengguna Anda dan bagaimana "rasa" situs web saat Anda menggunakannya tidak boleh didiskon, meskipun Anda harus membayar satu atau dua poin dalam Kecepatan Halaman (jika tidak, kita semua hanya akan memiliki bilah pencarian dan tanpa gaya teks).

Saya bekerja di agensi digital kecil, dan tim saya sebagian besar bekerja di situs web dan toko perusahaan besar — ​​kecepatan halaman menjadi bahan diskusi di beberapa titik, tetapi biasanya pada saat itu jawabannya adalah bahwa penulisan ulang besar akan diperlukan untuk benar-benar mencapai apa pun, efek samping yang tidak menguntungkan dari ukuran dan struktur proyek di perusahaan.

Bekerja dengan kotak perhiasan di toko online-nya merupakan perubahan kecepatan yang disambut baik bagi kami. Proyek ini terdiri dari meningkatkan perangkat lunak toko ke sistem sumber terbuka kami sendiri dan mengulang bagian depan toko dari awal. Desain dibuat oleh agensi desain dan UX yang juga menangani prototipe HTML (berdasarkan Bootstrap 4). Dari sana, kami memasukkannya ke dalam template — dan untuk sekali ini, kami memiliki klien yang terobsesi dengan kinerja situs web juga.

Untuk peluncuran, kami sebagian besar berfokus untuk mengeluarkan desain baru, tetapi setelah peluncuran kembali situs web ditayangkan, kami mulai memfokuskan perhatian kami untuk mengubah skor merah dan oranye menjadi hijau. Itu adalah perjalanan multi-bulan yang penuh dengan keputusan sulit, dengan banyak diskusi tentang pengoptimalan mana yang layak dilakukan. Saat ini, situs web jauh lebih cepat dan berperingkat tinggi di berbagai pameran dan tolok ukur. Dalam artikel ini, saya akan menyoroti beberapa pekerjaan yang kami lakukan dan bagaimana kami dapat mencapai kecepatan kami.

Toko Online Sedikit Berbeda

Sebelum kita masuk ke detail, mari luangkan waktu sejenak untuk berbicara tentang bagaimana toko online berbeda dari banyak situs web lain (jika Anda sudah mengetahuinya, kami akan bertemu dengan Anda di bagian berikutnya). Ketika kita berbicara tentang situs web e-niaga, halaman utama yang akan Anda miliki adalah:

• halaman beranda (dan halaman "konten"),
• kategori dan halaman pencarian,
• halaman detail produk,
• keranjang dan checkout (jelas).

Untuk artikel ini, kami akan fokus pada tiga yang pertama dan penyesuaian kinerja untuk ini. Kasir adalah binatangnya sendiri. Di sana Anda akan memiliki banyak JavaScript ekstra dan logika back-end untuk menghitung harga, ditambah beberapa panggilan layanan untuk mendapatkan penyedia pengiriman yang sesuai dan perkiraan harga berdasarkan negara tujuan pengiriman.

Ini jelas merupakan tambahan untuk validasi bidang formulir yang Anda perlukan untuk mencatat alamat penagihan dan pengiriman. Tambahkan ke drop-in penyedia pembayaran, dan Anda memiliki beberapa halaman yang tidak ingin disentuh siapa pun setelah diuji dan berfungsi dengan benar.

Apa hal pertama yang Anda pikirkan ketika Anda membayangkan sebuah toko online? Gambar — banyak sekali gambar produk. Mereka pada dasarnya ada di mana-mana dan akan mendominasi desain Anda. Plus, Anda akan ingin menunjukkan banyak produk untuk membuat orang membeli dari Anda — jadi ini adalah korsel. Tapi tunggu! Apakah orang mengklik produk di dalamnya? Kita bisa mengetahuinya dengan meletakkan beberapa pelacakan di carousel. Jika kami melacaknya, kami dapat mengoptimalkannya! Dan tiba-tiba, kami memiliki carousel produk eksternal bertenaga AI di halaman kami.

Masalahnya, carousel tidak akan menjadi elemen penghukuman terakhir yang Anda tambahkan ke halaman untuk menampilkan lebih banyak produk dengan harapan menarik lebih banyak penjualan. Tentu saja, sebuah toko membutuhkan elemen interaktif , baik itu pembesaran gambar produk, beberapa video, hitungan mundur hingga batas waktu pengiriman hari ini, atau jendela obrolan untuk menghubungi dukungan pelanggan.

Semua ini sangat penting ketika Anda mengukur konversi secara langsung sebagai pendapatan . Plus, setiap beberapa bulan, seseorang di tim akan melihat beberapa fungsionalitas baru yang keren yang dapat ditambahkan, sehingga kompleksitas dan JavaScript mulai menumpuk, meskipun Anda memulai dengan niat terbaik untuk membuatnya tetap ramping.

Dan meskipun Anda biasanya dapat men-cache halaman penuh sebuah artikel, hal yang sama tidak berlaku untuk banyak halaman dan elemen toko. Beberapa spesifik pengguna, seperti keranjang belanja di header atau daftar keinginan, dan karena sifat data pribadi, mereka tidak boleh di-cache. Selain itu, jika Anda memiliki barang fisik, Anda berurusan dengan inventaris langsung: Khususnya selama liburan Natal, Anda akan memerlukan informasi tentang inventaris yang tepat dan terkini; jadi, Anda memerlukan strategi caching yang lebih kompleks yang memungkinkan Anda untuk men-cache bagian halaman dan menggabungkan semuanya kembali selama rendering sisi server.

Tetapi bahkan dalam fase perencanaan, jebakan menunggu. Dalam desain — dan seringkali juga fase prototipe — Anda akan bekerja dengan nama dan deskripsi produk yang dibuat dengan baik, panjangnya hampir seragam, dan gambar produk yang ideal. Mereka terlihat luar biasa! Satu-satunya masalah? Pada kenyataannya, informasi produk bisa sangat berbeda panjangnya yang dapat mengacaukan desain Anda. Dengan beberapa ribu produk, Anda tidak dapat memeriksa satu per satu.

Oleh karena itu, ada baiknya jika desainer atau orang-orang melakukan uji prototipe dengan string yang sangat pendek dan sangat panjang untuk memastikan desainnya masih sesuai. Demikian pula, memiliki informasi yang muncul dua kali dalam HTML, sekali untuk desktop dan sekali untuk seluler, dapat menjadi masalah besar bagi toko — terutama jika itu adalah informasi yang kompleks seperti detail produk, keranjang belanja, atau faset untuk filter pada kategori produk. halaman. Menjaga sinkronisasi itu sulit dilakukan — jadi, tolong bantu sesama pengembang dan jangan lakukan itu.

Hal lain yang tidak boleh diabaikan dan harus dimasukkan dari tahap prototipe dan seterusnya adalah aksesibilitas. Beberapa alat di luar sana dapat membantu Anda dengan beberapa dasar, mulai dari memiliki teks alternatif untuk semua gambar dan ikon dengan fungsi, hingga kontras warna, hingga mengetahui atribut ARIA mana yang akan digunakan di mana (dan kapan tidak). Memasukkan ini sejak awal jauh lebih mudah daripada nanti, dan memungkinkan semua orang menikmati situs web yang sedang Anda kerjakan.

Berikut ini tipnya: Jika Anda belum pernah melihat orang menggunakan pembaca layar atau bernavigasi hanya dengan keyboard, video tentang ini dapat dengan mudah ditemukan di YouTube. Ini akan mengubah pemahaman Anda tentang topik ini.

Kembali ke kinerja: Mengapa sangat penting untuk meningkatkan kinerja toko lagi? Jawaban yang jelas adalah Anda ingin orang membeli dari Anda . Ada beberapa cara Anda dapat memengaruhi ini, dan kecepatan situs web Anda sangat besar. Studi menunjukkan bahwa setiap detik tambahan waktu pemuatan memiliki dampak signifikan pada tingkat konversi. Selain itu, kecepatan halaman adalah faktor peringkat untuk pencarian dan juga untuk Iklan Google Anda. Jadi, peningkatan kinerja akan memiliki efek nyata pada bottom line.

Hal-Hal Praktis yang Kami Lakukan

Beberapa hambatan kinerja mudah diidentifikasi, tetapi peningkatan menyeluruh adalah perjalanan yang lebih panjang, dengan banyak tikungan dan belokan. Kami memulai dengan semua hal yang biasa, seperti memeriksa ulang caching sumber daya, melihat apa yang dapat kami ambil atau muat secara asinkron, memastikan kami menggunakan HTTP/2 dan TLSv1.3. Banyak dari mereka tercakup dalam gambaran umum CSS-Tricks yang membantu, dan Smashing Magazine menawarkan daftar periksa PDF yang bagus.

Hal Pertama Yang Pertama: Hal-Hal yang Dimuat Di Semua Halaman

Mari kita bicara tentang sumber daya, dan bukan hanya CSS atau JavaScript (yang akan kita bahas nanti). Kami memulai dengan melihat hal-hal yang dibagikan di beberapa layar, yang masing-masing dapat berdampak. Baru setelah itu kami fokus pada jenis halaman dan masalah yang unik bagi mereka. Beberapa item umum adalah sebagai berikut.

Pemuatan Ikon

Seperti pada banyak situs web, kami menggunakan beberapa ikon dalam desain kami. Prototipe datang dengan beberapa ikon khusus yang disematkan simbol SVG. Ini disimpan sebagai satu tag svg besar di kepala HTML halaman, dengan simbol untuk setiap ikon yang kemudian digunakan sebagai svg tertaut di badan HTML. Ini memiliki efek yang bagus untuk membuatnya tersedia langsung ke browser saat dokumen dimuat, tetapi jelas browser tidak dapat menyimpannya di cache untuk seluruh situs web.

Jadi kami memutuskan untuk memindahkannya ke file SVG eksternal dan memuatnya terlebih dahulu. Selain itu, kami hanya menyertakan ikon yang sebenarnya kami gunakan. Dengan cara ini, file dapat di-cache di server dan di browser, dan tidak ada SVG yang berlebihan yang perlu ditafsirkan. Kami juga mendukung penggunaan Font Awesome pada halaman (yang kami muat melalui JavaScript), tetapi kami memuatnya sesuai permintaan (menambahkan skrip kecil yang memeriksa tag <i> apa pun, lalu memuat Font Awesome JavaScript untuk mendapatkan SVG apa pun ikon yang ditemukan). Karena kita tetap pada ikon kita sendiri di paro atas, kita dapat menjalankan seluruh skrip setelah DOM dimuat.

Kami juga menggunakan emoji di beberapa tempat untuk ikon warna-warni, sesuatu yang tidak satu pun dari kami benar-benar pikirkan tetapi yang diminta oleh editor konten kami, Daena, dan yang merupakan cara hebat untuk menampilkan ikon tanpa efek buruk pada kinerja sama sekali (satu-satunya peringatan adalah desain yang berbeda pada sistem operasi yang berbeda).

Pemuatan Font

Seperti di banyak situs web lain, kami menggunakan font web untuk kebutuhan tipografi kami. Desainnya membutuhkan dua font di badan ( Josefin Sans dalam dua bobot), satu untuk heading ( Nixie One ), dan satu untuk teks dengan gaya khusus ( Moonstone Regular ). Sejak awal, kami menyimpannya secara lokal, dengan jaringan pengiriman konten (CDN) untuk kinerja, tetapi setelah membaca artikel bagus oleh Simon Hearne tentang menghindari perubahan tata letak dengan pemuatan font, kami bereksperimen dengan menghapus versi tebal dan menggunakan yang biasa.

Dalam pengujian kami, perbedaan visual sangat kecil sehingga tidak ada penguji kami yang dapat mengetahuinya tanpa melihat keduanya secara bersamaan. Jadi, kami menurunkan bobot font . Saat mengerjakan artikel ini dan menyiapkan bantuan visual untuk bagian ini, kami menemukan perbedaan yang lebih besar antara browser berbasis Chromium di Mac dan browser berbasis WebKit pada layar resolusi tinggi (yay, kompleksitas!). Hal ini menyebabkan putaran lain diskusi tentang apa yang harus kita lakukan.

Setelah bolak-balik, kami memilih untuk tetap menggunakan huruf tebal palsu dan menggunakan -webkit-text-stroke: 0.3px untuk membantu browser tertentu tersebut. Perbedaan dari penggunaan berat font terpisah yang sebenarnya sedikit, tetapi tidak cukup untuk kasus penggunaan kami, di mana kami hampir tidak menggunakan font tebal, hanya beberapa kata pada satu waktu (maaf, penggemar font).

Selain itu, beberapa produk dapat dipersonalisasi dengan ukiran . Ukiran ini dapat dilakukan dalam beberapa font, dan untuk beberapa kami menawarkan pratinjau dengan font yang diterapkan. Untuk ini, kami mengunduh font sesuai permintaan saat dipilih di pemilih font dropdown. Pratinjau di dropdown adalah contoh gambar dari tampilan font. Ini membuat kami tidak perlu mengunduh 10 atau lebih file font tambahan.

Dukungan Warisan

Suatu hari, CSS-Tricks mengejutkan saya dengan artikel tentang "Cara Favicon di tahun 2021". Kami menggunakan setiap ukuran ikon sentuh di dunia — artikel tersebut membuat saya mengevaluasi kembali apa yang sebenarnya kami butuhkan dan menunjukkan kepada saya bahwa terkadang apa yang benar beberapa tahun yang lalu mungkin tidak diperlukan lagi. Berdasarkan artikel tersebut, kami membatasi daftar ikon favicon dan ikon sentuh kami ke versi yang direkomendasikan.

Demikian pula, kami juga mengonversi font yang kami miliki hanya sebagai versi WOFF ke WOFF2 , yang jauh lebih kecil, dan kami memutuskan untuk menyediakan WOFF2 untuk font (dengan WOFF tersisa sebagai fallback). Dan kami menghapus arahan CSS yang tidak lagi diperlukan.

Pemuatan Malas Dan Sesuai Permintaan

Beberapa metrik berpusat pada waktu setelah pengguna dapat berinteraksi dengan halaman. Logika menentukan bahwa memiliki lebih sedikit elemen untuk dimuat berarti titik ini akan tercapai lebih cepat. Untuk menjelaskan hal ini, penting untuk bertanya pada diri sendiri bagian mana dari halaman yang penting dan mana yang hanya dibutuhkan pengguna nanti. Kami melewati banyak perdebatan dan coba-coba dalam hal ini.

Air terjun aktivitas jaringan banyak membantu di sini, tetapi begitu juga memikirkan arus pengguna. Misalnya, gambar produk yang diperbesar dapat dimuat pertama kali pengguna berinteraksi dengan gambar produk, dan gambar di footer biasanya tidak ditampilkan di paro atas dan dapat dimuat nanti. Jika Anda khawatir tentang pelambatan, Anda masih dapat bekerja dengan mengambil sumber daya terlebih dahulu.

Satu hal yang kami perhatikan sejak awal adalah dampak besar dari klien obrolan. Itu lebih dari 500 KB JavaScript saja, dan sayangnya saya tidak memiliki grafik lagi, itu juga lambat untuk dimuat. Meskipun JavaScript disetel untuk memuat secara tidak sinkron, Google memasukkannya ke dalam pengukuran waktu-ke-interaktif.

Kami tidak dapat sepenuhnya melacak mengapa hal ini terjadi, tetapi antara itu dan ukurannya yang tipis, kami mulai mencari alternatif, alih-alih mencoba memperbaiki sesuatu yang kami kendalikan terbatas. Kami meyakinkan Jewellerybox untuk mencoba widget obrolan sumber terbuka yang dihosting sendiri , yang memberi kami kontrol lebih besar atas cara memuatnya dan yang juga jauh lebih kecil. Untuk meningkatkannya lebih lanjut, kami hanya memuat ikon untuk obrolan pada awalnya; sisanya akan dimuat ketika Anda mengklik untuk membukanya.

Korsel Pihak Ketiga yang Tak Terlihat

Jewellerybox ingin mencoba layanan pihak ketiga yang menggunakan AI untuk meningkatkan personalisasi produk di carousel di beberapa halaman. Kami memutuskan untuk memanggil API-nya dari bagian belakang untuk ini, sehingga kami akan memiliki kontrol lebih besar atas apa yang dimuat (tanpa ketergantungan JavaScript yang besar) dan berapa lama kami menunggu tanggapan dari layanan mereka (dengan beberapa fallback yang ditentukan). Karena itu, carousel dimuat dengan cara yang sama seperti yang tidak dipersonalisasi dan dapat di-cache dengan kunci cache yang unik juga.

Namun ada kekurangannya: Ini berarti bahwa rendering halaman awal di sisi server bisa lebih lambat kecuali di-cache. Untuk alasan ini, kami sedang mengerjakan cara alternatif untuk memasukkan hasil setelah halaman dimuat dan menampilkan placeholder terlebih dahulu.

Second Up: Mengoptimalkan JavaScript — Perjuangan Berat Melawan Musuh Eksternal

Korsel membawa kita ke area besar kedua yang menjadi fokus kami: JavaScript. Kami mengaudit JavaScript yang kami miliki, dan sebagian besar berasal dari perpustakaan untuk tugas yang berbeda, dengan sedikit kode khusus. Kami mengoptimalkan kode yang telah kami tulis sendiri, tetapi jelas hanya ada begitu banyak yang dapat Anda lakukan jika itu hanya sebagian kecil dari keseluruhan kode Anda — keuntungan besar terletak pada perpustakaan.

Mengoptimalkan barang-barang di perpustakaan atau mengambil bagian yang tidak Anda butuhkan, kemungkinan besar, adalah tugas yang bodoh. Anda tidak benar-benar tahu mengapa beberapa bagian ada di sana, dan Anda tidak akan pernah dapat memutakhirkan perpustakaan lagi tanpa banyak pekerjaan manual. Dengan mengingat hal itu, kami mengambil langkah mundur dan melihat perpustakaan mana yang kami gunakan dan untuk apa kami membutuhkannya , dan kami menyelidiki masing-masing apakah ada alternatif yang lebih kecil atau lebih cepat yang juga sesuai dengan kebutuhan kami.

Dalam beberapa kasus, ada! Misalnya, kami memutuskan untuk mengganti perpustakaan slider Slick dengan GliderJS, yang memiliki lebih sedikit fitur tetapi semua yang kami butuhkan, ditambah lebih cepat untuk memuat dan memiliki dukungan CSS yang lebih modern! Selain itu, kami mengambil banyak perpustakaan mandiri dari file JavaScript utama dan mulai memuatnya sesuai permintaan.

Karena kami menggunakan Bootstrap 4, kami masih menyertakan jQuery untuk proyek tersebut tetapi sedang berupaya mengganti semuanya dengan implementasi asli. Untuk Bootstrap sendiri, ada versi bootstrap.native di GitHub tanpa ketergantungan jQuery yang sekarang kita gunakan. Ukurannya lebih kecil dan berjalan lebih cepat. Selain itu, kami membuat dua versi file JavaScript utama kami: satu tanpa polyfill dan satu lagi dengan mereka, dan kami menukar versi dengan mereka saat browser membutuhkannya, memungkinkan kami untuk memberikan versi utama yang disederhanakan kepada kebanyakan orang. Kami menguji layanan "polyfill-on-demand", tetapi kinerjanya tidak memenuhi harapan kami.

Satu hal terakhir tentang topik jQuery. Awalnya, kami memuatnya dari server kami. Kami melihat peningkatan kinerja pada sistem pengujian kami saat memuatnya melalui Google CDN, tetapi Wawasan Kecepatan Laman mengeluhkan kinerja (saya ingin tahu siapa yang bisa menyelesaikannya), jadi kami menguji hostingnya sendiri lagi, dan dalam produksi sebenarnya lebih cepat karena CDN yang kami gunakan.

Hal yang dipelajari : Lingkungan pengujian bukanlah lingkungan produksi, dan perbaikan untuk yang satu mungkin tidak berlaku untuk yang lain.

Third Up: Gambar — Format, Ukuran, Dan Semua Jazz Itu

Gambar adalah bagian besar dari apa yang membuat toko online. Sebuah halaman biasanya memiliki beberapa lusin gambar, bahkan sebelum kita menghitung versi yang berbeda untuk perangkat yang berbeda. Situs web kotak perhiasan telah ada selama hampir 10 tahun, dan banyak produk telah tersedia untuk sebagian besar waktu itu, sehingga gambar produk asli tidak seragam dalam ukuran dan gaya, dan jumlah gambar produk juga dapat bervariasi.

Idealnya, kami ingin menawarkan gambar responsif untuk berbagai ukuran tampilan dan kepadatan tampilan dalam format modern, tetapi setiap perubahan persyaratan akan berarti banyak pekerjaan konversi yang harus dilakukan. Karena itu, saat ini kami menggunakan ukuran gambar produk yang dioptimalkan, tetapi kami tidak memiliki gambar responsif untuk itu. Memperbarui itu ada di peta jalan tetapi tidak sepele. Halaman konten menawarkan lebih banyak fleksibilitas, dan di sana kami menghasilkan dan menggunakan ukuran yang berbeda dan menyertakan format WebP dan fallback.

Memiliki begitu banyak gambar menambah banyak bobot pada muatan awal. Jadi, kapan dan bagaimana memuat gambar menjadi topik besar. Pemuatan lambat terdengar seperti solusinya, tetapi jika diterapkan secara universal, ini dapat memperlambat gambar yang awalnya terlihat, daripada memuatnya secara langsung (atau setidaknya terasa seperti itu bagi pengguna). Karena alasan ini, kami memilih kombinasi pemuatan beberapa yang pertama secara langsung dan pemuatan lambat sisanya, menggunakan kombinasi pemuatan lambat asli dan skrip.

Untuk logo situs web, kami menggunakan file SVG, yang kami dapatkan versi awal dari klien. Logo adalah font yang rumit di mana bagian-bagian hurufnya hilang, karena akan dicetak dengan tangan yang tidak sempurna. Dalam ukuran besar, Anda harus menunjukkan detailnya, tetapi di situs web kami tidak pernah menggunakannya di atas 150 kali 30 piksel. File aslinya berukuran 192 KB, tidak besar tetapi juga tidak terlalu kecil. Kami memutuskan untuk bermain dengan SVG dan mengurangi detail di dalamnya, dan kami berakhir dengan versi berukuran 40 KB yang dibuka ritsletingnya. Tidak ada perbedaan visual pada ukuran layar yang kami gunakan.

Terakhir Tapi Pasti Tidak Sedikit: CSS

CSS penting

Angka CSS sangat besar dalam Laporan Pengalaman Pengguna Chrome (CrUX) Google dan juga banyak fitur dalam laporan dan rekomendasi Wawasan Kecepatan Halaman Google. Salah satu hal pertama yang kami lakukan adalah mendefinisikan beberapa CSS penting, yang kami muat langsung di HTML sehingga tersedia untuk browser sesegera mungkin — ini adalah senjata utama Anda untuk melawan perubahan tata letak konten (CLS). Kami memilih kombinasi ekstraksi otomatis dari CSS penting berdasarkan halaman prototipe dan mekanisme yang dengannya kami dapat menentukan nama kelas yang akan diekstraksi (termasuk semua sub-aturan). Kami melakukan ini secara terpisah untuk gaya umum, gaya halaman produk, dan gaya kategori yang ditambahkan pada masing-masing jenis halaman.

Sesuatu yang kami pelajari dari ini dan yang menyebabkan beberapa bug di antaranya adalah bahwa kami harus berhati-hati agar urutan CSS tidak diubah oleh ini. Di antara orang yang berbeda yang menulis kode, seseorang yang menambahkan penggantian nanti di file, dan alat otomatis mengekstraksi sesuatu, itu bisa menjadi berantakan.

Dimensi Eksplisit Terhadap CLS

Bagi saya, CLS adalah sesuatu yang ditarik oleh Google, dan sekarang kita semua harus menghadapinya dan menyatukan kepala kita di sekitarnya. Padahal sebelumnya, kita bisa membiarkan kontainer mendapatkan ukurannya dari elemen di dalamnya, sekarang pemuatan elemen tersebut bisa mengacaukan ukuran kotak. Dengan mengingat hal itu, kami menggunakan tab "Kinerja" di Alat Pengembang dan Layout Shift GIF Generator yang sangat membantu untuk melihat elemen mana yang menyebabkan CLS. Dari sana, kami tidak hanya melihat elemen itu sendiri, tetapi juga pada induknya dan menganalisis properti CSS yang akan berdampak pada tata letak. Terkadang kami beruntung — misalnya, logo hanya membutuhkan ukuran eksplisit yang ditetapkan di ponsel untuk mencegah perubahan tata letak — tetapi di lain waktu, perjuangan itu nyata.

Kiat pro: Terkadang pergeseran tidak disebabkan oleh elemen yang tampak, tetapi oleh elemen yang mendahuluinya. Untuk mengidentifikasi kemungkinan penyebab, fokus pada properti yang berubah dalam ukuran dan jarak. Pertanyaan dasar untuk ditanyakan pada diri sendiri adalah: Apa yang bisa menyebabkan balok ini bergerak?

Karena begitu banyak gambar di halaman, membuatnya berperilaku benar dengan CLS juga membuat kami bekerja. Barry Pollard dengan tepat mengingatkan kita pada artikelnya, “Menyetel Tinggi dan Lebar pada Gambar Penting Lagi”. Kami menghabiskan banyak waktu untuk mencari tahu nilai lebar dan tinggi yang benar (ditambah rasio aspek) untuk gambar kami dalam setiap kasus untuk menambahkannya ke HTML lagi. Alhasil, tidak ada lagi pergeseran tata letak untuk gambar karena browser mendapatkan informasi lebih awal.

Kasus Skor CLS yang Misterius

Setelah menghapus banyak masalah besar CLS di dekat bagian atas halaman, kami menemui hambatan. Terkadang (tidak selalu) saat melihat Kecepatan Halaman atau Mercusuar, kami mendapat skor CLS lebih dari 0,3, tetapi tidak pernah di tab “Kinerja”. Layout Shift GIF Generator terkadang menunjukkannya, tetapi sepertinya seluruh wadah halaman sedang bergerak .

Dengan pelambatan jaringan dan CPU diaktifkan, kami akhirnya melihatnya di tangkapan layar! Header di ponsel bertambah tinggi 2 piksel karena elemen di dalamnya. Karena header adalah ketinggian tetap di seluler, kami melanjutkan dengan perbaikan sederhana dan menambahkan ketinggian eksplisit ke dalamnya — kasus ditutup. Tapi itu membuat kami gugup, dan itu menunjukkan bahwa perkakas di sini masih sangat tidak tepat.

Ini Tidak Berfungsi — Ayo Ulangi!

Seperti yang kita semua tahu, skor seluler jauh lebih keras untuk Kecepatan Halaman daripada desktop, dan satu area di mana mereka sangat buruk bagi kami adalah di halaman produk. Skor CLS sangat tinggi, dan halaman juga memiliki masalah kinerja (beberapa korsel, tab, dan elemen yang tidak dapat disimpan dalam cache akan melakukannya). Lebih buruk lagi, tata letak halaman berarti bahwa beberapa informasi dikocok atau ditambahkan dua kali.

Di desktop, pada dasarnya kami memiliki dua kolom untuk konten:

• Kolom A : Korsel foto produk, terkadang diikuti dengan kutipan blogger, diikuti oleh tata letak tab dengan informasi produk.
• Kolom B : Nama produk, harga, deskripsi, dan tombol “tambahkan ke keranjang”.
• Baris C : Korsel produk dari produk sejenis.

Namun, di seluler, korsel foto produk harus didahulukan, lalu kolom B, lalu tata letak tab dari kolom A. Karena itu, informasi tertentu diduplikasi dalam HTML, dikendalikan oleh display: none , dan urutannya sedang diaktifkan dengan flex: order properti. Ini pasti berhasil, tetapi tidak baik untuk skor CLS karena pada dasarnya semuanya perlu diatur ulang.

Saya memutuskan eksperimen sederhana di CodePen: Bisakah saya mencapai tata letak kotak dasar yang sama di desktop dan seluler dengan memikirkan ulang HTML dan menggunakan display: grid alih-alih flexbox, dan apakah itu memungkinkan saya untuk mengatur ulang area grid sesuai kebutuhan? Singkat cerita, itu berhasil, dan itu memecahkan CLS, dan memiliki manfaat tambahan bahwa nama produk sekarang hadir lebih cepat di HTML daripada sebelumnya — kemenangan SEO tambahan!

Meretas Korsel Untuk CLS

Kata "korsel" telah muncul beberapa kali — dan dengan alasan yang bagus. Kami tidak hanya mengubah pustaka carousel yang kami gunakan (dan mengubah perilaku pemuatan gambar di dalamnya), kami juga harus menanganinya untuk CLS karena kami memiliki beberapa halaman di mana carousel berada di paro atas dan, oleh karena itu, bisa berdampak besar pada skor kecepatan.

Kami memulai dengan memuat korsel nanti untuk mengurangi waktu-ke-interaktif , tetapi itu menyebabkan penundaan yang terlihat hingga JavaScript diaktifkan dan slide berpindah dari satu di bawah satu sama lain menjadi satu baris. Kami mencoba banyak cara untuk menulis CSS untuk mencegah hal ini terjadi dan menyimpan semuanya dalam satu baris, termasuk menyembunyikan seluruh carousel hingga selesai memuat. Tidak ada yang memberi kami jenis solusi yang ingin kami lihat saat mengunjungi toko sebagai pengguna.

Maaf untuk kata-kata kasar singkat ini, tetapi sungguh, korsel produk dan kategori adalah badai sempurna elemen fleksibel di toko yang responsif: Gambar mungkin tidak memiliki tinggi universal, nama produk mungkin mencakup beberapa baris, dan Anda mungkin memiliki label atau tidak. Pada dasarnya, intinya adalah ini: Tidak ada ketinggian tetap untuk baris yang dimungkinkan, dan Anda juga tidak benar-benar mengetahui lebarnya. Waktu yang menyenangkan.

Pada akhirnya, kami memutuskan untuk mengatur semua slide (selain dari yang pertama) ke visibility: hidden hingga carousel selesai dimuat, di mana kami menambahkan kelas ke carousel untuk mengubah semua slide agar terlihat lagi . Ini memecahkan masalah mengambil ketinggian tambahan pada awalnya.

Selain itu, kami menetapkan flex-shrink: 0 dan flex-base: 340px untuk slide dalam flexbox non-pembungkus pada awalnya. Hal ini menyebabkan mereka berada pada satu baris dan memberikan perkiraan lebar awal untuk slide. Setelah teka-teki itu terpecahkan — dan ya, itu sama memusingkan kedengarannya — kami menambahkan beberapa perbaikan untuk memberi ruang bagi titik dan panah untuk jatuh. Dengan itu, hampir tidak ada lagi CLS untuk carousel!

Tinjauan ke Belakang Adalah ²⁰ ₂₀

Pada akhirnya, banyak perubahan kecil selama beberapa bulan yang meningkatkan skor kami, dan kami belum selesai. Kami sebagian besar bekerja dengan dua orang pada peningkatan front-end, sementara tim lainnya fokus pada peningkatan back-end. Meskipun mungkin sedikit lebih lambat dengan cara ini, ini memastikan bahwa tidak ada tumpang tindih , dan perbedaan skor dapat dikaitkan dengan jelas. Beberapa sumber yang banyak membantu adalah artikel hebat di sini di Smashing Magazine tentang peningkatan majalah itu sendiri.

Pada titik tertentu, hal-hal yang harus Anda coba menjadi tidak jelas karena menurut Anda itu tidak akan membuat perbedaan besar, tetapi beberapa saat setelahnya Anda menyadari bahwa itu benar. Lebih dari itu, apa yang diajarkan proyek ini kepada kita lagi adalah betapa pentingnya untuk memiliki kinerja dan metrik untuk itu sejak awal , dari membayangkan desain dan mengkodekan prototipe hingga implementasi dalam template. Hal-hal kecil yang diabaikan sejak awal dapat menambah gunung besar yang harus Anda daki nanti untuk membatalkannya.

Berikut adalah beberapa aspek utama yang kami pelajari:

• Mengoptimalkan JavaScript tidak seefektif memuatnya sesuai permintaan;
• Mengoptimalkan CSS tampaknya mendapatkan lebih banyak poin daripada mengoptimalkan JavaScript;
• Tulis kelas CSS dengan CLS dan ekstraksi CSS penting dalam pikiran;
• Alat untuk menemukan masalah CLS belum sempurna. Pikirkan di luar kotak dan periksa beberapa alat;
• Evaluasi setiap layanan pihak ketiga yang Anda integrasikan untuk ukuran file dan waktu kinerja. Jika memungkinkan, dorong kembali integrasi apa pun yang akan memperlambat segalanya;
• Uji ulang halaman Anda secara teratur untuk melihat perubahan CrUX (dan terutama CLS);
• Periksa secara teratur apakah semua entri dukungan lawas Anda masih diperlukan.

Kami masih memiliki beberapa hal dalam daftar perbaikan yang harus kami lakukan:

• Kami masih memiliki banyak CSS yang tidak digunakan di file utama yang dapat dihapus;
• Kami ingin menghapus jQuery sepenuhnya. Ini berarti menulis ulang bagian dari kode kita, terutama di area checkout;
• Eksperimen lebih lanjut perlu dilakukan tentang cara memasukkan bilah geser eksternal;
• Skor poin seluler kami bisa lebih baik. Pekerjaan lebih lanjut akan dibutuhkan terutama untuk seluler;
• Gambar responsif perlu ditambahkan untuk semua gambar produk;
• Kami akan memeriksa halaman konten secara khusus untuk perbaikan yang mungkin mereka perlukan, terutama seputar CLS;
• Elemen yang menggunakan plugin penciutan Bootstrap akan diganti dengan tag details HTML asli;
• Ukuran DOM perlu dikurangi;
• Kami akan mengintegrasikan layanan pihak ketiga untuk hasil pencarian yang lebih cepat dan lebih baik. Ini akan datang dengan ketergantungan JavaScript besar yang perlu kita integrasikan;
• Kami akan berupaya meningkatkan aksesibilitas baik dengan melihat alat otomatis dan dengan menjalankan beberapa pengujian dengan pembaca layar dan navigasi keyboard sendiri.

Sumber Daya Lebih Lanjut

• “Tips dan Pintasan Debugging DevTools (Chrome, Firefox, Edge),” Vitaly Friedman, Smashing Magazine
• “Beberapa Postingan Blog Performa yang Saya Tandai dan Baca Akhir-akhir ini,” Chris Coyier, Trik-CSS
• “Panduan Mendalam Untuk Mengukur Vital Web Inti,” Barry Pollard, Majalah Smashing
• “Dari CSS Semantik Ke Tailwind: Refactoring The Netlify UI Codebase,” Charlie Gerard dan Leslie Cohn-Wein, Netlify
• “Alat Audit CSS,” Iris Lješnjanin, Majalah Smashing
• “Hal-hal yang Dapat Anda Lakukan Dengan CSS Hari Ini,” Andy Bell, Majalah Smashing
• “Cara Meningkatkan Kinerja CSS,” Milica Mihajlija, Kaliber
• “Kesenjangan Ketimpangan Kinerja Seluler, 2021,” Alex Russell
• “Mengoptimalkan Pemuatan Gambar Secara Maksimal Untuk Web Pada Tahun 2021,” Malte Ubl
• “Elemen <img> Rendah Hati Dan Vital Web Inti,” Addy Osmani, Majalah Smashing