Di Google IO 2018, kami mempresentasikan ringkasan alat, library, dan teknik pengoptimalan yang mempermudah peningkatan performa web. Di sini kami menjelaskannya menggunakan aplikasi The Oodles Theater. Kami juga membahas eksperimen kami dengan pemuatan prediktif dan inisiatif Guess.js yang baru.
Kami cukup sibuk selama setahun terakhir mencoba mencari tahu cara membuat Web lebih cepat dan berperforma lebih baik. 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 The 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 rendering, 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, Anda tidak dapat mengagumi estetikanya.
Kami tahu bahwa performa penting bagi pengguna, tetapi juga bisa terasa seperti rahasia untuk menemukan tempat 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 melakukan audit situs, dan memberikan 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. Aplikasi 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 menandai banyak masalah di situs kami, dan skor performa keseluruhan sebesar 23 mencerminkan hal tersebut.
Ukuran halaman 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 keseluruhan pengalaman.
Peluang pengoptimalan performa
Menghapus resource yang tidak perlu
Ada beberapa hal jelas yang dapat dihapus dengan aman: spasi dan komentar.
Lighthouse menyoroti peluang ini dalam audit CSS & JavaScript yang tidak di-minify. Kami menggunakan webpack untuk proses build, jadi untuk mendapatkan minifikasi, kami cukup menggunakan plugin Uglify JS.
Minifikasi adalah tugas umum, jadi Anda dapat menemukan solusi siap pakai untuk proses build apa pun yang Anda gunakan.
Audit berguna lainnya 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 kami, dan Firebase mengaktifkan gzipping secara default, jadi dengan menghosting kode kami di CDN yang wajar, kami mendapatkan manfaat tersebut secara gratis.
Meskipun gzip adalah cara kompresi yang sangat populer, mekanisme lain seperti Zopfli dan Brotli juga mendapatkan daya tarik. Brotli didukung di sebagian besar browser, dan Anda dapat menggunakan biner untuk memampatkan aset terlebih dahulu sebelum mengirimkannya ke server.
Menggunakan kebijakan cache yang efisien
Langkah berikutnya adalah memastikan bahwa kami tidak mengirimkan 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 menyetel header masa berlaku max-age di server kami, kami memastikan bahwa pada kunjungan berulang, pengguna dapat menggunakan kembali resource yang telah didownload sebelumnya.
Idealnya, Anda harus berupaya menyimpan dalam cache sebanyak mungkin resource dengan aman selama jangka waktu yang paling lama dan memberikan token validasi untuk validasi ulang yang efisien dari resource yang diperbarui.
Menghapus kode yang tidak digunakan
Sejauh ini, kita telah menghapus bagian yang jelas dari download yang tidak perlu, tetapi bagaimana dengan bagian yang kurang jelas? Misalnya, kode yang tidak digunakan.
Terkadang kami menyertakan kode yang sebenarnya tidak diperlukan dalam aplikasi kami. Hal ini terjadi terutama jika Anda mengerjakan aplikasi dalam jangka waktu yang lebih lama, tim atau dependensi Anda berubah, dan terkadang library yang tidak digunakan tertinggal. Itulah yang terjadi pada kami.
Pada awalnya, kami menggunakan library Komponen Material untuk membuat prototipe aplikasi dengan cepat. Seiring waktu, kami beralih ke tampilan dan nuansa yang lebih kustom dan kami benar-benar 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 dapat melihat dua garis merah besar di screenshot bawah - kami memiliki lebih dari 95% CSS yang tidak digunakan, dan banyak JavaScript juga.
Lighthouse juga mendeteksi masalah ini dalam audit aturan CSS yang tidak digunakan. Hal ini menunjukkan potensi penghematan lebih dari 400 KB. Jadi, kita kembali ke kode dan menghapus bagian JavaScript dan CSS dari library tersebut.
Hal ini mengurangi ukuran 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 sebenarnya tidak pernah bebas risiko, jadi Anda harus selalu mewaspadai potensi regresi.
Kode kita tidak digunakan dalam 95% kasus - masih ada 5% di suatu tempat. Ternyata salah satu komponen kami masih menggunakan gaya dari library tersebut - panah kecil di penggeser doodle. Namun, karena ukurannya sangat kecil, kita dapat langsung menggabungkan gaya tersebut kembali ke tombol secara manual.
Jadi, jika Anda menghapus kode, pastikan Anda memiliki alur kerja pengujian yang tepat untuk membantu Anda mencegah potensi regresi visual.
Menghindari payload jaringan yang sangat besar
Kami tahu bahwa resource besar dapat memperlambat pemuatan halaman web. Hal ini dapat membuat pengguna kami mengeluarkan uang dan berdampak besar pada paket data mereka, jadi 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 ada lebih dari 3 MB kode yang dikirimkan – yang cukup banyak, terutama di perangkat seluler.
Di bagian paling atas daftar ini, Lighthouse menandai bahwa kita memiliki paket vendor JavaScript yang berisi 2 MB kode yang tidak dikompresi. Hal ini juga merupakan masalah yang ditandai oleh webpack.
Seperti kata pepatah: permintaan tercepat adalah permintaan yang tidak dibuat.
Idealnya, Anda harus mengukur nilai setiap aset yang ditayangkan kepada pengguna, mengukur performa aset tersebut, dan memutuskan apakah aset tersebut layak ditayangkan dengan pengalaman awal. Karena terkadang aset ini dapat ditangguhkan, atau dimuat secara lambat, atau diproses selama waktu tidak ada aktivitas.
Dalam kasus kami, karena kami berurusan dengan banyak paket JavaScript, kami beruntung karena komunitas JavaScript memiliki serangkaian alat audit paket JavaScript yang lengkap.
Kami memulai dengan penganalisis paket webpack, yang memberi tahu kami bahwa kami menyertakan dependensi bernama unicode yang berukuran 1,6 MB JavaScript yang diuraikan, jadi cukup besar.
Kemudian, kita membuka editor dan menggunakan Plugin Biaya Impor untuk Visual Code, kita dapat memvisualisasikan biaya setiap modul yang kita impor. Hal ini memungkinkan kita menemukan komponen yang menyertakan kode yang mereferensikan modul ini.
Kemudian, kita beralih ke alat lain, BundlePhobia. Ini adalah alat yang memungkinkan Anda memasukkan nama paket NPM apa pun dan melihat perkiraan ukuran minifikasi dan gzip-nya. Kami menemukan alternatif yang bagus untuk modul slug yang kami gunakan yang hanya berbobot 2,2 kb, jadi kami menggantinya.
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 sebesar 65% secara keseluruhan, setelah Anda memperhitungkan ukuran paket yang di-gzip dan di-minifikasi ini. Dan kami mendapati bahwa hal ini sangat layak dilakukan sebagai sebuah proses.
Jadi, secara umum, cobalah untuk menghilangkan download yang tidak perlu di situs dan aplikasi Anda. Membuat inventaris aset dan mengukur dampak performanya dapat membuat perbedaan yang sangat besar, jadi pastikan Anda mengaudit aset secara cukup rutin.
Mempercepat 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 mengirim paket JavaScript berukuran besar, hal ini dapat menunda seberapa cepat pengguna dapat berinteraksi dengan komponen antarmuka pengguna Anda. Artinya, mereka dapat mengetuk UI tanpa ada hal yang berarti yang benar-benar terjadi. Jadi, penting bagi kita untuk memahami mengapa JavaScript sangat mahal.
Berikut cara browser memproses JavaScript.
Pertama-tama kita harus mendownload skrip tersebut, kita memiliki mesin JavaScript yang kemudian perlu mem-parsing kode tersebut, perlu mengompilasinya, dan mengeksekusinya.
Sekarang, fase ini tidak memerlukan banyak waktu di perangkat kelas atas seperti komputer desktop atau laptop, bahkan mungkin ponsel kelas atas. Namun, di ponsel kelas menengah, proses ini dapat memakan waktu lima hingga sepuluh kali lebih lama. Hal inilah yang menunda interaktivitas, jadi penting bagi kita untuk mencoba menguranginya.
Untuk membantu Anda menemukan masalah ini di aplikasi, kami memperkenalkan audit waktu booting JavaScript baru ke Lighthouse.
Dalam kasus aplikasi Oodle, aplikasi tersebut memberi tahu kami bahwa kami menghabiskan waktu 1,8 detik untuk booting 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 dengan menggunakan pemisahan kode.
Pemisahan kode adalah gagasan untuk tidak memberikan JavaScript senilai satu pizza utuh kepada pengguna Anda, tetapi memberikan satu potong saja setiap kali mereka membutuhkannya.
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. Hal ini mengurangi waktu pemuatan menjadi 0,78 detik, sehingga aplikasi 56% lebih cepat.
Secara umum, jika Anda membuat pengalaman yang sangat bergantung pada JavaScript, pastikan untuk hanya mengirim kode yang dibutuhkan pengguna.
Manfaatkan konsep seperti pemisahan kode, pelajari ide seperti penghapusan kode yang tidak digunakan, dan lihat repo 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, kami gagal dalam ketiga audit terkait gambar.
Kita lupa mengoptimalkan gambar, tidak menyesuaikan ukurannya dengan benar, dan juga bisa mendapatkan keuntungan dari penggunaan format gambar lain.
Kami mulai dengan mengoptimalkan gambar.
Untuk putaran pengoptimalan satu kali, Anda dapat menggunakan alat visual seperti ImageOptim atau XNConvert.
Pendekatan yang lebih otomatis adalah menambahkan langkah pengoptimalan gambar ke proses build Anda, 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 benar. Setelah menyesuaikan ukurannya dengan benar ke area pandang dan menjalankannya melalui ImageOptim, kami turun menjadi 100 kb, yang dapat diterima.
Dengan mengulangi proses ini untuk beberapa gambar di situs kami, kami dapat mengurangi bobot halaman secara keseluruhan secara signifikan.
Menggunakan format yang tepat untuk konten animasi
GIF bisa sangat mahal. Anehnya, format GIF tidak pernah dimaksudkan sebagai platform animasi sejak awal. Oleh karena itu, beralih ke format video yang lebih sesuai akan memberikan penghematan besar dalam hal ukuran file.
Di aplikasi Oodle, kami menggunakan GIF sebagai urutan pengantar 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.
Kita 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% berat keseluruhan berkat konversi ini. Hal ini mengurangi ukuran kami menjadi sekitar 1 MB.
Namun, 1 MB adalah resource besar yang harus didorong melalui jaringan, terutama bagi pengguna dengan bandwidth terbatas. Untungnya, kami dapat menggunakan Effective Type API untuk mengetahui bahwa mereka menggunakan bandwidth lambat, dan memberikan JPEG yang jauh lebih kecil.
Antarmuka ini menggunakan waktu perjalanan pulang pergi yang efektif dan nilai penurunan untuk memperkirakan jenis jaringan yang digunakan pengguna. Fungsi 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 pengguna, tetapi setidaknya situs dapat digunakan pada koneksi yang lambat.
Memuat lambat gambar di luar layar
Korsel, penggeser, atau halaman yang sangat panjang sering kali memuat gambar, meskipun pengguna tidak dapat melihatnya langsung 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 yang masuk, tetapi hanya beberapa yang terlihat di halaman, berarti Anda dapat mempertimbangkan untuk memuatnya secara 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 kami.
<!-- 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 pintar karena tidak hanya melacak perubahan visibilitas elemen, tetapi juga secara proaktif mengambil data elemen yang berada di dekat tampilan untuk pengalaman pengguna yang optimal.
Gemini Cloud Assist juga menawarkan integrasi opsional IntersectionObserver, yang memberi Anda pencarian visibilitas yang sangat efisien.
Setelah perubahan ini, gambar kami 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 dikirimkan melalui kabel 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.
Sesuatu yang dapat berguna adalah kami, sebagai penulis halaman, memberi tahu browser apa yang sebenarnya sangat penting bagi kami. 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 dibawa ke platform web ini membantu browser mengambil hal yang tepat pada waktu yang tepat, dan dapat sedikit lebih efisien daripada beberapa pendekatan pemuatan kustom berbasis logika yang dilakukan menggunakan skrip.
Mari kita lihat bagaimana Lighthouse memandu kita menggunakan beberapa fitur ini secara efektif.
Hal pertama yang disarankan Lighthouse adalah menghindari beberapa perjalanan pulang pergi yang mahal ke asal mana pun.
Dalam kasus aplikasi Oodle, kami sebenarnya banyak 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 memanaskan koneksi tersebut, kita dapat menghemat hingga 300 milidetik dalam waktu koneksi awal kita.
Dengan memanfaatkan prakoneksi rel link, kita dapat secara efektif menyembunyikan latensi koneksi tersebut.
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 mengurangi beberapa ratus milidetik.
Hal berikutnya yang disarankan Lighthouse adalah memuat permintaan utama terlebih dahulu.
<link rel=preload> sangat efektif, memberi tahu browser bahwa resource diperlukan sebagai
bagian dari navigasi saat ini, dan mencoba membuat browser mengambilnya sesegera mungkin.
Sekarang, Lighthouse memberi tahu kita bahwa kita harus memuat dan mempramuat resource font web utama, karena kita memuat dua font web.
Pemuatan awal di font web terlihat seperti ini - dengan menentukan rel=preload, Anda meneruskan as dengan
jenis font, lalu Anda menentukan jenis font yang ingin dimuat, seperti woff2.
Dampak yang dapat ditimbulkan pada halaman Anda cukup besar.
Biasanya, tanpa menggunakan pramuat rel link, jika font web penting untuk halaman Anda, yang harus dilakukan browser adalah pertama-tama mengambil HTML Anda, mengurai CSS Anda, dan di suatu waktu yang jauh kemudian, browser akan mengambil font web Anda.
Dengan menggunakan link rel preload, segera setelah browser mengurai HTML Anda, browser dapat mulai mengambil font web tersebut lebih awal. Dalam kasus aplikasi kami, hal ini dapat mengurangi satu detik waktu yang diperlukan untuk merender teks menggunakan font web kami.
Sekarang, tidak sesederhana itu jika Anda akan mencoba memuat font terlebih dahulu menggunakan Google Fonts, ada satu hal yang perlu diperhatikan.
URL Google Font yang kami tentukan pada wajah font di stylesheet kami ternyata adalah sesuatu yang diperbarui tim font secara cukup rutin. URL ini dapat berakhir masa berlakunya, atau diperbarui secara rutin, sehingga kami menyarankan Anda untuk menghosting sendiri font web jika ingin memiliki kontrol penuh atas pengalaman pemuatan font. Hal ini bisa sangat berguna 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 meng-offline-kan beberapa font web tersebut dan menyiapkannya secara lokal, jadi coba alat tersebut.
Baik Anda menggunakan font web sebagai bagian dari resource penting, atau JavaScript, coba bantu browser mengirimkan resource penting Anda sesegera mungkin.
Eksperimental: Petunjuk Prioritas
Kami punya sesuatu yang spesial untuk dibagikan kepada Anda hari ini. Selain fitur seperti petunjuk resource dan 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 menyampaikan penurunan prioritas resource yang kurang penting, seperti gaya, gambar, atau panggilan API pengambilan data yang tidak penting untuk mengurangi pertentangan. Kita juga dapat meningkatkan prioritas hal-hal yang lebih penting, seperti gambar utama.
Dalam kasus aplikasi Oodle kami, hal ini benar-benar mengarah pada satu tempat praktis yang dapat kami optimalkan.
Sebelum kami menambahkan pemuatan lambat ke gambar kami, yang dilakukan browser adalah, kami memiliki carousel gambar ini dengan semua doodle kami dan browser 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, kami menetapkan tingkat kepentingan gambar latar belakang tersebut ke sangat rendah, gambar latar depan ke sangat tinggi, dan hasilnya adalah dampak dua detik pada 3G yang lambat, dan seberapa cepat kami dapat mengambil dan merender gambar tersebut. Jadi, pengalaman yang positif dan menyenangkan.
Kami berharap dapat menghadirkan fitur ini ke Canary dalam beberapa minggu ke depan, jadi nantikan info dari kami.
Memiliki strategi pemuatan font web
Tipografi sangat penting untuk desain yang baik, dan jika Anda menggunakan font web, idealnya Anda tidak ingin memblokir rendering teks, dan Anda tentu 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 membiarkan browser memutuskan apa yang harus dilakukan jika font web tersebut membutuhkan waktu lama untuk diambil. Beberapa browser akan menunggu hingga tiga detik untuk ini sebelum kembali ke font sistem, dan pada akhirnya akan menggantinya dengan font setelah didownload.
Kami berusaha menghindari teks yang tidak terlihat ini, jadi dalam kasus ini, kami tidak akan dapat melihat doodle klasik minggu ini jika font web memakan waktu terlalu lama. Untungnya, dengan fitur baru yang disebut
font-display, Anda 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 diganti berdasarkan waktu yang diperlukan untuk menggantinya.
Dalam hal ini, kita menggunakan penggantian tampilan font. Swap memberikan periode pemblokiran nol detik pada font face, dan periode swap tak terbatas. Artinya, browser akan menggambar teks Anda dengan cukup cepat menggunakan font pengganti jika font membutuhkan waktu lama untuk dimuat. Dan font akan ditukar 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, terapkan strategi pemuatan font web yang baik.
Ada banyak fitur platform web yang dapat Anda gunakan untuk mengoptimalkan pengalaman pemuatan font, tetapi Anda juga dapat melihat repo Web Font Recipes Zach Leatherman, karena repo ini sangat bagus.
Mengurangi skrip yang memblokir render
Ada bagian lain dari aplikasi yang dapat kita dorong lebih awal dalam rantai download untuk memberikan setidaknya beberapa pengalaman pengguna dasar sedikit lebih awal.
Di deretan 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 menghalangi proses rendering kami untuk membuat kemajuan apa pun.
Kita dapat mencoba mengoptimalkan jalur rendering penting dengan mengirimkan beberapa gaya sedikit lebih awal.
Jika kita mengekstrak gaya yang bertanggung jawab atas rendering awal ini dan menjadikannya sebaris dalam HTML, browser dapat merendernya secara langsung tanpa menunggu lembar gaya eksternal tiba.
Dalam kasus ini, kita menggunakan modul NPM bernama Critical untuk menyisipkan konten penting dalam index.html selama langkah build.
Meskipun modul ini telah melakukan sebagian besar tugas berat untuk kita, masih ada sedikit trik untuk membuat ini berfungsi lancar di berbagai rute.
Jika Anda tidak berhati-hati atau struktur situs Anda sangat rumit, akan sangat sulit untuk memperkenalkan jenis pola ini jika Anda tidak merencanakan arsitektur shell aplikasi dari awal.
Itulah sebabnya 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 kami terbayar. Kami berhasil membuatnya berfungsi dan aplikasi mulai mengirimkan konten jauh lebih awal, sehingga meningkatkan waktu paint bermakna pertama kami secara signifikan.
Hasilnya
Itulah daftar panjang pengoptimalan performa yang kami terapkan ke situs kami. Mari kita lihat hasilnya. Berikut cara aplikasi kami dimuat di perangkat seluler sedang di jaringan 3G, sebelum dan sesudah pengoptimalan.
Skor performa Lighthouse meningkat dari 23 menjadi 91. Itu adalah kemajuan yang cukup baik dalam hal kecepatan. Semua perubahan tersebut didorong oleh upaya kami yang terus-menerus memeriksa dan mengikuti laporan Lighthouse. Jika Anda ingin melihat cara kami menerapkan semua peningkatan ini secara teknis, silakan lihat repo kami, terutama PR yang ada di sana.
Performa prediktif - pengalaman pengguna berbasis data
Kami yakin bahwa machine learning menghadirkan peluang menarik untuk masa depan di berbagai bidang. Salah satu ide yang kami harapkan akan memicu lebih banyak eksperimen di masa mendatang adalah bahwa data nyata dapat benar-benar memandu pengalaman pengguna yang kami ciptakan.
Saat ini, kami membuat banyak keputusan arbitrer tentang apa yang mungkin diinginkan atau dibutuhkan pengguna, dan oleh karena itu, apa yang layak di-prefetch, dimuat sebelumnya, atau di-cache sebelumnya. Jika tebakan kita benar, kita dapat memprioritaskan sejumlah kecil resource, tetapi sangat sulit untuk menskalakannya ke seluruh situs.
Sebenarnya kami memiliki data yang tersedia untuk menginformasikan pengoptimalan kami dengan lebih baik hari 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 sumber daya mana yang harus diprioritaskan.
Jika kita menggabungkannya dengan model probabilitas yang baik, kita dapat menghindari pemborosan data pengguna dengan melakukan pengambilan awal konten secara agresif. Kita dapat memanfaatkan data Google Analytics tersebut, dan menggunakan machine learning serta model seperti rantai Markov atau jaringan saraf 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 berharap ini akan menginspirasi eksplorasi penggunaan data untuk meningkatkan performa web dan melampaui hal tersebut. Semuanya bersifat open source dan tersedia di GitHub hari ini. Dokumen ini dibuat berkolaborasi dengan komunitas open source oleh Minko Gechev, Kyle Matthews dari Gatsby, Katie Hempenius, dan sejumlah orang lainnya.
Coba Guess.js, lalu beri tahu kami pendapat Anda.
Ringkasan
Skor dan metrik berguna dalam meningkatkan kecepatan Web, tetapi keduanya hanyalah alat, bukan tujuan itu sendiri.
Kita semua pernah mengalami pemuatan halaman yang lambat saat bepergian, tetapi kini kita memiliki peluang untuk memberikan pengalaman yang lebih menyenangkan kepada pengguna yang memuat dengan sangat cepat.
Meningkatkan performa adalah sebuah perjalanan. 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 Doodles.