Refactoring CSS: Mengoptimalkan Ukuran Dan Kinerja (Bagian 3)

Dalam artikel sebelumnya dari seri ini, kita telah membahas audit kesehatan basis kode CSS dan strategi, pengujian, dan pemeliharaan pemfaktoran ulang CSS inkremental. Terlepas dari seberapa banyak basis kode CSS telah ditingkatkan selama proses refactoring dan seberapa jauh lebih dapat dipertahankan dan diperpanjang, stylesheet terakhir perlu dioptimalkan untuk kinerja terbaik dan ukuran file seminimal mungkin.

Menyebarkan basis kode yang di-refactored seharusnya tidak menghasilkan kinerja situs web yang lebih buruk dan pengalaman pengguna yang lebih buruk. Lagi pula, pengguna tidak akan menunggu selamanya untuk memuat situs web. Selain itu, manajemen akan tidak puas dengan penurunan lalu lintas dan pendapatan yang disebabkan oleh basis kode yang tidak dioptimalkan, meskipun ada peningkatan kualitas kode.

Pada artikel ini, kita akan membahas strategi pengoptimalan CSS yang dapat mengoptimalkan ukuran file CSS, waktu pemuatan, dan kinerja render. Dengan begitu, basis kode CSS yang di-refactored tidak hanya lebih dapat dipelihara dan diperluas tetapi juga berkinerja dan mencentang semua kotak yang penting baik bagi pengguna akhir maupun manajemen.

Mengoptimalkan Ukuran File Stylesheet

Mengoptimalkan ukuran file bermuara pada menghapus karakter yang tidak perlu dan memformat dan mengoptimalkan kode CSS untuk menggunakan sintaks yang berbeda atau properti singkatan untuk mengurangi jumlah keseluruhan karakter dalam file.

Optimasi Dan Minifikasi

Optimalisasi dan minifikasi CSS telah ada selama bertahun-tahun dan menjadi pokok dalam pengoptimalan frontend. Alat seperti cssnano dan clean-css adalah salah satu alat favorit saya dalam hal pengoptimalan dan minifikasi CSS. Mereka menawarkan berbagai pilihan penyesuaian untuk lebih mengontrol bagaimana kode dioptimalkan dan browser mana yang didukung.

Alat-alat ini bekerja dengan cara yang sama. Pertama, kode yang tidak dioptimalkan diurai dan ditranspilasikan mengikuti aturan yang ditetapkan dalam konfigurasi. Hasilnya adalah kode yang menggunakan lebih sedikit karakter tetapi tetap mempertahankan pemformatan (jeda baris dan spasi putih).

 /* Before - original and unoptimized code */ .container { padding: 24px 16px 24px 16px; background: #222222; } /* After - optimized code with formatting */ .container { padding: 24px 16px; background: #222; }

Dan akhirnya, kode dioptimalkan yang ditranspilasikan diperkecil dengan menghapus semua pemformatan teks yang tidak perlu . Bergantung pada basis kode dan browser yang didukung yang diatur dalam konfigurasi, kode dengan awalan vendor yang tidak digunakan lagi juga dapat dihapus.

 /* Before - optimized code with formatting */ .container { padding: 24px 16px; background: #222; } /* After - optimized and minified code */ .container{padding:24px 16px;background:#222}

Bahkan dalam contoh dasar ini, kami telah berhasil mengurangi ukuran file keseluruhan dari 76 byte menjadi 55 byte, menghasilkan pengurangan 23%. Bergantung pada basis kode dan alat pengoptimalan serta konfigurasi, pengoptimalan dan minifikasi CSS dapat menjadi lebih efektif.

Optimalisasi dan minifikasi CSS dapat dianggap sebagai kemenangan mudah karena hasil yang signifikan hanya dengan beberapa penyesuaian pada alur kerja CSS. Itulah sebabnya minifikasi harus diperlakukan sebagai pengoptimalan kinerja minimum dan persyaratan untuk semua lembar gaya pada proyek.

Mengoptimalkan Kueri Media

Saat kami menulis kueri media dalam CSS, terutama saat menggunakan banyak file (PostCSS atau Sass), kami biasanya tidak menyarangkan kode di bawah kueri media tunggal untuk keseluruhan proyek. Untuk pemeliharaan yang lebih baik, modularitas, dan struktur kode, kami biasanya menulis ekspresi kueri media yang sama untuk beberapa komponen CSS.

Mari kita perhatikan contoh berikut dari basis kode CSS yang tidak dioptimalkan.

 .page { display: grid; grid-gap: 16px; } @media (min-width: 768px) { .page { grid-template-columns: 268px auto; grid-gap: 24px; } } /* ... */ .products-grid { display: grid; grid-template-columns: repeat(2, 1fr); grid-gap: 16px; } @media (min-width: 768px) { .products-grid { grid-template-columns: repeat(3, 1fr); grid-gap: 20px; } }

Seperti yang Anda lihat, kami memiliki @media (min-width: 768px) per komponen untuk keterbacaan dan pemeliharaan yang lebih baik. Mari kita jalankan optimasi dan minifikasi pada contoh kode ini dan lihat apa yang kita dapatkan.

 .page{display:grid;grid-gap:16px}@media (min-width: 768px){.page{grid-template-columns:268px auto;grid-gap:24px}}.products-grid{display:grid;grid-template-columns:repeat(2,1fr);grid-gap:16px}@media (min-width: 768px){.products-grid{grid-template-columns:repeat(3,1fr);grid-gap:20px}}

Ini mungkin agak sulit dibaca, tetapi yang harus kita perhatikan adalah kueri media @media (min-width: 768px) yang berulang. Kami telah menyimpulkan bahwa kami ingin mengurangi jumlah karakter dalam lembar gaya dan kami dapat menyarangkan beberapa pemilih di bawah satu kueri media, jadi mengapa minifier tidak menghapus ekspresi duplikat? Ada alasan sederhana untuk itu.

Urutan aturan penting dalam CSS, jadi untuk menggabungkan kueri media yang diduplikasi, blok kode perlu dipindahkan. Ini akan mengakibatkan urutan aturan diubah yang dapat menyebabkan efek samping yang tidak diinginkan dalam gaya.

Namun, menggabungkan kueri media berpotensi membuat ukuran file menjadi lebih kecil, tergantung pada basis kode dan strukturnya. Alat dan paket seperti postcss-sort-media-queries memungkinkan kami menghapus kueri media yang diduplikasi dan selanjutnya mengurangi ukuran file.

Tentu saja, ada peringatan penting untuk memiliki struktur basis kode CSS yang terstruktur dengan baik yang tidak bergantung pada urutan aturan. Pengoptimalan ini harus diperhitungkan saat merencanakan refactor CSS dan menetapkan aturan dasar.

Saya akan merekomendasikan untuk memeriksa terlebih dahulu apakah manfaat pengoptimalan melebihi potensi risikonya. Ini dapat dengan mudah dilakukan dengan menjalankan audit CSS dan memeriksa statistik kueri media. Jika ya, saya akan merekomendasikan untuk menambahkannya nanti dan menjalankan pengujian regresi otomatis untuk menangkap efek samping dan bug yang tidak terduga yang dapat terjadi sebagai hasilnya.

Menghapus CSS yang Tidak Digunakan

Selama proses pemfaktoran ulang, selalu ada kemungkinan bahwa Anda akan berakhir dengan beberapa gaya lama yang tidak digunakan yang belum sepenuhnya dihapus atau Anda akan memiliki beberapa gaya baru yang ditambahkan yang tidak digunakan. Gaya ini juga menambah jumlah karakter keseluruhan dan ukuran file. Menghilangkan gaya yang tidak digunakan ini menggunakan alat otomatis, bagaimanapun, bisa agak berisiko karena alat tidak dapat secara akurat memprediksi gaya mana yang benar-benar digunakan.

Alat seperti purgecss memeriksa semua file dalam proyek dan menggunakan semua kelas yang disebutkan dalam file sebagai pemilih, hanya untuk berhati-hati dan tidak sengaja menghapus pemilih untuk elemen dinamis yang disuntikkan JavaScript, di antara kasus potensial lainnya. Namun, purgecss menawarkan opsi konfigurasi yang fleksibel sebagai solusi untuk potensi masalah dan risiko ini.

Namun, perbaikan ini harus dilakukan hanya jika potensi manfaatnya lebih besar daripada risikonya . Selain itu, teknik pengoptimalan ini akan memerlukan waktu yang cukup lama untuk menyiapkan, mengonfigurasi, dan menguji, dan dapat menyebabkan masalah yang tidak diinginkan, jadi lanjutkan dengan hati-hati dan pastikan penyiapannya antipeluru.

Menghilangkan Render-Blocking CSS

Secara default, CSS adalah sumber daya yang memblokir perenderan, artinya situs web tidak akan ditampilkan kepada pengguna hingga semua lembar gaya yang ditautkan dan dependensinya (font, misalnya) telah diunduh dan diuraikan oleh browser.

Jika file stylesheet memiliki ukuran file yang besar atau beberapa dependensi yang terletak di server pihak ketiga atau CDN, rendering situs web dapat ditunda secara signifikan tergantung pada kecepatan dan keandalan jaringan.

Largest Contentful Paint (LCP) telah menjadi metrik penting dalam beberapa bulan terakhir. LCP tidak hanya penting untuk kinerja tetapi juga SEO — situs web dengan skor LCP yang lebih baik akan memiliki peringkat hasil pencarian yang lebih baik. Menghapus resource yang memblokir render seperti CSS adalah salah satu cara untuk meningkatkan skor LCP.

Namun, jika kita menunda pemuatan dan pemrosesan stylesheet, ini akan menghasilkan Flash Of Unstyled Content (FOUC) — konten akan segera ditampilkan kepada pengguna dan gaya akan dimuat dan diterapkan beberapa saat kemudian. Sakelar ini bisa terlihat menggelegar dan bahkan mungkin membingungkan beberapa pengguna.

CSS penting

Dengan CSS Kritis, kami dapat memastikan bahwa situs web dimuat dengan jumlah gaya minimum yang dijamin akan digunakan pada halaman saat pertama kali dirender. Dengan cara ini, kita dapat membuat FOUC kurang terlihat atau bahkan menghilangkannya untuk sebagian besar kasus. Misalnya, jika beranda menampilkan komponen header dengan navigasi dan komponen pahlawan yang terletak di paruh atas, ini berarti bahwa CSS penting akan berisi semua gaya global dan komponen yang diperlukan untuk komponen ini, sedangkan gaya untuk komponen lain di halaman akan ditangguhkan.

CSS ini digarisbawahi dalam HTML di bawah tag style , sehingga gaya dimuat dan diuraikan di samping file HTML. Meskipun ini akan menghasilkan ukuran file HTML yang sedikit lebih besar (yang juga harus diperkecil), semua CSS non-kritis lainnya akan ditangguhkan dan tidak akan langsung dimuat dan situs web akan dirender lebih cepat. Secara keseluruhan, manfaatnya lebih besar daripada peningkatan ukuran file HTML.

 <head> <style type="text/css"><!-- Minified Critical CSS markup --></style> </head>

Ada banyak alat otomatis dan paket NPM di luar sana, tergantung pada pengaturan Anda, yang dapat mengekstrak CSS penting dan menghasilkan lembar gaya yang ditangguhkan.

Menunda Stylesheet

Bagaimana tepatnya kita membuat CSS menjadi non-blocking? Kami tahu bahwa itu tidak boleh direferensikan di elemen head HTML saat HTML halaman pertama kali diunduh. Demian Renzulli telah menguraikan metode ini dalam artikelnya.

Tidak ada pendekatan HTML asli (sampai sekarang) untuk mengoptimalkan atau menunda pemuatan sumber daya yang memblokir perenderan, jadi kita perlu menggunakan JavaScript untuk memasukkan lembar gaya non-kritis ke dalam markup HTML setelah perenderan awal. Kami juga perlu memastikan bahwa gaya ini dimuat dengan cara yang tidak optimal (memblokir render) jika pengguna mengunjungi halaman dengan JavaScript yang tidak diaktifkan di browser.

 <!-- Deferred stylesheet --> <link rel="preload" as="style" href="path/to/stylesheet.css" onload="this.onload=null;this.rel='stylesheet'"> <!-- Fallback --> <noscript> <link rel="stylesheet" href="path/to/stylesheet.css"> </noscript>

Dengan link rel="preload" as="style" memastikan bahwa file stylesheet diminta secara asinkron, sedangkan onload JavaScript handler memastikan bahwa file dimuat dan diproses oleh browser setelah dokumen HTML selesai dimuat. Diperlukan beberapa pembersihan, jadi kita perlu mengatur onload ke null untuk menghindari fungsi ini berjalan beberapa kali dan menyebabkan rendering ulang yang tidak perlu.

Ini persis bagaimana Smashing Magazine menangani stylesheet-nya. Setiap template (beranda, kategori artikel, halaman artikel, dll.) memiliki CSS kritis khusus template yang disisipkan di dalam tag style HTML di elemen head , dan lembar gaya main.css yang ditangguhkan yang berisi semua gaya non-kritis.

Namun, alih-alih mengubah parameter rel , di sini kita dapat melihat kueri media dialihkan dari media print prioritas rendah yang ditangguhkan secara otomatis ke atribut all prioritas tinggi saat halaman selesai dimuat. Ini adalah alternatif, pendekatan yang sama-sama layak untuk menunda pemuatan stylesheet non-kritis.

 <link href="/css/main.css" media="print" onload="this.media='all'" rel="stylesheet">

Memisahkan Dan Memuat Secara Kondisional Stylesheet Dengan Media Query

Untuk kasus ketika file stylesheet akhir memiliki ukuran file besar bahkan setelah pengoptimalan yang disebutkan di atas telah diterapkan, Anda dapat membagi stylesheet menjadi beberapa file berdasarkan kueri media dan menggunakan properti media pada lembar gaya yang dirujuk dalam elemen HTML tautan untuk memuatnya secara kondisional .

 <link href="print.css" rel="stylesheet" media="print"> <link href="mobile.css" rel="stylesheet" media="all"> <link href="tablet.css" rel="stylesheet" media="screen and (min-width: 768px)"> <link href="desktop.css" rel="stylesheet" media="screen and (min-width: 1366px)">

Dengan begitu, jika pendekatan yang mengutamakan seluler digunakan, gaya untuk ukuran layar yang lebih besar tidak akan diunduh atau diuraikan di perangkat seluler yang dapat berjalan di jaringan yang lebih lambat atau tidak dapat diandalkan.

Hanya untuk mengulangi, metode ini harus digunakan jika hasil dari metode pengoptimalan yang disebutkan sebelumnya menghasilkan stylesheet dengan ukuran file yang kurang optimal. Untuk kasus biasa, metode pengoptimalan ini tidak akan efektif atau berdampak, bergantung pada ukuran lembar gaya individu.

Menunda File Font Dan Stylesheet

Menunda lembar gaya font (file Google Font, misalnya) juga dapat bermanfaat untuk kinerja render awal. Kami telah menyimpulkan bahwa stylesheet memblokir render, tetapi begitu juga file font yang direferensikan dalam stylesheet. File font juga menambahkan sedikit overhead ke kinerja render awal.

Memuat lembar gaya font dan file font adalah topik yang kompleks dan menyelam ke dalamnya akan membutuhkan artikel baru hanya untuk menjelaskan semua pendekatan yang layak. Untungnya, Zach Leatherman telah menguraikan banyak strategi yang layak dalam panduan komprehensif yang mengagumkan ini dan merangkum pro dan kontra dari setiap pendekatan. Jika Anda menggunakan Google Font, Harry Roberts telah menguraikan strategi untuk memuat Google Font tercepat.

Jika Anda memutuskan untuk menunda stylesheet font, Anda akan berakhir dengan Flash of Unstyled Text (FOUT). Halaman awalnya akan dirender dengan font fallback hingga file font dan stylesheet yang ditangguhkan telah diunduh dan diuraikan, di mana gaya baru akan diterapkan. Perubahan ini bisa sangat terlihat dan dapat menyebabkan pergeseran tata letak dan membingungkan pengguna, tergantung pada kasus masing-masing.

Barry Pollard telah menguraikan beberapa strategi yang dapat membantu kami menangani FOUT dan berbicara tentang fitur CSS penyesuaian ukuran yang akan datang yang akan memberikan cara yang lebih mudah dan lebih asli untuk menangani FOUT.

Pengoptimalan Sisi Server

Kompresi HTTP

Selain minifikasi dan optimasi ukuran file, aset statis seperti HTML, file CSS, file JavaScript, dll. Algoritma kompresi HTTP seperti Gzip dan Brotli dapat digunakan untuk mengurangi ukuran file yang diunduh.

Kompresi HTTP perlu dikonfigurasi di server yang bergantung pada tumpukan teknologi dan konfigurasi. Namun, manfaat kinerja dapat bervariasi dan mungkin tidak berdampak sebanyak minifikasi dan pengoptimalan stylesheet standar, karena browser masih akan mendekompresi file terkompresi dan harus menguraikannya.

Caching Stylesheets

Caching file statis adalah strategi pengoptimalan yang berguna. Peramban masih harus mengunduh file statis dari server pada pemuatan pertama, tetapi setelah di-cache, file akan dimuat langsung pada permintaan berikutnya, mempercepat proses pemuatan.

Caching dapat dikontrol melalui header HTTP Cache-Control di tingkat server (misalnya, menggunakan file .htaccess di server Apache).

Dengan max-age kami dapat menunjukkan berapa lama file harus tetap di-cache (dalam detik) di browser dan dengan public , kami menunjukkan bahwa file dapat di-cache oleh browser dan cache lainnya.

 Cache-Control: public, max-age=604800

Strategi cache yang lebih agresif dan efektif untuk aset statis dapat dicapai dengan konfigurasi yang immutable . Ini memberitahu browser bahwa file khusus ini tidak akan pernah berubah dan bahwa setiap pembaruan baru akan mengakibatkan file ini terhapus dan file baru dengan nama file yang berbeda akan menggantikannya. Ini dikenal sebagai cache-busting .

 Cache-Control: public, max-age=604800, immutable

Tanpa strategi penghilang cache yang tepat , ada risiko kehilangan kendali atas file yang di-cache di browser pengguna. Artinya jika file tersebut diubah, browser tidak akan dapat mengetahui bahwa ia harus mengunduh file yang diperbarui dan tidak menggunakan file cache yang kedaluwarsa. Dan sejak saat itu, hampir tidak ada yang bisa kami lakukan untuk memperbaikinya dan pengguna akan terjebak dengan file yang sudah usang hingga kedaluwarsa.

Untuk stylesheet, itu bisa berarti bahwa jika kita memperbarui file HTML dengan konten dan komponen baru yang memerlukan gaya baru, gaya ini tidak akan ditampilkan karena stylesheet usang di-cache tanpa strategi penghilang cache dan browser tidak akan mengetahuinya. itu harus mengunduh file baru.

Sebelum menggunakan strategi caching untuk stylesheet atau file statis lainnya, mekanisme penghilang cache yang efektif harus diterapkan untuk mencegah file statis usang agar tidak tersangkut di cache pengguna. Anda dapat menggunakan salah satu mekanisme pembuatan versi berikut untuk penghilang cache:

• Menambahkan string kueri ke nama file.
  Misalnya styles.css?v=1.0.1. Namun, beberapa CDN dapat sepenuhnya mengabaikan atau menghapus string kueri dari nama file dan mengakibatkan file macet di cache pengguna dan tidak pernah diperbarui.
• Mengubah nama file atau menambahkan hash.
  Misalnya styles.a1bc2.css atau styles.v1.0.1.css. Ini lebih andal dan efektif daripada menambahkan string kueri ke nama file.

CDN Atau Self-hosting?

Jaringan Pengiriman Konten (CDN) adalah sekelompok server yang didistribusikan secara geografis yang biasanya digunakan untuk pengiriman aset statis yang andal dan cepat seperti gambar, video, file HTML, file CSS, file JavaScript, dll.

Meskipun CDN mungkin tampak seperti alternatif yang bagus untuk aset statis yang menghosting sendiri, Harry Roberts telah melakukan penelitian mendalam tentang topik tersebut dan menyimpulkan bahwa aset yang menghosting sendiri lebih bermanfaat untuk kinerja.

“Ada sedikit alasan untuk meninggalkan aset statis Anda di infrastruktur orang lain. Manfaat yang dirasakan sering kali merupakan mitos, dan bahkan jika tidak, pengorbanannya tidak sepadan. Memuat aset dari berbagai sumber terbukti lebih lambat.”

Karena itu, saya akan merekomendasikan hosting sendiri stylesheet (termasuk font stylesheet, jika mungkin) secara default dan pindah ke CDN hanya jika ada alasan yang layak atau manfaat lain untuk melakukannya.

Mengaudit Ukuran dan Kinerja File CSS

WebPageTest dan alat audit kinerja serupa lainnya dapat digunakan untuk mendapatkan gambaran rinci tentang proses pemuatan situs web, ukuran file, sumber daya pemblokiran render, dll. Alat ini dapat memberi Anda wawasan tentang bagaimana situs web Anda dimuat di berbagai perangkat — dari PC desktop yang berjalan di jaringan berkecepatan tinggi hingga smartphone kelas bawah yang berjalan di jaringan yang lambat dan tidak dapat diandalkan.

Mari lakukan audit kinerja di situs web yang disebutkan dalam artikel pertama dari seri ini — yang memiliki 2MB CSS yang diperkecil.

Pertama, kita akan melihat perincian konten untuk menentukan sumber daya mana yang menggunakan bandwidth paling banyak. Dari bagan berikut, kita dapat melihat bahwa gambar menerima sebagian besar permintaan, artinya mereka harus dimuat dengan lambat. Dari bagan kedua, kita dapat melihat bahwa file stylesheet dan JavaScript adalah yang terbesar dalam hal ukuran file. Ini adalah indikasi yang baik bahwa file-file ini perlu diperkecil dan dioptimalkan, difaktorkan ulang, atau dipecah menjadi beberapa file dan dimuat secara asinkron.

Kita dapat menarik lebih banyak kesimpulan dari grafik Web Vitals. Dengan melihat bagan Largest Contentful Paint (LCP), kita bisa mendapatkan gambaran rinci tentang sumber daya yang memblokir render dan seberapa besar pengaruhnya terhadap render awal.

Kami sudah dapat menyimpulkan bahwa stylesheet situs web akan memiliki dampak paling besar pada LCP dan statistik pemuatan. Namun, kita dapat melihat lembar gaya font, file JavaScript, dan gambar yang dirujuk di dalam lembar gaya yang juga memblokir render. Mengetahui bahwa kami dapat menerapkan metode pengoptimalan yang disebutkan di atas untuk mengurangi waktu LCP dengan menghilangkan sumber daya yang memblokir render.

Kesimpulan

Proses refactoring tidak lengkap ketika kesehatan dan kualitas kode telah ditingkatkan dan ketika kelemahan dan masalah basis kode telah diperbaiki. Basis kode yang difaktorkan ulang harus menghasilkan kinerja yang sama atau lebih baik dibandingkan dengan basis kode lama.

Pengguna akhir seharusnya tidak mengalami masalah kinerja atau waktu pemuatan yang lama dari basis kode yang difaktorkan ulang. Untungnya, ada banyak metode di luar sana untuk memastikan bahwa basis kode kuat dan berkinerja baik — mulai dari metode minifikasi dan pengoptimalan sederhana hingga metode yang lebih kompleks seperti menghilangkan sumber daya yang memblokir render dan pemecahan kode.

Kami dapat menggunakan berbagai alat audit kinerja seperti WebPageTest untuk mendapatkan gambaran rinci tentang waktu pemuatan, kinerja, sumber daya pemblokiran render, dan faktor lainnya sehingga kami dapat mengatasi masalah ini lebih awal dan efektif.

Referensi

• “Render Blocking CSS,” Ilya Grigorik
• “Tunda CSS Non-Kritis,” Demian Renzulli
• “Panduan Komprehensif Untuk Strategi Pemuatan Font,” Zach Leatherman
• “Cara Baru Untuk Mengurangi Dampak Pemuatan Font: Deskriptor Font CSS,” Barry Pollard
• “Self-Host Aset Statis Anda,” Harry Roberts
• “Optimalkan Pemuatan dan Rendering WebFont,” Ilya Grigorik