Di Google IO 2018, kami menyajikan rangkuman alat, library, dan teknik pengoptimalan yang memudahkan peningkatan performa web. Di sini, kami menjelaskannya menggunakan aplikasi The Oodles Theater. Kami juga membahas eksperimen kami dengan pemuatan prediktif dan inisiatif Guess.js baru.
Kami cukup sibuk selama setahun terakhir mencoba mencari cara untuk membuat Web lebih cepat dan lebih berperforma. Hal ini menghasilkan alat, pendekatan, dan library baru yang ingin kami bagikan kepada Anda dalam artikel ini. Di bagian pertama, kami akan menunjukkan beberapa teknik pengoptimalan yang kami gunakan dalam praktik saat mengembangkan aplikasi Oodles Theater. Di bagian kedua, kami akan membahas eksperimen kami dengan pemuatan prediktif dan inisiatif Guess.js baru.
Kebutuhan akan performa
Internet menjadi semakin berat setiap tahunnya. Jika kita memeriksa status web, kita dapat melihat bahwa halaman median di perangkat seluler berukuran sekitar 1,5 MB, dengan sebagian besar berupa JavaScript dan gambar.
Ukuran situs yang terus bertambah, bersama dengan faktor lain, seperti latensi jaringan, batasan CPU, pola pemblokiran render, atau kode pihak ketiga yang berlebihan, berkontribusi pada teka-teki performa yang rumit.
Sebagian besar pengguna menilai kecepatan sebagai hal yang paling penting dalam hierarki kebutuhan UX mereka. Hal ini tidak terlalu mengejutkan, karena Anda tidak dapat melakukan banyak hal hingga halaman selesai dimuat. Anda tidak dapat memperoleh nilai dari halaman tersebut, Anda tidak dapat mengagumi estetikanya.
Kami tahu bahwa performa penting bagi pengguna, tetapi mungkin sulit untuk mengetahui dari mana harus memulai pengoptimalan. Untungnya, ada alat yang dapat membantu Anda dalam prosesnya.
Lighthouse - Dasar untuk alur kerja performa
Lighthouse adalah bagian dari Chrome DevTools yang memungkinkan Anda mengaudit situs, dan memberi Anda petunjuk tentang cara meningkatkannya.
Baru-baru ini kami meluncurkan sejumlah audit performa baru yang sangat berguna dalam alur kerja pengembangan sehari-hari.
Mari kita pelajari cara memanfaatkannya dalam contoh praktis: Aplikasi Oodles Theater. Ini adalah aplikasi web demo kecil, tempat Anda dapat mencoba beberapa Google Doodle interaktif favorit kami dan bahkan memainkan satu atau dua game.
Saat membangun aplikasi, kami ingin memastikan bahwa aplikasi tersebut memiliki performa sebaik mungkin. Titik awal pengoptimalan adalah laporan Lighthouse.
Performa awal aplikasi kami seperti yang terlihat di laporan Lighthouse cukup buruk. Di jaringan 3G, pengguna harus menunggu selama 15 detik untuk first meaningful paint, atau agar aplikasi menjadi interaktif. Lighthouse menyoroti banyak masalah pada situs kami, dan skor performa keseluruhan sebesar 23 mencerminkan hal tersebut.
Halaman ini berukuran sekitar 3,4 MB - kami sangat perlu mengurangi ukurannya.
Hal ini memulai tantangan performa pertama kami: menemukan hal-hal yang dapat kami hapus dengan mudah tanpa memengaruhi pengalaman secara keseluruhan.
Peluang pengoptimalan performa
Menghapus resource yang tidak diperlukan
Ada beberapa hal yang jelas dapat dihapus dengan aman: spasi kosong dan komentar.
Lighthouse menyoroti peluang ini dalam audit CSS & JavaScript yang tidak diminifikasi. Kami menggunakan webpack untuk proses build, jadi untuk mendapatkan minifikasi, kami cukup menggunakan plugin Uglify JS.
Minifikasi adalah tugas umum, jadi Anda seharusnya dapat menemukan solusi siap pakai untuk proses build apa pun yang Anda gunakan.
Audit lain yang berguna di ruang tersebut adalah Aktifkan kompresi teks. Tidak ada alasan untuk mengirim file yang tidak dikompresi, dan sebagian besar CDN mendukung hal ini secara langsung saat ini.
Kami menggunakan Firebase Hosting untuk menghosting kode, dan Firebase mengaktifkan gzipping secara default, jadi dengan menghosting kode di CDN yang memadai, kami mendapatkannya secara gratis.
Meskipun gzip adalah cara kompresi yang sangat populer, mekanisme lain seperti Zopfli dan Brotli juga semakin populer. Brotli didukung di sebagian besar browser, dan Anda dapat menggunakan biner untuk mengompresi aset terlebih dahulu sebelum mengirimkannya ke server.
Menggunakan kebijakan cache yang efisien
Langkah berikutnya adalah memastikan bahwa kita tidak mengirim resource dua kali jika tidak diperlukan.
Audit Kebijakan cache yang tidak efisien di Lighthouse membantu kami menyadari bahwa kami dapat mengoptimalkan strategi caching untuk mencapai hal tersebut. Dengan menetapkan header masa berlaku max-age di server, kami memastikan bahwa pada kunjungan berulang, pengguna dapat menggunakan kembali resource yang telah mereka download sebelumnya.
Idealnya, Anda harus menargetkan untuk meng-cache sebanyak mungkin resource dengan aman untuk jangka waktu yang paling lama dan memberikan token validasi untuk validasi ulang yang efisien dari resource yang telah diperbarui.
Menghapus kode yang tidak digunakan
Sejauh ini, kita telah menghapus bagian yang jelas dari download yang tidak diperlukan, tetapi bagaimana dengan bagian yang kurang jelas? Misalnya, kode yang tidak digunakan.
Terkadang, kita menyertakan kode yang tidak terlalu diperlukan dalam aplikasi kita. Hal ini terjadi terutama jika Anda mengerjakan aplikasi dalam jangka waktu yang lebih lama, tim atau dependensi Anda berubah, dan terkadang library tanpa induk tertinggal. Itulah yang terjadi pada kami.
Awalnya, kami menggunakan library Komponen Material untuk membuat prototipe aplikasi dengan cepat. Seiring waktu, kami beralih ke tampilan dan nuansa yang lebih kustom dan sepenuhnya melupakan library tersebut. Untungnya, pemeriksaan cakupan kode membantu kami menemukannya kembali dalam paket.
Anda dapat memeriksa statistik cakupan kode di DevTools, baik untuk runtime maupun waktu pemuatan aplikasi Anda. Anda dapat melihat dua garis merah besar di screenshot bawah - lebih dari 95% CSS kami tidak digunakan, dan juga banyak JavaScript.
Lighthouse juga mendeteksi masalah ini dalam audit aturan CSS yang tidak digunakan. Laporan ini menunjukkan potensi penghematan lebih dari 400 kb. Jadi, kami kembali ke kode dan menghapus bagian JavaScript dan CSS dari library tersebut.
Hal ini mengurangi paket CSS kami sebanyak 20 kali lipat, yang cukup bagus untuk commit kecil sepanjang dua baris.
Tentu saja, hal ini meningkatkan skor performa kami, dan juga Time to Interactive menjadi jauh lebih baik.
Namun, dengan perubahan seperti ini, memeriksa metrik dan skor saja tidak cukup. Menghapus kode yang sebenarnya tidak pernah bebas risiko, jadi Anda harus selalu mewaspadai potensi regresi.
Kode kami tidak digunakan di 95% - masih ada 5% ini di suatu tempat. Ternyata salah satu komponen kami masih menggunakan gaya dari library tersebut, yaitu panah kecil di penggeser doodle. Namun, karena ukurannya sangat kecil, kita dapat langsung memasukkan kembali gaya tersebut ke dalam tombol secara manual.
Jadi, jika Anda menghapus kode, pastikan Anda memiliki alur kerja pengujian yang tepat untuk membantu Anda mencegah potensi regresi visual.
Hindari payload jaringan yang sangat besar
Kita tahu bahwa resource yang besar dapat memperlambat pemuatan halaman web. Hal ini dapat merugikan pengguna dan berdampak besar pada paket data mereka, jadi sangat penting untuk memperhatikan hal ini.
Lighthouse dapat mendeteksi bahwa kami mengalami masalah dengan beberapa payload jaringan menggunakan audit Payload jaringan yang sangat besar.
Di sini, kami melihat bahwa kami memiliki kode berukuran lebih dari 3 MB yang dikirimkan – jumlah yang cukup besar, terutama di perangkat seluler.
Di bagian paling atas daftar ini, Lighthouse menyoroti bahwa kita memiliki paket vendor JavaScript yang merupakan kode tanpa kompresi sebesar 2 MB. Masalah ini juga disoroti oleh webpack.
Seperti kata pepatah: permintaan tercepat adalah permintaan yang tidak dibuat.
Idealnya, Anda harus mengukur nilai setiap aset yang Anda tayangkan kepada pengguna, mengukur performa aset tersebut, dan memutuskan apakah aset tersebut benar-benar layak dikirimkan dengan pengalaman awal. Karena terkadang aset ini dapat ditangguhkan, atau dimuat lambat, atau diproses selama waktu tidak ada aktivitas.
Dalam kasus kami, karena kami menangani banyak paket JavaScript, kami beruntung karena komunitas JavaScript memiliki beragam alat audit paket JavaScript.
Kami memulai dengan webpack bundle analyzer, yang memberi tahu kami bahwa kami menyertakan dependensi bernama unicode yang merupakan JavaScript yang diuraikan sebesar 1,6 MB, jadi cukup banyak.
Kemudian, kami membuka editor dan menggunakan Plugin Import Cost untuk Visual Code untuk memvisualisasikan biaya setiap modul yang kami impor. Dengan demikian, kami dapat menemukan komponen mana yang menyertakan kode yang merujuk ke modul ini.
Kemudian, kami beralih ke alat lain, BundlePhobia. Ini adalah alat yang memungkinkan Anda memasukkan nama paket NPM apa pun dan benar-benar melihat perkiraan ukuran yang diminifikasi dan di-gzip. Kami menemukan alternatif yang bagus untuk modul slug yang kami gunakan, yang hanya berukuran 2,2 kb, jadi kami beralih ke modul tersebut.
Hal ini berdampak besar pada performa kami. Dengan perubahan ini dan penemuan peluang lain untuk mengurangi ukuran paket JavaScript, kami menghemat 2,1 MB kode.
Kami melihat peningkatan keseluruhan sebesar 65%, setelah Anda memperhitungkan ukuran paket yang di-gzip dan diminifikasi. Kami mendapati bahwa proses ini sangat layak dilakukan.
Jadi, secara umum, cobalah untuk menghilangkan download yang tidak perlu di situs dan aplikasi Anda. Membuat inventaris aset dan mengukur dampak performanya dapat memberikan perbedaan yang sangat besar, jadi pastikan Anda mengaudit aset secara rutin.
Mempersingkat waktu booting JavaScript dengan pemisahan kode
Meskipun payload jaringan yang besar dapat berdampak besar pada aplikasi kita, ada hal lain yang dapat berdampak sangat besar, yaitu JavaScript.
JavaScript adalah aset termahal Anda. Di perangkat seluler, jika Anda mengirimkan paket JavaScript yang besar, hal ini dapat menunda seberapa cepat pengguna dapat berinteraksi dengan komponen antarmuka pengguna Anda. Artinya, mereka dapat mengetuk UI tanpa ada hal berarti yang benar-benar terjadi. Jadi, penting bagi kita untuk memahami mengapa JavaScript memerlukan biaya yang sangat besar.
Berikut cara browser memproses JavaScript.
Pertama-tama, kita harus mendownload skrip tersebut. Kita memiliki mesin JavaScript yang kemudian perlu mengurai kode tersebut, mengompilasinya, dan mengeksekusinya.
Fase-fase ini tidak memerlukan banyak waktu pada perangkat kelas atas seperti mesin desktop atau laptop, bahkan mungkin ponsel kelas atas. Namun, di ponsel median, proses ini dapat memerlukan waktu antara lima hingga sepuluh kali lebih lama. Hal inilah yang menunda interaktivitas, jadi penting bagi kita untuk mencoba memangkasnya.
Untuk membantu Anda menemukan masalah ini pada aplikasi, kami memperkenalkan audit waktu booting JavaScript baru ke Lighthouse.
Dan dalam kasus aplikasi Oodle, aplikasi ini memberi tahu kami bahwa kami menghabiskan waktu 1,8 detik dalam boot-up JavaScript. Yang terjadi adalah kami mengimpor semua rute dan komponen secara statis ke dalam satu paket JavaScript monolitik.
Salah satu teknik untuk mengatasi hal ini adalah menggunakan pemisahan kode.
Pemisahan kode adalah konsep yang memungkinkan Anda memberikan JavaScript kepada pengguna secara bertahap sesuai kebutuhan, bukan sekaligus.
Pemisahan kode dapat diterapkan di tingkat rute atau tingkat komponen. Alat ini berfungsi dengan baik dengan React dan React Loadable, Vue.js, Angular, Polymer, Preact, dan beberapa library lainnya.
Kami menggabungkan pemisahan kode ke dalam aplikasi, kami beralih dari impor statis ke impor dinamis, sehingga kami dapat memuat kode secara asinkron sesuai kebutuhan.
Dampaknya adalah memperkecil ukuran paket, tetapi juga mengurangi waktu booting JavaScript. Waktu pemuatan turun menjadi 0,78 detik, sehingga aplikasi menjadi 56% lebih cepat.
Secara umum, jika Anda membangun pengalaman yang menggunakan banyak JavaScript, pastikan untuk hanya mengirim kode yang diperlukan pengguna.
Manfaatkan konsep seperti pemisahan kode, pelajari ide seperti tree shaking, dan lihat repositori webpack-libs-optimizations untuk mendapatkan beberapa ide tentang cara mengurangi ukuran library jika Anda menggunakan webpack.
Mengoptimalkan gambar
Di aplikasi Oodle, kita menggunakan banyak gambar. Sayangnya, Lighthouse tidak terlalu antusias dengan hal ini seperti kami. Faktanya, kita gagal dalam ketiga audit terkait gambar.
Kita lupa mengoptimalkan gambar, tidak mengukur ukurannya dengan benar, dan juga kita bisa mendapatkan beberapa keuntungan dari penggunaan format gambar lain.
Kami mulai dengan mengoptimalkan gambar.
Untuk pengoptimalan satu kali, Anda dapat menggunakan alat visual seperti ImageOptim atau XNConvert.
Pendekatan yang lebih otomatis adalah menambahkan langkah pengoptimalan gambar ke proses build, dengan library seperti imagemin.
Dengan cara ini, Anda memastikan bahwa gambar yang ditambahkan pada masa mendatang akan dioptimalkan secara otomatis. Beberapa CDN, misalnya Akamai atau solusi pihak ketiga seperti Cloudinary, Fastly, atau Uploadcare menawarkan solusi pengoptimalan gambar yang komprehensif. Jadi, Anda juga dapat menghosting gambar di layanan tersebut.
Jika Anda tidak ingin melakukannya karena masalah biaya atau latensi, project seperti Thumbor atau Imageflow menawarkan alternatif yang dihosting sendiri.
PNG latar belakang kami ditandai di webpack sebagai besar, dan memang demikian. Setelah mengukur ukurannya dengan benar ke area pandang dan menjalankannya melalui ImageOptim, ukurannya turun menjadi 100 kb, yang dapat diterima.
Mengulangi hal ini untuk beberapa gambar di situs kami memungkinkan kami mengurangi bobot halaman secara keseluruhan secara signifikan.
Menggunakan format yang tepat untuk konten animasi
GIF bisa sangat mahal. Anehnya, format GIF awalnya tidak pernah dimaksudkan sebagai platform animasi. Oleh karena itu, beralih ke format video yang lebih sesuai akan menghemat ukuran file secara signifikan.
Di aplikasi Oodle, kami menggunakan GIF sebagai urutan intro di halaman beranda. Menurut Lighthouse, kita dapat menghemat lebih dari 7 MB dengan beralih ke format video yang lebih efisien. Klip kami berukuran sekitar 7,3 MB, terlalu besar untuk situs yang wajar, jadi kami mengubahnya menjadi elemen video dengan dua file sumber - MP4 dan WebM untuk dukungan browser yang lebih luas.
Kami menggunakan alat FFmpeg untuk mengonversi GIF animasi menjadi file mp4. Format WebM menawarkan penghematan yang lebih besar - ImageOptim API dapat melakukan konversi tersebut untuk Anda.
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
Kami berhasil menghemat lebih dari 80% bobot keseluruhan berkat konversi ini. Hal ini mengurangi ukuran file menjadi sekitar 1 MB.
Namun, 1 MB adalah resource yang besar untuk dikirim, terutama bagi pengguna dengan bandwidth terbatas. Untungnya, kita dapat menggunakan Effective Type API untuk mengetahui bahwa mereka menggunakan bandwidth yang lambat, dan memberikan JPEG yang jauh lebih kecil.
Antarmuka ini menggunakan waktu round-trip efektif dan nilai download untuk memperkirakan jenis jaringan yang digunakan pengguna. API ini hanya menampilkan string, 2G lambat, 2G, 3G, atau 4G. Jadi, bergantung pada nilai ini, jika pengguna menggunakan jaringan di bawah 4G, kita dapat mengganti elemen video dengan gambar.
if (navigator.connection.effectiveType) { ... }
Hal ini memang sedikit mengurangi pengalaman, tetapi setidaknya situs dapat digunakan pada koneksi yang lambat.
Pemuatan lambat gambar di luar layar
Carousel, penggeser, atau halaman yang sangat panjang sering kali memuat gambar, meskipun pengguna tidak dapat langsung melihatnya di halaman.
Lighthouse akan menandai perilaku ini dalam audit gambar di luar layar, dan Anda juga dapat melihatnya sendiri di panel jaringan DevTools. Jika Anda melihat banyak gambar masuk, sementara hanya beberapa yang terlihat di halaman, sebaiknya pertimbangkan untuk menggunakan pemuatan lambat.
Pemuatan lambat belum didukung secara native di browser, jadi kita harus menggunakan JavaScript untuk menambahkan kemampuan ini. Kami menggunakan library Lazysizes untuk menambahkan perilaku pemuatan lambat ke sampul Oodle.
<!-- Import library -->
import lazysizes from 'lazysizes' <!-- or -->
<script src="lazysizes.min.js"></script>
<!-- Use it -->
<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w"/>
Lazysizes cerdas karena tidak hanya melacak perubahan visibilitas elemen, tetapi juga
secara proaktif mengambil data elemen yang berada di dekat tampilan untuk pengalaman pengguna yang optimal.
Fitur ini juga menawarkan integrasi opsional IntersectionObserver, yang memberi Anda
pencarian visibilitas yang sangat efisien.
Setelah perubahan ini, image kita akan diambil sesuai permintaan. Jika Anda ingin mempelajari topik tersebut lebih dalam, lihat images.guide - referensi yang sangat berguna dan komprehensif.
Membantu browser mengirimkan resource penting lebih awal
Tidak setiap byte yang dikirim melalui jaringan ke browser memiliki tingkat kepentingan yang sama, dan browser mengetahuinya. Banyak browser memiliki heuristik untuk memutuskan apa yang harus diambil terlebih dahulu. Jadi, terkadang browser akan mengambil CSS sebelum gambar atau skrip.
Hal yang dapat berguna adalah kita, sebagai penulis halaman, memberi tahu browser apa yang
sebenarnya sangat penting bagi kita. Untungnya, selama beberapa tahun terakhir, vendor browser telah
menambahkan sejumlah fitur untuk membantu kita dalam hal ini, misalnya
petunjuk resource seperti link rel=preconnect,
atau preload atau prefetch.
Kemampuan yang dihadirkan ke platform web ini membantu browser mengambil hal yang tepat pada waktu yang tepat, dan dapat sedikit lebih efisien daripada beberapa pendekatan berbasis logika pemuatan kustom yang dilakukan menggunakan skrip.
Mari kita lihat bagaimana Lighthouse memandu kita untuk menggunakan beberapa fitur ini secara efektif.
Hal pertama yang disarankan Lighthouse adalah menghindari beberapa perjalanan pulang pergi yang mahal ke origin mana pun.
Dalam kasus aplikasi Oodle, kami sebenarnya sangat sering menggunakan Google Fonts. Setiap kali Anda memasukkan stylesheet Google Font ke halaman, stylesheet tersebut akan terhubung ke maksimal dua subdomain. Dan yang diberitahukan Lighthouse kepada kita adalah bahwa jika kita dapat mempercepat koneksi tersebut, kita dapat menghemat hingga 300 milidetik dalam waktu koneksi awal.
Dengan memanfaatkan link rel preconnect, kita dapat menyamarkan latensi koneksi tersebut secara efektif.
Terutama dengan sesuatu seperti Google Fonts, tempat CSS font-face kami dihosting di googleapis.com, dan resource font kami dihosting di Gstatic, hal ini dapat memberikan dampak yang sangat besar. Jadi, kami menerapkan pengoptimalan ini dan berhasil menghemat beberapa ratus milidetik.
Hal berikutnya yang disarankan Lighthouse adalah melakukan pramuat permintaan utama.
<link rel=preload> sangat efektif, karena memberi tahu browser bahwa resource diperlukan sebagai
bagian dari navigasi saat ini, dan mencoba membuat browser mengambilnya sesegera mungkin.
Di sini, Lighthouse memberi tahu kita bahwa kita harus melakukan pramuat resource font web utama, karena kita memuat dua font web.
Pramuat dalam font web terlihat seperti ini - menentukan rel=preload, Anda meneruskan as dengan
jenis font, lalu Anda menentukan jenis font yang ingin Anda muat, seperti woff2.
Dampak yang dapat ditimbulkan pada halaman Anda cukup signifikan.
Biasanya, tanpa menggunakan link rel preload, jika font web ternyata penting untuk halaman Anda, browser harus mengambil HTML Anda terlebih dahulu, harus mengurai CSS Anda, dan di suatu tempat yang jauh lebih lambat, browser akhirnya akan mengambil font web Anda.
Dengan menggunakan link rel preload, segera setelah browser mengurai HTML, browser dapat mulai mengambil font web tersebut jauh lebih awal. Dalam kasus aplikasi kami, hal ini dapat menghemat satu detik dari waktu yang diperlukan untuk merender teks menggunakan font web kami.
Namun, jika Anda mencoba melakukan pramuat font menggunakan Google Fonts, ada satu hal yang perlu diperhatikan.
URL Google Fonts yang kami tentukan pada font-face di stylesheet kami ternyata merupakan sesuatu yang cukup sering diperbarui oleh tim font. URL ini dapat habis masa berlakunya, atau diperbarui secara berkala, jadi sebaiknya Anda menghosting sendiri font web jika ingin memiliki kontrol penuh atas pengalaman pemuatan font. Hal ini dapat bermanfaat karena memberi Anda akses ke hal-hal seperti link rel preload.
Dalam kasus kami, kami menemukan alat Google Web Fonts Helper sangat berguna dalam membantu kami membuat beberapa font web tersebut tersedia secara offline dan menyiapkannya secara lokal, jadi lihat alat tersebut.
Baik Anda menggunakan font web sebagai bagian dari resource penting, atau kebetulan menggunakan JavaScript, cobalah membantu browser mengirimkan resource penting Anda secepat mungkin.
Eksperimental: Petunjuk Prioritas
Kami punya sesuatu yang spesial untuk dibagikan kepada Anda hari ini. Selain fitur seperti petunjuk resource, serta pramuat, kami telah mengerjakan fitur browser eksperimental baru yang kami sebut petunjuk prioritas.
Ini adalah fitur baru yang memungkinkan Anda memberi petunjuk kepada browser tentang seberapa penting suatu resource. Fitur ini mengekspos atribut baru - importance - dengan nilai low, high, atau auto.
Hal ini memungkinkan kita untuk menurunkan prioritas resource yang kurang penting, seperti gaya, gambar, atau panggilan API pengambilan yang tidak penting untuk mengurangi pertentangan. Kita juga dapat meningkatkan prioritas hal-hal yang lebih penting, seperti banner besar.
Dalam kasus aplikasi Oodle, hal ini mengarah pada satu tempat praktis yang dapat kita optimalkan.
Sebelum kami menambahkan pemuatan lambat ke gambar, browser akan mengambil semua gambar di awal carousel dengan prioritas tinggi sejak awal. Sayangnya, gambar di tengah carousel adalah yang paling penting bagi pengguna. Jadi, yang kami lakukan adalah menetapkan tingkat kepentingan gambar latar belakang tersebut ke sangat rendah, dan gambar latar depan ke sangat tinggi. Hal ini memberikan dampak dua detik pada koneksi 3G yang lambat, dan seberapa cepat kami dapat mengambil dan merender gambar tersebut. Jadi, pengalaman positif yang menyenangkan.
Kami berharap dapat menghadirkan fitur ini ke Canary dalam beberapa minggu, jadi nantikan kehadirannya.
Memiliki strategi pemuatan font web
Tipografi adalah hal mendasar untuk desain yang baik, dan jika Anda menggunakan font web, idealnya Anda tidak ingin memblokir rendering teks, dan Anda pasti tidak ingin menampilkan teks yang tidak terlihat.
Kami menyoroti hal ini di Lighthouse sekarang, dengan audit hindari teks yang tidak terlihat saat font web dimuat.
Jika Anda memuat font web menggunakan blok font face, Anda mengizinkan browser memutuskan apa yang harus dilakukan jika font web tersebut memerlukan waktu lama untuk diambil. Beberapa browser akan menunggu hingga tiga detik untuk hal ini sebelum beralih ke font sistem, dan pada akhirnya akan menukarnya dengan font tersebut setelah didownload.
Kami mencoba menghindari teks yang tidak terlihat ini, jadi dalam kasus ini, kami tidak akan dapat melihat doodle klasik minggu ini jika font web memerlukan waktu terlalu lama. Untungnya, dengan fitur baru yang disebut
font-display, Anda sebenarnya mendapatkan lebih banyak kontrol atas proses ini.
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-display: swap;
font-weight: 400;
src: local('Montserrat Regular'), local('Montserrat-Regular'),
/* Chrome 26+, Opera 23+, Firefox 39+ */
url('montserrat-v12-latin-regular.woff2') format('woff2'),
/* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
url('montserrat-v12-latin-regular.woff') format('woff');
}
Tampilan font membantu Anda memutuskan cara font web akan dirender atau di-fallback berdasarkan waktu yang diperlukan untuk menukarnya.
Dalam hal ini, kita menggunakan font-display: swap. Swap memberikan periode pemblokiran nol detik pada font, dan periode pertukaran yang tak terbatas. Artinya, browser akan segera menggambar teks Anda dengan font pengganti jika font memerlukan waktu untuk dimuat. Dan browser akan menukarnya setelah font face tersedia.
Dalam kasus aplikasi kami, hal ini sangat bagus karena memungkinkan kami menampilkan beberapa teks yang bermakna sejak awal, dan beralih ke font web setelah siap.
Secara umum, jika Anda menggunakan font web, seperti yang dilakukan sebagian besar web, miliki strategi pemuatan font web yang baik.
Ada banyak fitur platform web yang dapat Anda gunakan untuk mengoptimalkan pengalaman pemuatan font, tetapi lihat juga repo Web Font Recipes Zach Leatherman, karena sangat bagus.
Mengurangi skrip yang memblokir rendering
Ada bagian lain dari aplikasi kita yang dapat kita dorong lebih awal dalam rantai download untuk memberikan setidaknya beberapa pengalaman pengguna dasar sedikit lebih awal.
Pada strip linimasa Lighthouse, Anda dapat melihat bahwa selama beberapa detik pertama saat semua resource dimuat, pengguna tidak dapat melihat konten apa pun.
Mendownload dan memproses stylesheet eksternal akan memblokir proses rendering kami agar tidak membuat progres apa pun.
Kita dapat mencoba mengoptimalkan jalur rendering penting dengan mengirimkan beberapa gaya sedikit lebih awal.
Jika kita mengekstrak gaya yang bertanggung jawab atas render awal ini dan menyisipkannya dalam HTML, browser dapat langsung merendernya tanpa menunggu stylesheet eksternal tiba.
Dalam kasus kami, kami menggunakan modul NPM yang disebut Critical untuk menyisipkan konten penting dalam index.html selama langkah build.
Meskipun modul ini melakukan sebagian besar pekerjaan berat untuk kami, masih agak sulit untuk membuatnya berfungsi dengan lancar di berbagai rute.
Jika Anda tidak berhati-hati atau struktur situs Anda sangat kompleks, mungkin akan sangat sulit untuk memperkenalkan jenis pola ini jika Anda tidak merencanakan arsitektur app shell sejak awal.
Oleh karena itu, sangat penting untuk mempertimbangkan performa sejak awal. Jika Anda tidak mendesain untuk performa sejak awal, kemungkinan besar Anda akan mengalami masalah saat melakukannya nanti.
Pada akhirnya, risiko yang kami ambil membuahkan hasil, kami berhasil membuatnya berfungsi dan aplikasi mulai menayangkan konten jauh lebih awal, sehingga meningkatkan waktu first meaningful paint kami secara signifikan.
Hasil
Itu adalah daftar panjang pengoptimalan performa yang kami terapkan ke situs kami. Mari kita lihat hasilnya. Berikut adalah cara aplikasi kami dimuat di perangkat seluler sedang di jaringan 3G, sebelum dan sesudah pengoptimalan.
Skor performa Lighthouse naik dari 23 menjadi 91. Itu adalah kemajuan yang cukup bagus dalam hal kecepatan. Semua perubahan didorong oleh kami yang terus memeriksa dan mengikuti laporan Lighthouse. Jika Anda ingin melihat cara kami menerapkan semua peningkatan secara teknis, silakan lihat repo kami, terutama pada PR yang ada di sana.
Performa prediktif - pengalaman pengguna berbasis data
Kami percaya bahwa machine learning merupakan peluang menarik untuk masa depan di banyak bidang. Satu ide yang kami harap akan memicu lebih banyak eksperimen di masa mendatang, adalah bahwa data sebenarnya dapat benar-benar memandu pengalaman pengguna yang kami buat.
Saat ini, kita membuat banyak keputusan arbitrer tentang apa yang mungkin diinginkan atau dibutuhkan pengguna, dan oleh karena itu, apa yang layak diambil, dimuat, atau di-pra-cache terlebih dahulu. Jika tebakan kami benar, kami dapat memprioritaskan sejumlah kecil resource, tetapi sangat sulit untuk menskalakannya ke seluruh situs.
Sebenarnya, kita memiliki data yang tersedia untuk mengoptimalkan kampanye dengan lebih baik saat ini. Dengan menggunakan Google Analytics Reporting API, kita dapat melihat halaman teratas berikutnya dan persentase keluar untuk URL apa pun di situs kita, sehingga dapat menarik kesimpulan tentang resource mana yang harus diprioritaskan.
Jika kita menggabungkannya dengan model probabilitas yang baik, kita dapat menghindari pemborosan data pengguna dengan tidak melakukan pengambilan data konten secara berlebihan dan agresif. Kita dapat memanfaatkan data Google Analytics tersebut, dan menggunakan machine learning serta model seperti rantai Markov atau jaringan neural untuk menerapkan model tersebut.
Untuk memfasilitasi eksperimen ini, dengan senang hati kami mengumumkan inisiatif baru yang kami sebut Guess.js.
Guess.js adalah project yang berfokus pada pengalaman pengguna berbasis data untuk web. Kami harap hal ini akan menginspirasi eksplorasi penggunaan data untuk meningkatkan performa web dan melampauinya. Semuanya bersifat open source dan tersedia di GitHub sekarang. Alat ini dibuat melalui kolaborasi dengan komunitas open source oleh Minko Gechev, Kyle Matthews dari Gatsby, Katie Hempenius, dan sejumlah orang lainnya.
Lihat Guess.js, beri tahu kami pendapat Anda.
Ringkasan
Skor dan metrik berguna untuk meningkatkan kecepatan Web, tetapi keduanya hanyalah sarana, bukan tujuan itu sendiri.
Kita semua pernah mengalami pemuatan halaman yang lambat saat bepergian, tetapi sekarang kita memiliki kesempatan untuk memberikan pengalaman yang lebih menyenangkan kepada pengguna dengan pemuatan yang sangat cepat.
Meningkatkan performa adalah sebuah proses. Banyak perubahan kecil dapat menghasilkan keuntungan besar. Dengan menggunakan alat pengoptimalan yang tepat dan memantau laporan Lighthouse, Anda dapat memberikan pengalaman yang lebih baik dan lebih inklusif kepada pengguna.
Terima kasih khusus kepada: Ward Peeters, Minko Gechev, Kyle Mathews, Katie Hempenius, Dom Farolino, Yoav Weiss, Susie Lu, Yusuke Utsunomiya, Tom Ankers, Lighthouse & Google Doodle.