Di Google IO 2018, kami mempresentasikan rangkuman 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. Pada 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 dan semakin berat setiap tahun. Jika memeriksa status web, kita dapat melihat bahwa ukuran halaman media pada perangkat seluler berukuran sekitar 1,5 MB, yang sebagian besar berupa JavaScript dan gambar.
Ukuran situs yang terus bertambah, beserta faktor lain, seperti latensi jaringan, batasan CPU, pola pemblokir render, atau kode pihak ketiga yang berlebihan, berkontribusi pada performa yang rumit.
Sebagian besar pengguna menilai kecepatan berada di hierarki UX paling atas dari kebutuhan mereka. Hal ini tidak terlalu mengejutkan, karena Anda tidak dapat melakukan banyak hal sampai halaman selesai dimuat. Anda tidak dapat memperoleh nilai dari halaman, Anda tidak dapat mengagumi estetikanya.
Kami tahu bahwa performa penting bagi pengguna, tetapi hal ini juga bisa terasa seperti rahasia untuk menemukan tempat untuk memulai pengoptimalan. Untungnya, ada alat yang dapat membantu Anda.
Lighthouse - dasar untuk alur kerja performa
Lighthouse adalah bagian dari Chrome DevTools yang memungkinkan Anda mengaudit situs Anda, dan memberi Anda petunjuk tentang cara membuatnya lebih baik.
Baru-baru ini kami meluncurkan berbagai audit performa baru yang sangat berguna dalam alur kerja pengembangan sehari-hari.
Mari kita pelajari cara memanfaatkannya melalui contoh praktis: Aplikasi Oodles Theater. Ini adalah aplikasi web demo kecil yang memungkinkan Anda mencoba beberapa Google Doodle interaktif favorit kami, bahkan memainkan satu atau dua game.
Saat membangun aplikasi, kami ingin memastikan bahwa aplikasi tersebut berperforma sebaik mungkin. Titik awal untuk pengoptimalan adalah laporan Lighthouse.
Kinerja awal aplikasi kami seperti yang terlihat pada laporan Lighthouse cukup buruk. Pada jaringan 3G, pengguna harus menunggu selama 15 detik untuk paint pertama yang bermakna, atau agar aplikasi menjadi interaktif. Lighthouse menyoroti banyak masalah pada situs kami, dan skor performa keseluruhan 23 mencerminkan masalah tersebut.
Halaman ini berbobot sekitar 3,4 MB - kami sangat perlu mengurangi sebagian lemak.
Hal ini memulai tantangan performa pertama kami: temukan hal-hal yang dapat dengan mudah dihapus tanpa memengaruhi pengalaman keseluruhan.
Peluang pengoptimalan performa
Menghapus resource yang tidak diperlukan
Ada beberapa hal penting yang dapat dihapus dengan aman: spasi kosong dan komentar.
Lighthouse menyoroti peluang ini di 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 mana pun yang kebetulan digunakan.
Audit berguna lainnya di ruang tersebut adalah Aktifkan kompresi teks. Tidak ada alasan untuk mengirim file yang tidak dikompresi, dan sebagian besar CDN saat ini mendukung hal ini sejak saat ini.
Kami menggunakan Firebase Hosting untuk menghosting kode kami, dan Firebase mengaktifkan gzip secara default, jadi dengan menghosting kode kami di CDN yang wajar, kami mendapatkannya secara gratis.
Meskipun gzip adalah cara kompresi yang sangat populer, mekanisme lain seperti Zopfli dan Brotli juga menarik perhatian. Brotli menikmati dukungan di sebagian besar browser, dan Anda dapat menggunakan biner untuk mengompresi aset terlebih dahulu sebelum mengirimkannya ke server.
Menggunakan kebijakan cache yang efisien
Langkah kita selanjutnya adalah memastikan bahwa kita tidak akan mengirim materi 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 itu. Dengan menyetel header habis masa berlaku usia maksimal di server kami, kami memastikan bahwa pada kunjungan berulang, pengguna dapat menggunakan kembali resource yang telah didownload sebelumnya.
Idealnya, Anda harus berupaya untuk menyimpan sebanyak mungkin resource dalam cache selama jangka waktu lama dan menyediakan token validasi untuk validasi ulang yang efisien terhadap resource yang diperbarui.
Hapus kode yang tidak digunakan
Sejauh ini kita menghapus bagian yang jelas dari download yang tidak perlu, tetapi bagaimana dengan bagian yang kurang terlihat? Misalnya, kode yang tidak digunakan.
Terkadang kami menyertakan kode yang tidak terlalu diperlukan dalam aplikasi kami. Hal ini terjadi terutama jika Anda mengerjakan aplikasi untuk jangka waktu yang lebih lama, tim atau dependensi Anda berubah, dan terkadang library usang tertinggal. Itulah yang terjadi pada kita.
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 sepenuhnya lupa tentang library tersebut. Untungnya, pemeriksaan cakupan kode membantu kita 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 juga sejumlah besar JavaScript.
Lighthouse juga menemukan 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 itu.
Ini menurunkan paket CSS kami 20 kali lipat, yang cukup bagus untuk commit kecil sepanjang dua baris.
Tentu saja, hal tersebut membuat skor performa kami meningkat, dan Saatnya untuk Interaktif jauh lebih baik.
Namun, dengan perubahan seperti ini, Anda tidak hanya dapat memeriksa metrik dan skor saja. Menghapus kode yang sebenarnya tidak bebas risiko, jadi Anda harus selalu waspada terhadap potensi regresi.
Kode kita tidak digunakan dalam 95% - masih ada 5% di suatu tempat. Tampaknya salah satu komponen kami masih menggunakan gaya dari {i>library<i} tersebut - panah kecil di penggeser doodle. Karena ukurannya sangat kecil, kita bisa memasukkan dan menggabungkan gaya tersebut kembali secara manual ke dalam tombol.
Jadi, jika Anda menghapus kode, pastikan Anda memiliki alur kerja pengujian yang tepat untuk membantu melindungi dari potensi regresi visual.
Menghindari payload jaringan yang sangat besar
Kita tahu bahwa resource yang besar dapat memperlambat pemuatan halaman. Mereka bisa menghabiskan biaya pengguna kami dan berdampak besar pada paket data mereka, jadi sangat penting untuk memperhatikan hal ini.
Lighthouse dapat mendeteksi bahwa kami memiliki masalah dengan beberapa payload jaringan menggunakan audit Enormous network payload.
Di sini kita melihat bahwa kami memiliki kode senilai lebih dari 3 MB yang telah dikirim – yang jumlahnya cukup banyak, terutama di perangkat seluler.
Di bagian paling atas daftar ini, Lighthouse menyoroti bahwa kami memiliki paket vendor JavaScript berukuran 2 MB kode yang tidak dikompresi. 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 Anda sajikan kepada pengguna, mengukur performa aset tersebut, dan membuat panggilan tentang apakah benar-benar layak dikirimkan dengan pengalaman awal. Karena terkadang aset ini dapat ditangguhkan, atau dimuat dengan lambat, atau diproses selama waktu tidak ada aktivitas.
Dalam kasus ini, karena kita menangani banyak paket JavaScript, kami beruntung karena komunitas JavaScript memiliki banyak rangkaian alat audit paket JavaScript.
Kami memulai dengan webpack bundle analyzer, yang memberi tahu kami bahwa kami menyertakan dependensi bernama unicode yang merupakan 1, 6 MB dari JavaScript yang diurai.
Setelah itu, kami beralih ke editor dan menggunakan Plugin Biaya Impor untuk kode Visual kami dapat memvisualisasikan biaya setiap modul yang kami impor. Ini memungkinkan kami menemukan komponen mana yang termasuk kode yang merujuk pada modul ini.
Kami kemudian 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 gzip-nya. Kami menemukan alternatif yang bagus untuk modul slug yang kami gunakan yang hanya memiliki berat 2,2 kb, jadi kami menggantinya.
Hal ini berdampak besar pada performa kami. Di antara perubahan ini dan menemukan peluang lain untuk mengurangi ukuran paket JavaScript, kami menghemat 2,1 MB kode.
Secara keseluruhan, kami melihat 65% peningkatan, setelah Anda mempertimbangkan ukuran paket yang diminifikasi dan di-gzip. Dan kami merasa bahwa ini benar-benar layak dilakukan sebagai sebuah proses.
Jadi, secara umum, coba hilangkan download yang tidak perlu di situs dan aplikasi Anda. Buat inventaris aset dan ukur dampaknya terhadap performanya dapat membuat perbedaan yang sangat besar, jadi pastikan Anda mengaudit aset secara cukup teratur.
Waktu booting JavaScript yang lebih rendah dengan pemisahan kode
Meskipun payload jaringan yang besar dapat berdampak besar pada aplikasi, ada hal lain yang dapat berdampak sangat besar, yaitu JavaScript.
JavaScript adalah aset paling mahal. Di perangkat seluler, jika Anda mengirimkan paket besar JavaScript, hal ini dapat menunda seberapa cepat pengguna dapat berinteraksi dengan komponen antarmuka pengguna. Artinya, mereka dapat mengetuk UI tanpa ada peristiwa penting yang benar-benar terjadi. Jadi, penting bagi kita untuk memahami mengapa biaya JavaScript begitu mahal.
Ini adalah cara browser memproses JavaScript.
Pertama-tama, kita harus mendownload skrip tersebut. Kita memiliki mesin JavaScript yang kemudian perlu mengurai kode tersebut, mengompilasi dan mengeksekusinya.
Fase-fase ini sekarang tidak menghabiskan banyak waktu pada perangkat kelas atas seperti komputer desktop atau laptop, bahkan mungkin ponsel kelas atas. Namun, di ponsel median, proses ini bisa berlangsung antara lima dan sepuluh kali lebih lama. Inilah yang menunda interaktivitas, jadi penting bagi kita untuk mencoba menguranginya.
Untuk membantu Anda menemukan masalah ini pada aplikasi, kami memperkenalkan audit waktu booting JavaScript baru ke Lighthouse.
Dan untuk aplikasi Oodle, kami diberi tahu bahwa kami memiliki waktu 1,8 detik untuk melakukan booting pada JavaScript. Yang terjadi adalah kami mengimpor secara statis semua rute dan komponen menjadi satu paket JavaScript monolitik.
Salah satu teknik untuk mengatasi hal ini adalah dengan menggunakan pemisahan kode.
Pemisahan kode adalah gagasan alih-alih memberikan seluruh kode JavaScript kepada pengguna Anda, bagaimana jika Anda hanya memberi mereka satu irisan dalam satu waktu saat mereka membutuhkannya?
Pemisahan kode dapat diterapkan di tingkat rute atau tingkat komponen. Library ini berfungsi sangat baik dengan React dan React Loadable, Vue.js, Angular, Polymer, Preact, dan beberapa library lainnya.
Kami menggabungkan pemisahan kode ke dalam aplikasi, dan kami beralih dari impor statis ke impor dinamis, sehingga kami dapat menjalankan lambat pada kode secara asinkron sesuai kebutuhan.
Dampaknya adalah memperkecil ukuran paket, tetapi juga mengurangi waktu booting JavaScript. Waktu yang diperlukan turun menjadi 0,78 detik, yang membuat aplikasi ini 56% lebih cepat.
Secara umum, jika Anda membangun pengalaman yang sarat JavaScript, pastikan untuk hanya mengirim kode kepada pengguna yang mereka butuhkan.
Manfaatkan konsep seperti pemisahan kode, pelajari ide seperti tree shaking, dan lihat repositori webpack-libs-optimizations untuk mendapatkan beberapa ide tentang cara memangkas ukuran library jika Anda menggunakan webpack.
Mengoptimalkan gambar
Di aplikasi Oodle, kita menggunakan banyak gambar. Sayangnya, Lighthouse kurang antusias tentang hal itu daripada kami. Faktanya, kami gagal dalam ketiga audit terkait gambar.
Kita lupa mengoptimalkan gambar, kita tidak mengukurnya dengan benar, dan juga kita bisa mendapatkan manfaat dari penggunaan format gambar lainnya.
Kami memulai 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 di masa mendatang akan otomatis dioptimalkan. Beberapa CDN, misalnya Akamai atau solusi pihak ketiga seperti Cloudinary, Fastly, atau Uploadcare menawarkan solusi pengoptimalan gambar yang komprehensif, sehingga Anda juga dapat menghosting gambar di layanan tersebut dengan mudah.
Jika Anda tidak ingin melakukannya karena biaya, atau masalah latensi, project seperti Thumbor atau Imageflow menawarkan alternatif yang dihosting sendiri.
PNG latar belakang kami ditandai di webpack sebagai besar, dan memang begitu. Setelah mengukurnya dengan benar ke area pandang dan menjalankannya melalui ImageOptim, kami turun ke 100 kb, yang bisa diterima.
Mengulangi hal ini untuk beberapa gambar di situs memungkinkan kami menurunkan berat 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 pada awalnya. Oleh karena itu, beralih ke format video yang lebih sesuai dapat menghemat ukuran file dengan lebih besar.
Di aplikasi Oodle, kami menggunakan GIF sebagai urutan intro di halaman beranda. Menurut Lighthouse, kami dapat menghemat lebih dari 7 MB dengan beralih ke format video yang lebih efisien. Bobot klip kami sekitar 7,3 mb, terlalu banyak untuk situs web yang masuk akal, 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% berat keseluruhan berkat konversi ini. Hasilnya, kami turun menjadi sekitar 1 MB.
Namun, 1 MB adalah resource besar untuk mendorong kabel, terutama bagi pengguna dengan bandwidth yang terbatas. Untungnya kita dapat menggunakan Effective Type API untuk menyadari bahwa API ini menggunakan bandwidth yang lambat, dan memberinya JPEG yang jauh lebih kecil.
Antarmuka ini menggunakan waktu round-trip yang efektif dan nilai penurunan untuk memperkirakan jenis jaringan yang digunakan pengguna. Itu hanya mengembalikan string, 2G, 2G, 3G atau 4G lambat. Jadi, bergantung pada nilai ini, jika pengguna menggunakan jaringan di bawah 4G, kita dapat mengganti elemen video dengan gambar.
if (navigator.connection.effectiveType) { ... }
Tindakan ini memang menghapus sedikit dari pengalaman, tetapi setidaknya situs dapat digunakan pada koneksi yang lambat.
Pemuatan lambat untuk gambar di luar layar
Korsel, penggeser, atau halaman yang sangat panjang sering 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 di panel jaringan DevTools. Jika Anda melihat banyak gambar yang masuk sementara hanya beberapa gambar yang terlihat di halaman, itu berarti Anda mungkin dapat mempertimbangkan pemuatan lambat gambar tersebut.
Pemuatan lambat belum didukung secara native di browser, sehingga kami harus menggunakan JavaScript untuk menambahkan kemampuan ini. Kami menggunakan library Lazysizes untuk menambahkan perilaku pemuatan lambat ke cakupan 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 adalah fitur 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.
Class ini juga menawarkan integrasi opsional dari IntersectionObserver, yang memberi Anda
pencarian visibilitas yang sangat efisien.
Setelah perubahan ini, gambar akan diambil sesuai permintaan. Jika Anda ingin menggali topik tersebut lebih dalam, lihat images.guide - referensi yang sangat berguna dan komprehensif.
Bantu browser menyediakan resource penting lebih awal
Tidak setiap byte yang dikirim melalui kabel ke browser memiliki tingkat kepentingan yang sama, dan browser mengetahui hal ini. Banyak browser memiliki heuristik untuk memutuskan apa yang harus diambil terlebih dahulu. Jadi, terkadang mereka akan mengambil CSS sebelum gambar atau skrip.
Sesuatu yang dapat berguna adalah kita, sebagai penulis halaman, yang memberi tahu browser tentang
hal yang benar-benar penting bagi kita. Untungnya, selama beberapa tahun terakhir, vendor browser telah
menambahkan sejumlah fitur untuk membantu kami melakukannya, 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 menjadi sedikit lebih efisien daripada beberapa pendekatan berbasis logika pemuatan kustom yang dilakukan menggunakan skrip.
Mari kita lihat bagaimana Lighthouse benar-benar memandu kita untuk menggunakan beberapa fitur ini secara efektif.
Hal pertama yang harus dilakukan Lighthouse adalah menghindari beberapa perjalanan pulang pergi yang mahal ke tempat asal mana pun.
Dalam kasus aplikasi Oodle, kami sebenarnya lebih banyak menggunakan Google Fonts. Setiap kali Anda meletakkan stylesheet Google Font ke halaman Anda, stylesheet tersebut akan menghubungkan hingga dua subdomain. Dan yang dikatakan Lighthouse kepada kita adalah jika kita dapat memanaskan koneksi itu, kita dapat menghemat waktu hingga 300 milidetik pada waktu koneksi awal kita.
Dengan memanfaatkan link rel preconnect, kita dapat secara efektif menyamarkan latensi koneksi tersebut.
Terutama untuk alat seperti Google Fonts tempat CSS tampilan font kita dihosting di googleapis.com, dan resource font kita dihosting di Gstatic, hal ini dapat memiliki dampak yang sangat besar. Jadi kami menerapkan pengoptimalan ini dan kami memangkas beberapa ratus milidetik.
Hal berikutnya yang disarankan Lighthouse adalah kita melakukan pramuat permintaan kunci.
<link rel=preload> sangat andal, yang 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 memulai dan melakukan pramuat resource font web utama, karena kita memuat dua font web.
Melakukan pramuat dalam font web terlihat seperti ini - dengan menentukan rel=preload, Anda meneruskan as dengan
jenis font, lalu tentukan jenis font yang ingin dimuat, seperti woff2.
Dampaknya terhadap halaman Anda cukup jelas.
Biasanya, tanpa menggunakan pramuat rel link, jika font web sangat penting bagi halaman Anda, yang harus dilakukan browser adalah mengambil HTML Anda terlebih dahulu, harus mengurai CSS Anda, dan pada akhirnya, browser akan mengambil font web Anda.
Dengan menggunakan pramuat link rel, segera setelah browser mengurai HTML Anda, browser dapat mulai mengambil font web tersebut jauh lebih awal. Dalam kasus aplikasi, cara ini dapat memangkas satu detik waktu yang diperlukan untuk merender teks menggunakan font web.
Sekarang tidak semudah itu jika Anda akan mencoba melakukan pramuat {i>font<i} menggunakan Google Fonts, ada satu hal yang harus dilakukan.
URL Google Font yang kami tentukan pada tampilan font di stylesheet kami kebetulan merupakan sesuatu yang sering diperbarui oleh tim font. URL ini dapat habis masa berlakunya, atau diperbarui secara rutin, sehingga kami akan menyarankan Anda jika ingin memiliki kontrol penuh atas pengalaman pemuatan font adalah menghosting sendiri font web Anda. Cara ini sangat bagus karena memberi Anda akses ke hal-hal seperti pramuat rel link.
Dalam kasus ini, kami merasa alat Google Web Fonts Helper sangat berguna dalam membantu kami offline beberapa font web tersebut dan menyiapkannya secara lokal. Jadi, cobalah alat tersebut.
Baik Anda menggunakan font web sebagai bagian dari resource penting atau pun JavaScript, cobalah bantu browser mengirimkan resource penting Anda sesegera mungkin.
Eksperimental: Petunjuk Prioritas
Kami punya sesuatu yang istimewa untuk disampaikan 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 menunjukkan kepada browser seberapa penting suatu resource. Fitur ini mengekspos atribut baru - tingkat kepentingan - dengan nilai rendah, tinggi, atau otomatis.
Hal ini memungkinkan kami menyampaikan penurunan prioritas resource yang kurang penting, seperti gaya yang tidak penting, gambar, atau panggilan API pengambilan untuk mengurangi pertentangan. Kita juga dapat meningkatkan prioritas hal-hal yang lebih penting, seperti gambar utama kita.
Dalam kasus aplikasi Oodle, hal ini sebenarnya menghasilkan satu tempat praktis yang dapat digunakan untuk mengoptimalkan.
Sebelum menambahkan pemuatan lambat ke gambar, yang dilakukan browser, kami memiliki carousel gambar dengan semua doodle dan browser mengambil semua gambar di awal carousel dengan prioritas tinggi. Sayangnya, gambar yang berada di tengah {i>carousel<i}lah yang paling penting bagi pengguna. Jadi yang kami lakukan adalah, kami menetapkan nilai penting gambar latar tersebut menjadi sangat rendah, gambar latar depan menjadi sangat tinggi, dan dampak ini adalah dampak dua detik dibandingkan 3G yang lambat, serta 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 pantau terus.
Memiliki strategi pemuatan font web
Tipografi adalah dasar desain yang baik, dan jika Anda menggunakan font web, idealnya Anda tidak ingin memblokir rendering teks, dan tentu saja tidak ingin menampilkan teks yang tidak terlihat.
Kami menandai hal ini di Lighthouse sekarang, dengan audit Hindari teks tidak terlihat saat font web dimuat.
Jika Anda memuat font web menggunakan jenis font, Anda membiarkan browser memutuskan apa yang harus dilakukan jika perlu waktu yang lama untuk mengambil font web tersebut. Beberapa browser akan menunggu hingga tiga detik sebelum kembali ke font sistem, dan pada akhirnya browser akan menukarnya dengan font yang telah didownload.
Kita berusaha menghindari teks yang tidak terlihat ini, jadi dalam kasus ini kita tidak akan bisa melihat
corat-coret klasik minggu ini jika {i>font<i} webnya terlalu panjang. Untungnya, dengan fitur baru bernama
font-display, Anda sebenarnya mendapatkan kontrol yang jauh lebih besar 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 menentukan cara font web dirender atau diganti berdasarkan waktu yang dibutuhkan untuk menukarnya.
Dalam hal ini, kita menggunakan {i>font display swap<i}. Swap memberikan periode pemblokiran nol detik dan periode penukaran tak terbatas pada bentuk font. Artinya browser akan segera menggambar teks dengan font pengganti jika font membutuhkan waktu yang cukup lama untuk dimuat. Dan komputer itu akan menukarnya setelah bentuk {i>font<i} tersedia.
Dalam kasus aplikasi kita, hal ini sangat bagus karena kita dapat menampilkan beberapa teks yang bermakna sejak awal, dan melakukan transisi ke font web setelah siap.
Umumnya, jika Anda menggunakan font web, sebagian besar web menggunakan strategi pemuatan font web yang baik.
Ada banyak fitur platform web yang dapat Anda gunakan untuk mengoptimalkan pengalaman pemuatan font, tetapi coba juga repo Web Font Recipes milik Zach Leatherman, karena fitur ini sangat bagus.
Mengurangi skrip yang memblokir render
Ada bagian lain dari aplikasi yang dapat kami dorong lebih awal di 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 memblokir proses rendering kita sehingga tidak dapat membuat progres.
Kita bisa mencoba mengoptimalkan jalur rendering penting dengan memberikan beberapa gaya sedikit lebih awal.
Jika kita mengekstrak gaya yang bertanggung jawab atas render awal ini dan menyisipkannya di HTML, browser dapat merendernya langsung tanpa menunggu stylesheet eksternal muncul.
Dalam kasus ini, kami menggunakan modul NPM yang disebut Penting untuk menyisipkan konten penting di index.html selama langkah build.
Meskipun modul ini melakukan sebagian besar pekerjaan berat bagi kami, masih sedikit sulit untuk membuatnya berfungsi dengan lancar di berbagai rute.
Jika tidak berhati-hati atau struktur situs Anda sangat kompleks, mungkin akan sangat sulit untuk memperkenalkan jenis pola ini jika Anda tidak merencanakan arsitektur shell aplikasi sejak awal.
Inilah alasan mengapa sangat penting untuk mempertimbangkan kinerja sejak dini. Jika Anda tidak mendesain untuk performa sejak awal, kemungkinan besar Anda akan mengalami masalah saat melakukannya nanti.
Pada akhirnya, risiko tersebut berhasil. Kami berhasil melakukannya dan aplikasi mulai mengirimkan konten lebih sebelumnya, sehingga mempercepat waktu render pertama yang signifikan secara signifikan.
Hasil
Itulah daftar panjang pengoptimalan performa yang telah kita terapkan ke situs. Mari kita lihat hasilnya. Ini adalah cara aplikasi kami dimuat pada perangkat seluler berukuran sedang pada jaringan 3G, sebelum dan setelah pengoptimalan.
Skor performa Lighthouse naik dari 23 menjadi 91. Dalam hal kecepatan, ini kemajuan yang cukup bagus. Semua perubahan ini didukung oleh kami yang terus memeriksa dan mengikuti laporan Lighthouse. Jika Anda ingin melihat cara kami mengimplementasikan semua peningkatan secara teknis, lihat repo kami, terutama PR yang telah diterapkan di sana.
Performa prediktif - pengalaman pengguna berbasis data
Kami percaya bahwa machine learning menghadirkan peluang menarik bagi masa depan di banyak bidang. Salah satu ide yang kami harapkan akan memicu lebih banyak eksperimen pada masa mendatang, adalah data nyata dapat benar-benar memandu pengalaman pengguna yang kami ciptakan.
Saat ini, kita membuat banyak keputusan arbitrer tentang apa yang mungkin diinginkan atau dibutuhkan pengguna, sehingga apa yang layak diambil data, dimuat sebelumnya, atau di-cache. Jika kami menebak dengan benar, kami dapat memprioritaskan sejumlah kecil sumber daya, tetapi sangat sulit untuk menskalakannya ke seluruh situs web.
Sebenarnya, kami memiliki data yang tersedia untuk menginformasikan pengoptimalan kami dengan lebih baik saat ini. Dengan menggunakan Google Analytics Reporting API, kita dapat melihat halaman teratas berikutnya dan persentase keluar untuk semua URL di situs kita, sehingga menarik kesimpulan tentang resource mana yang harus diprioritaskan.
Jika kita menggabungkannya dengan model probabilitas yang baik, kita akan menghindari pemborosan data pengguna dengan secara agresif mengambil konten secara berlebihan. Kami 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 umumkan inisiatif baru yang disebut Guess.js.
Guess.js adalah proyek yang berfokus pada pengalaman pengguna berbasis data untuk web. Kami harap hal ini dapat menginspirasi eksplorasi penggunaan data untuk meningkatkan performa web dan lebih dari itu. Semuanya bersifat {i>open source<i} dan tersedia di GitHub hari ini. Aplikasi 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 dalam meningkatkan kecepatan Web, tetapi ini hanyalah sarana, bukan tujuan itu sendiri.
Kita semua pernah mengalami pemuatan halaman yang lambat di mana saja, tetapi sekarang kita punya kesempatan untuk memberikan pengalaman yang lebih menyenangkan kepada pengguna yang dimuat dengan sangat cepat.
Meningkatkan performa adalah sebuah perjalanan. Banyak perubahan kecil dapat memberikan 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.