Performa Web Jadi Mudah - edisi Google I/O 2018

Di Google IO 2018, kami mempresentasikan rangkuman alat, library, dan teknik pengoptimalan yang mempermudah peningkatan performa web. Di sini kami menjelaskannya menggunakan aplikasi Oodles Theater. Kami juga membahas eksperimen kami dengan pemuatan prediktif dan inisiatif baru Guess.js.

Addy Osmani

Ewa Gasperowicz

Selama setahun terakhir, kami cukup sibuk mencoba mencari cara untuk membuat Web lebih cepat dan memiliki performa yang 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 praktiknya saat mengembangkan aplikasi Oodles Theater. Di bagian kedua, kita akan membahas eksperimen kami dengan pemuatan prediktif dan inisiatif Guess.js baru.

Kebutuhan akan performa

Internet semakin berat setiap tahunnya. Jika memeriksa status web, kita dapat melihat bahwa halaman median di perangkat seluler memiliki berat sekitar 1,5 MB, dengan sebagian besar berupa JavaScript dan gambar.

Ukuran situs yang semakin besar, bersama dengan faktor-faktor lain, seperti latensi jaringan, batasan CPU, pola pemblokiran render, atau kode pihak ketiga yang berlebihan, berkontribusi pada permasalahan performa yang rumit.

Sebagian besar pengguna menilai kecepatan sebagai hierarki UX yang paling atas kebutuhan mereka. Hal ini tidak terlalu mengejutkan, karena Anda tidak dapat melakukan banyak hal hingga halaman selesai dimuat. Anda tidak dapat mendapatkan nilai dari halaman, Anda tidak dapat mengagumi estetikanya.

Kami tahu bahwa performa penting bagi pengguna, tetapi menemukan tempat untuk memulai pengoptimalan juga bisa terasa seperti sebuah rahasia. 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 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 dengan 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 mem-build aplikasi, kami ingin memastikan aplikasi tersebut berperforma sebaik mungkin. Titik awal untuk pengoptimalan adalah laporan Lighthouse.

Performa awal aplikasi seperti yang terlihat di laporan Lighthouse cukup buruk. Pada jaringan 3G, pengguna harus menunggu selama 15 detik untuk mendapatkan tampilan pertama yang bermakna, atau agar aplikasi menjadi interaktif. Lighthouse menyoroti banyak masalah pada situs kami, dan skor performa keseluruhan sebesar 23 mencerminkan hal tersebut.

Halaman tersebut memiliki berat sekitar 3,4 MB - kami sangat perlu memangkas beberapa bagian yang tidak perlu.

Hal ini memulai tantangan performa pertama kami: menemukan berbagai hal yang dapat dihapus dengan mudah tanpa memengaruhi keseluruhan pengalaman pengguna.

Peluang pengoptimalan performa

Menghapus referensi 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.

Pengompresian adalah tugas umum, sehingga Anda dapat menemukan solusi siap pakai untuk proses build apa pun yang kebetulan Anda gunakan.

Audit berguna lainnya di ruang tersebut adalah Aktifkan kompresi teks. Anda tidak perlu mengirim file yang tidak dikompresi, dan kini sebagian besar CDN mendukungnya.

Kami menggunakan Firebase Hosting untuk menghosting kode kami, dan Firebase mengaktifkan gzipping secara default, sehingga 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 sedang 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 kami selanjutnya adalah memastikan bahwa kami tidak mengirim resource dua kali jika tidak perlu.

Audit Kebijakan cache yang tidak efisien di Lighthouse membantu kami menyadari bahwa kami dapat mengoptimalkan strategi penyimpanan dalam cache 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 didownload sebelumnya.

Idealnya, Anda harus berusaha meng-cache sebanyak mungkin resource dengan aman selama mungkin, dan menyediakan 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 kita menyertakan kode aplikasi yang tidak terlalu diperlukan. 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 lagi 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 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. Anda dapat melihat dua garis merah besar di screenshot bawah - lebih dari 95% CSS kita tidak digunakan, dan juga banyak 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 tersebut.

Ini menjadikan paket CSS kami turun 20 kali lipat, yang cukup bagus untuk commit kecil dengan dua baris.

Tentu saja, hal ini membuat skor performa kami meningkat, dan juga Waktu Hingga Interaktif menjadi jauh lebih baik.

Namun, dengan perubahan seperti ini, Anda tidak cukup hanya memeriksa metrik dan skor. Menghapus kode yang sebenarnya tidak akan pernah bebas risiko, jadi Anda harus selalu waspada terhadap potensi regresi.

Kode kita tidak digunakan dalam 95% - masih ada 5% di suatu tempat. Rupanya salah satu komponen kami masih menggunakan gaya dari library tersebut - panah kecil di penggeser doodle. Karena ukurannya sangat kecil, kita bisa memasukkan gaya tersebut kembali ke tombol secara manual.

Jadi, jika Anda menghapus kode, pastikan Anda memiliki alur kerja pengujian yang tepat untuk membantu Anda menjaga terhadap potensi regresi visual.

Menghindari payload jaringan yang sangat besar

Kita tahu bahwa resource yang besar dapat memperlambat pemuatan halaman web. Hal ini dapat merugikan pengguna dan dapat 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, kita melihat bahwa kita memiliki kode senilai lebih dari 3 MB yang dikirimkan – yang cukup banyak, terutama di perangkat seluler.

Di bagian paling atas daftar ini, Lighthouse menyoroti bahwa kami memiliki paket vendor JavaScript yang berukuran 2 MB kode yang tidak dikompresi. Hal ini juga merupakan masalah yang disoroti 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 membuat keputusan apakah aset tersebut benar-benar layak dikirimkan dengan pengalaman awal. Karena terkadang aset ini dapat ditangguhkan, dimuat dengan lambat, atau diproses selama waktu tidak ada aktivitas.

Dalam kasus kami, karena kami menangani 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 bahwa kami menyertakan dependensi yang disebut unicode, yaitu 1,6 mb dari JavaScript yang diurai, dalam jumlah sangat banyak.

Kemudian, kita membuka editor dan menggunakan Plugin Biaya Impor untuk kode Visual, kita dapat memvisualisasikan biaya setiap modul yang kita impor. Hal ini memungkinkan kita menemukan komponen mana yang menyertakan kode yang mereferensikan modul ini.

Kemudian, kami beralih ke alat lain, BundlePhobia. Ini adalah alat yang memungkinkan Anda memasukkan nama paket NPM dan benar-benar melihat perkiraan ukurannya yang diminifikasi dan di-gzip. Kami menemukan alternatif yang bagus untuk modul slug yang kami gunakan yang beratnya hanya 2,2 kb, jadi kami menggantinya.

Hal ini berdampak besar pada performa kami. Antara perubahan ini dan menemukan peluang lain untuk memangkas ukuran paket JavaScript, kami menghemat 2,1 MB kode.

Kami melihat peningkatan sebesar 65% secara keseluruhan, setelah Anda memperhitungkan ukuran paket ini yang dikompresi dengan gzip dan diminifikasi. Dan kami mendapati bahwa proses ini benar-benar layak dilakukan.

Jadi, secara umum, cobalah untuk meniadakan download yang tidak perlu di situs dan aplikasi Anda. Membuat inventaris aset dan mengukur dampaknya terhadap performa dapat memberikan dampak yang sangat besar, jadi pastikan Anda mengaudit aset secara rutin.

Menurunkan waktu booting JavaScript dengan pemisahan kode

Meskipun payload jaringan yang besar dapat berdampak besar pada aplikasi kita, ada hal lain yang dapat memiliki dampak yang sangat besar, yaitu JavaScript.

JavaScript adalah aset termahal Anda. Di perangkat seluler, jika Anda mengirimkan paket JavaScript dalam jumlah besar, hal ini dapat menunda seberapa cepat pengguna dapat berinteraksi dengan komponen antarmuka pengguna Anda. Artinya, mereka dapat mengetuk UI tanpa ada hal yang bermakna yang benar-benar terjadi. Jadi, penting bagi kita untuk memahami mengapa JavaScript memiliki biaya yang begitu besar.

Inilah cara browser memproses JavaScript.

Pertama-tama, kita harus mendownload skrip tersebut, kita memiliki mesin JavaScript yang kemudian perlu mengurai kode tersebut, perlu mengompilasi dan mengeksekusinya.

Sekarang, fase ini adalah sesuatu yang tidak memerlukan banyak waktu di perangkat kelas atas seperti komputer desktop atau laptop, bahkan mungkin ponsel kelas atas. Namun, pada ponsel median, proses ini dapat memerlukan waktu 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 tersebut memberi tahu kita bahwa kita menghabiskan waktu 1,8 detik dalam proses booting JavaScript. Yang terjadi adalah kami mengimpor secara statis semua rute dan komponen ke dalam satu paket JavaScript monolitik.

Salah satu teknik untuk mengatasi hal ini adalah menggunakan pemisahan kode.

Pemisahan kode adalah gagasan tentang alih-alih memberikan JavaScript satu per satu kepada pengguna, bagaimana jika Anda hanya memberi mereka satu irisan sekaligus sesuai kebutuhan mereka?

Pemisahan kode dapat diterapkan di tingkat rute atau tingkat komponen. Library 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, yang memungkinkan kami memuat kode secara asinkron sesuai kebutuhan.

Dampaknya adalah mengecilkan ukuran paket, tetapi juga mengurangi waktu booting JavaScript. Waktu yang dibutuhkan menjadi 0,78 detik, membuat aplikasi 56% lebih cepat.

Secara umum, jika Anda membuat pengalaman yang berat JavaScript, pastikan untuk hanya mengirim kode kepada pengguna yang mereka butuhkan.

Manfaatkan konsep seperti pemisahan kode, jelajahi ide-ide seperti tree shaking, dan lihat repo webpack-libs-optimizations untuk mengetahui beberapa ide tentang cara memangkas ukuran library jika Anda kebetulan menggunakan webpack.

Mengoptimalkan gambar

Di aplikasi Oodle, kita menggunakan banyak gambar. Sayangnya, Lighthouse tidak terlalu antusias dengan hal ini. Faktanya, kami gagal dalam ketiga audit terkait gambar.

Kita lupa mengoptimalkan gambar, kita tidak menyesuaikan ukurannya dengan benar, dan kita juga bisa mendapatkan beberapa manfaat dari penggunaan format gambar lain.

Kita 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 dapat memastikan bahwa gambar yang ditambahkan di 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, ukurannya turun menjadi 100 kb, yang dapat diterima.

Pengulangan hal ini untuk beberapa gambar di situs memungkinkan kami menurunkan 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 menghemat banyak 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 berbobot sekitar 7,3 mb, terlalu banyak untuk situs web 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% dari keseluruhan bobot berkat konversi ini. Hal ini membuat ukuran menjadi sekitar 1 mb.

Namun, 1 MB adalah resource yang besar untuk dikirimkan, terutama bagi pengguna dengan lebar bandwidth yang dibatasi. Untungnya, kita dapat menggunakan Effective Type API untuk mengetahui bahwa mereka menggunakan bandwidth yang lambat, dan memberi mereka JPEG yang jauh lebih kecil.

Antarmuka ini menggunakan waktu bolak-balik efektif dan nilai downing 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 mengurangi sedikit pengalaman, tetapi setidaknya situs dapat digunakan pada koneksi lambat.

Gambar di luar layar pemuatan lambat

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 sendiri di panel jaringan DevTools. Jika Anda melihat banyak gambar masuk, tetapi hanya beberapa yang terlihat di halaman, berarti Anda dapat mempertimbangkan untuk memuat gambar 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.

<!-- 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 melakukan pengambilan data secara proaktif pada elemen yang berada di dekat tampilan untuk pengalaman pengguna yang optimal. API ini 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 lebih lanjut topik tersebut, lihat images.guide - referensi yang sangat praktis dan komprehensif.

Membantu browser mengirimkan resource penting lebih awal

Tidak setiap byte yang dikirim melalui jaringan ke browser memiliki tingkat substansi yang sama, dan browser mengetahui hal ini. Banyak browser memiliki heuristik untuk menentukan apa yang harus diambil terlebih dahulu. Jadi, terkadang CSS akan diambil sebelum gambar atau skrip.

Sesuatu yang mungkin bermanfaat 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 kita dalam hal ini, misalnya petunjuk resource seperti link rel=preconnect, atau preload atau prefetch.

Kemampuan ini yang dibawa ke platform web 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 cara Lighthouse memandu kita untuk menggunakan beberapa fitur ini secara efektif.

Hal pertama yang disarankan Lighthouse untuk dilakukan adalah menghindari beberapa perjalanan bolak-balik yang mahal ke asal mana pun.

Dalam kasus aplikasi Oodle, kami sebenarnya banyak menggunakan Google Fonts. Setiap kali Anda menempatkan stylesheet Google Font ke halaman, stylesheet tersebut akan terhubung ke maksimal dua subdomain. Dan yang disampaikan Lighthouse adalah jika kita dapat melakukan pemanasan koneksi tersebut, kita dapat menghemat hingga 300 milidetik waktu koneksi awal.

Dengan memanfaatkan preconnect link link, kita dapat menyamarkan latensi koneksi tersebut secara efektif.

Apalagi dengan Google Fonts tempat CSS tampilan font kita dihosting di googleapis.com, dan resource font kita dihosting di Gstatic, hal ini dapat berdampak sangat besar. Jadi, kami menerapkan pengoptimalan ini dan menghemat waktu beberapa ratus milidetik.

Hal berikutnya yang disarankan Lighthouse adalah kita melakukan pramuat permintaan kunci.

<link rel=preload> sangat canggih 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 memuat dan memuat ulang resource font web utama, karena kita memuat dua font web.

Melakukan pramuat dalam font web akan terlihat seperti ini - dengan menentukan rel=preload, Anda meneruskan as dengan jenis font, lalu menentukan jenis font yang Anda coba muat, seperti woff2.

Dampak yang dapat ditimbulkan terhadap halaman Anda sangat mencolok.

Biasanya, tanpa menggunakan pramuat rel link, jika font web kebetulan sangat penting untuk halaman Anda, yang harus dilakukan browser adalah pertama-tama mengambil HTML, mengurai CSS, dan di lain waktu, browser akan mengambil font web Anda.

Dengan menggunakan pramuat rel link, segera setelah browser menguraikan HTML Anda, browser tersebut dapat mulai mengambil font web tersebut lebih awal. Dalam kasus aplikasi kita, hal ini dapat menghemat waktu satu detik dari waktu yang diperlukan untuk merender teks menggunakan font web.

Sekarang, prosesnya tidak semudah itu jika Anda akan mencoba memuat font secara otomatis menggunakan Google Fonts. Ada satu hal yang perlu diperhatikan.

URL Google Font yang kami tentukan pada tampilan font di stylesheet kami ternyata merupakan sesuatu yang diperbarui oleh tim font secara cukup rutin. Masa berlaku URL ini dapat berakhir, atau diperbarui secara rutin, jadi tindakan yang sebaiknya Anda lakukan jika menginginkan kontrol penuh atas pengalaman pemuatan font adalah menghosting sendiri font web Anda. Hal ini dapat menjadi hal yang bagus karena memberi Anda akses ke hal-hal seperti pramuat rel link.

Dalam kasus ini, kami mendapati bahwa alat Google Web Fonts Helper sangat berguna dalam membantu offline beberapa font web tersebut dan menyiapkannya secara lokal. Jadi, periksa alat tersebut.

Baik Anda menggunakan font web sebagai bagian dari resource penting, atau kebetulan 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, serta pramuat, kami telah mengerjakan fitur browser eksperimental baru yang kami sebut petunjuk prioritas.

Ini adalah fitur baru yang memungkinkan Anda memberi tahu browser seberapa penting suatu resource. Fitur ini mengekspos atribut baru - importance - dengan nilai rendah, tinggi, atau otomatis.

Hal ini memungkinkan kita menyampaikan penurunan 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 gambar utama.

Dalam kasus aplikasi Oodle, hal ini sebenarnya mengarah ke satu tempat praktis yang dapat kami optimalkan.

Sebelum menambahkan pemuatan lambat ke gambar, browser melakukan hal berikut: kita memiliki carousel gambar dengan semua doodle dan browser mengambil semua gambar di awal carousel dengan prioritas tinggi sejak awal. Sayangnya, gambar di tengah carousel itulah yang paling penting bagi pengguna. Jadi yang kami lakukan adalah, kami menyetel nilai penting gambar latar tersebut ke sangat rendah, gambar latar depan ke sangat tinggi, dan dampak ini adalah dampak dua detik melalui 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 pantau terus.

Memiliki strategi pemuatan font web

Tipografi adalah dasar dari desain yang baik, dan jika Anda menggunakan font web, sebaiknya Anda tidak memblokir rendering teks, dan Anda pasti tidak ingin menampilkan teks yang tidak terlihat.

Sekarang kami menyoroti hal ini di Lighthouse, dengan audit hindari teks yang tidak terlihat saat font web dimuat.

Jika memuat font web menggunakan blok tampilan font, Anda mengizinkan browser memutuskan tindakan yang akan dilakukan jika font web tersebut memerlukan waktu lama untuk diambil. Beberapa browser akan menunggu hingga tiga detik untuk ini sebelum kembali ke font sistem, dan pada akhirnya akan menukarnya dengan font setelah didownload.

Kami mencoba menghindari teks yang tidak terlihat ini, jadi dalam hal ini kita 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 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 akan dirender atau diganti berdasarkan waktu yang diperlukan untuk menukar font web.

Dalam hal ini, kita menggunakan penggantian tampilan font. Swap memberi font periode pemblokiran nol detik, dan periode swap tak terbatas. Artinya, browser akan segera menggambar teks Anda dengan font pengganti jika font memerlukan waktu beberapa saat untuk dimuat. Dan akan menukarnya setelah font tersedia.

Dalam kasus aplikasi kita, hal ini sangat bagus karena memungkinkan kita menampilkan beberapa teks yang bermakna sejak awal, dan bertransisi ke font web setelah siap.

Secara umum, jika Anda kebetulan 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 lihat juga repo Web Font Recipes Zach Leatherman, karena sangat bagus.

Kurangi skrip yang memblokir render

Ada bagian lain dari aplikasi yang dapat kita kirim lebih awal dalam rantai download untuk memberikan setidaknya beberapa pengalaman pengguna dasar sedikit lebih awal.

Di strip linimasa Lighthouse, Anda dapat melihat bahwa selama beberapa detik pertama, saat semua resource dimuat, pengguna tidak dapat benar-benar melihat konten apa pun.

Mendownload dan memproses stylesheet eksternal menghalangi proses rendering kami sehingga tidak dapat melakukan progres.

Kita dapat mencoba mengoptimalkan jalur rendering penting dengan mengirimkan beberapa gaya sedikit lebih awal.

Jika kita mengekstrak gaya yang bertanggung jawab untuk rendering awal ini dan menyisipkannya dalam HTML, browser dapat langsung merendernya tanpa menunggu lembar gaya eksternal tiba.

Dalam kasus ini, kami menggunakan modul NPM yang disebut Critical untuk menyematkan konten penting di index.html selama langkah build.

Meskipun modul ini melakukan sebagian besar pekerjaan berat untuk kita, masih sedikit rumit untuk membuat modul ini 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.

Itulah sebabnya penting untuk mempertimbangkan performa sejak awal. Jika Anda tidak mendesain untuk performa dari awal, ada 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 pertama yang signifikan secara signifikan.

Hasil

Itu adalah daftar panjang pengoptimalan performa yang kami terapkan ke situs kami. Mari kita lihat hasilnya. Ini adalah cara aplikasi kami dimuat di perangkat seluler berukuran sedang pada jaringan 3G, sebelum dan setelah pengoptimalan.

Skor performa Lighthouse meningkat dari 23 menjadi 91. Itu adalah progres yang cukup bagus dalam hal kecepatan. Semua perubahan ini 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 PR yang diposting di sana.

Performa prediktif - pengalaman pengguna berbasis data

Kami percaya bahwa machine learning merupakan peluang yang menarik untuk masa depan di banyak bidang. Salah satu ide yang kami harap akan memicu lebih banyak eksperimen di masa mendatang adalah bahwa data nyata benar-benar dapat 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 perlu diambil data-datanya, dipramuat, atau di-pra-cache. Jika tebakan kita benar, kita dapat memprioritaskan sejumlah kecil resource, tetapi sangat sulit untuk menskalakannya ke seluruh situs.

Kami sebenarnya memiliki data yang tersedia untuk mengoptimalkan pengoptimalan kami saat ini. Dengan Google Analytics Reporting API, kita dapat melihat persentase halaman teratas dan keluar berikutnya untuk setiap URL di situs, sehingga dapat menarik kesimpulan tentang resource yang harus diprioritaskan.

Jika menggabungkan ini dengan model probabilitas yang baik, kita dapat menghindari pemborosan data pengguna dengan pengambilan data konten yang berlebihan secara agresif. Kita dapat memanfaatkan data Google Analytics tersebut, dan menggunakan machine learning serta model seperti rantai Markov atau neural network untuk menerapkan model tersebut.

Untuk memfasilitasi eksperimen ini, dengan senang hati kami umumkan 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 lebih dari itu. Semuanya bersifat open source dan tersedia di GitHub sekarang. 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 membantu meningkatkan kecepatan Web, tetapi keduanya hanyalah sarana, bukan tujuan itu sendiri.

Kita semua pernah mengalami pemuatan halaman yang lambat kapan saja di mana saja, tetapi kini kita dapat memberikan pengalaman menyenangkan yang lebih menyenangkan kepada pengguna dan dapat dimuat 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.