Smashing Podcast Episode 34 Dengan Harry Roberts: Bagaimana Kondisi Kinerja Web?

Diterbitkan: 2022-03-10

Ringkasan cepat Dalam episode ini, kita berbicara tentang Performa Web. Seperti apa lanskap performa di tahun 2021? Drew McLellan berbicara dengan ahli Harry Roberts untuk mencari tahu.

Dalam episode ini, kita berbicara tentang Performa Web. Seperti apa lanskap performa di tahun 2021? Saya berbicara dengan ahli Harry Roberts untuk mencari tahu.

Tampilkan Catatan

Harry menjalankan lokakarya Web Performance Masterclass dengan Smashing pada Mei 2021. Pada saat penerbitan, diskon awal yang besar masih tersedia.

Harry di Twitter
Situs konsultasi Harry, CSS Wizardry
Kursus video Semua yang Telah Saya Lakukan untuk Membuat CSS Wizardry Cepat termasuk diskon 15%
Pertanyaan untuk eBook Konsultan termasuk diskon 15%
Panduan Web.dev untuk Web Vitals
Pengocok telur OXO GoodGrips favorit Drew

Update mingguan

Tren Desain Web 2021: Laporan yang ditulis oleh Suzanne Scacca
Menggunakan Grommet Dalam Aplikasi Bereaksi yang ditulis oleh Fortune Ikechi
Cara Membangun API Node.js Untuk Ethereum Blockchain yang ditulis oleh John Agbanusi
Bagaimana Kami Meningkatkan Kinerja SmashingMag yang ditulis oleh Vitaly Friedman
When To Say No To Freelance Projects yang ditulis oleh Becca Kennedy

Salinan

Foto Charlie Gerard Drew McLellan: Dia adalah Konsultan Insinyur Kinerja Web independen dari Leeds di Inggris. Dalam perannya, dia membantu beberapa organisasi terbesar dan paling dihormati di dunia untuk memberikan pengalaman yang lebih cepat dan lebih andal kepada pelanggan mereka. Dia adalah Pakar Pengembang Google yang diundang, Pakar Pengembang Media Cloudinary, pengembang pemenang penghargaan, dan pembicara internasional. Jadi kita tahu dia tahu barang-barangnya dalam hal kinerja web, tetapi tahukah Anda bahwa dia memiliki 14 lengan dan tujuh kaki? Teman-teman Smashing saya, tolong sambut Harry Roberts. Hai Harry, apa kabar?

Harry Roberts: Hei, terima kasih banyak. Jelas bahwa 14 lengan, tujuh kaki… masih menimbulkan masalah seperti biasanya. Tidak mungkin membeli celana.

Drew: Dan sepeda.

Harry: Ya. Yah saya punya tiga setengah sepeda.

Drew: Jadi saya ingin berbicara dengan Anda hari ini, sayangnya, bukan tentang sepeda, meskipun itu sendiri akan menyenangkan. Saya ingin berbicara dengan Anda tentang kinerja web. Ini adalah subjek yang secara pribadi sangat saya sukai, tetapi itu adalah salah satu area di mana saya khawatir, ketika saya mengalihkan pandangan dari bola dan terlibat dalam beberapa jenis pekerjaan lain dan kemudian kembali melakukan sedikit kinerja, Saya khawatir bahwa pengetahuan yang sedang saya kerjakan akan ketinggalan zaman dengan sangat cepat… Apakah kinerja web saat ini bergerak secepat yang saya rasakan?

Harry: Ini... Aku bahkan tidak hanya mengatakan ini untuk bersikap baik padamu, itu pertanyaan yang bagus karena aku sudah memikirkan ini belakangan ini dan aku akan mengatakan ada dua bagian. Satu hal yang akan saya coba dan katakan kepada klien adalah bahwa sebenarnya itu tidak bergerak secepat itu. Terutama karena, dan ini adalah soundbite yang selalu saya gunakan, Anda bisa bertaruh di browser. Peramban tidak benar-benar diizinkan untuk mengubah cara kerjanya secara mendasar, karena, tentu saja, ada warisan dua dekade yang harus mereka junjung. Jadi, secara umum, jika Anda bertaruh pada browser dan Anda tahu cara kerja internal tersebut, dan TCP/IP yang tidak pernah berubah… Jadi, hal-hal tertentu yang ditetapkan secara wajar, yang berarti bahwa praktik terbaik akan, pada umumnya, selalu praktik terbaik yang menyangkut dasar-dasarnya.

Harry: Hal yang semakin menarik adalah… Hal yang semakin sering saya lihat adalah bahwa kita mengecat diri kita sendiri ketika datang ke masalah kecepatan situs. Jadi sebenarnya kita menciptakan banyak masalah bagi diri kita sendiri. Jadi apa artinya secara realistis adalah kinerja… itu adalah tiang gawang yang bergerak, saya kira. Semakin lanskap atau topografi web berubah, dan cara pembuatannya serta cara kerja kami, kami menghadirkan tantangan baru bagi diri kami sendiri. Jadi munculnya lebih banyak pekerjaan pada klien menimbulkan masalah kinerja yang berbeda daripada yang kami selesaikan lima tahun lalu, tetapi masalah kinerja itu masih berkaitan dengan internal browser yang, pada umumnya, tidak berubah dalam lima tahun. Jadi banyak tergantung… Dan saya akan mengatakan pasti ada dua sisi yang jelas untuk itu… Saya mendorong klien saya bersandar pada browser, bersandar pada standar, karena mereka tidak bisa hanya diubah, tiang gawang tidak benar-benar bergerak . Tapi, tentu saja, itu perlu dipadukan dengan praktik pembangunan yang lebih modern dan, mungkin sedikit lebih menarik. Jadi Anda tetap ... Yah, saya akan mengatakan "Satu kaki di kedua kubu" tetapi dengan tujuh kaki saya, saya harus ... empat dan tiga.

Drew: Anda menyebutkan bahwa fundamental tidak berubah dan hal-hal seperti TCP/IP tidak berubah. Salah satu hal yang berubah di… Saya katakan “tahun-tahun terakhir”, ini sebenarnya mungkin akan sedikit mundur sekarang, tetapi, adalah HTTP di mana kami memiliki protokol HTTP yang mapan untuk berkomunikasi antara klien dan server, dan itu berubah dan kemudian kami mendapat H2 yang kemudian semuanya biner dan berbeda. Dan itu banyak mengubah… Itu karena alasan kinerja, itu untuk menghilangkan beberapa batasan yang ada, tapi itu adalah perubahan dan cara kami harus mengoptimalkan protokol itu berubah. Apakah itu sekarang stabil? Atau akan berubah lagi, atau…

Harry: Jadi satu hal yang ingin saya pelajari lebih lanjut adalah bagian terakhir dari pertanyaan, perubahan lagi. Saya perlu melihat lebih jauh ke dalam QUIC dan H3 tetapi agak terlalu jauh untuk berguna bagi klien saya. Ketika datang ke H2, banyak hal telah berubah tetapi saya benar-benar berpikir H2 adalah janji palsu dan saya percaya itu terburu-buru, yang luar biasa mengingat H1 diluncurkan… Dan maksud saya 1.1, adalah 1997, jadi kita punya banyak waktu untuk mengerjakan H2.

Harry: Saya kira manfaat utama adalah pengembang web yang memahaminya atau menganggapnya tidak terbatas dalam permintaan penerbangan sekarang. Jadi, daripada enam permintaan terkirim dan/atau enam dalam penerbangan sekaligus, berpotensi tidak terbatas, tidak terbatas. Membawa masalah yang sangat menarik karena… cukup sulit untuk dijelaskan tanpa bantuan visual tetapi Anda masih memiliki jumlah bandwidth yang sama, apakah Anda menjalankan H1 atau H2, protokol tidak membuat koneksi Anda lebih cepat. Jadi sangat mungkin Anda dapat membanjiri jaringan dengan meminta 24 file sekaligus, tetapi Anda tidak memiliki bandwidth yang cukup untuk itu. Jadi Anda tidak benar-benar mendapatkan lebih cepat karena Anda hanya dapat mengelola, mungkin, sebagian kecil dari itu pada suatu waktu.

Harry: Dan juga yang harus Anda pikirkan adalah bagaimana file-file itu merespons. Dan ini adalah tip pro lain yang saya lalui di lokakarya klien dan lain-lain. Orang-orang akan melihat air terjun H2 dan mereka akan melihat bahwa alih-alih enam permintaan pengiriman tradisional, mereka mungkin melihat 24. Mengirim 24 permintaan sebenarnya tidak terlalu berguna. Apa yang berguna adalah ketika tanggapan tersebut dikembalikan. Dan apa yang akan Anda perhatikan adalah bahwa Anda mungkin mengirimkan 24 permintaan, jadi sisi kiri air terjun Anda terlihat sangat bagus dan curam, tetapi semuanya kembali dengan cara berurutan yang agak terhuyung-huyung karena Anda perlu membatasi jumlah bandwidth sehingga Anda tidak dapat memenuhi semua respons secara bersamaan.

Harry: Nah, hal lain adalah jika Anda memenuhi semua respons pada saat yang sama, Anda akan menjadi respons interleaving. Jadi Anda malam mendapatkan 10% pertama dari setiap file dan 20% berikutnya ... 20% dari file JavaScript tidak berguna. JavaScript tidak dapat digunakan sampai 100% telah tiba. Jadi apa yang akan Anda lihat adalah, pada kenyataannya, cara air terjun H2 memanifestasikan dirinya ketika Anda melihat responsnya… Lagi pula, itu terlihat lebih mirip H1, jauh lebih terhuyung-huyung. Jadi, H2, saya pikir itu oversold, atau mungkin para insinyur tidak dituntun untuk percaya bahwa ada batasan seberapa efektifnya. Karena Anda akan melihat orang-orang melakukan sharding aset mereka secara berlebihan dan mereka mungkin memiliki dua puluh… mari kita pertahankan angka 24. Alih-alih memiliki dua file JS besar, Anda mungkin memiliki 24 bundel kecil. Mereka masih akan kembali cukup berurutan. Mereka semua tidak akan tiba pada saat yang sama karena Anda tidak meningkatkan bandwidth sendiri.

Harry: Dan masalah lainnya adalah setiap permintaan memiliki jumlah latensi yang konstan. Jadi, katakanlah Anda meminta dua file besar dan membutuhkan waktu seratus milidetik bolak-balik dan 250 milidetik untuk mengunduh, itu berarti dua kali 250 milidetik. Jika Anda mengalikan hingga 24 permintaan, Anda masih memiliki latensi konstan, yang telah kami putuskan 100 milidetik, jadi sekarang Anda memiliki latensi 2400 milidetik dan 24 kali… alih-alih unduhan 250 milidetik, katakanlah unduhannya 25 milidetik, itu sebenarnya memakan waktu lebih lama karena latensi tetap konstan dan Anda hanya mengalikan latensi itu dengan lebih banyak permintaan. Jadi saya akan melihat klien yang akan membaca bahwa H2 adalah peluru ajaib ini. Mereka akan pecah... Oh! Mereka tidak bisa menyederhanakan proses pengembangan, kita tidak perlu melakukan bundling atau concatenation dan lain-lain. Dan pada akhirnya itu akan berakhir lebih lambat karena Anda telah berhasil menyebarkan permintaan Anda, yang merupakan janji, tetapi latensi Anda tetap konstan sehingga Anda sebenarnya baru saja mendapatkan latensi n kali lebih banyak di browser. Seperti yang saya katakan, sangat sulit, mungkin tidak ada gunanya mencoba menjelaskannya tanpa visual, tetapi sungguh luar biasa bagaimana H2 memanifestasikan dirinya dibandingkan dengan apa yang diharapkan orang.

Drew: Apakah masih ada manfaat dalam proses sharding itu, oke, untuk mendapatkan keseluruhan masih membutuhkan jumlah waktu yang sama tetapi pada saat Anda mendapatkan 100% dari yang pertama 24 kembali Anda dapat mulai mengerjakannya dan Anda bisa mulai jalankan sebelum tanggal 24 selesai.

Harry: Oh, man, pertanyaan bagus lainnya. Jadi, tentu saja, jika semuanya berjalan dengan benar dan itu memanifestasikan dirinya dalam respons yang tampak lebih H1, idenya adalah mengajukan satu pengembalian terlebih dahulu, dua, tiga, empat, dan kemudian mereka dapat mengeksekusi dalam urutan mereka tiba. Jadi Anda benar-benar dapat mempersingkat waktu agregat dengan memastikan bahwa segala sesuatunya tiba pada waktu yang sama. Jika kami melihat halaman web alih-alih air terjun, dan Anda melihat bahwa permintaan disisipkan, itu berita buruk. Karena seperti yang saya katakan, 10% dari file JavaScript tidak berguna.

Harry: Jika server melakukan tugasnya dengan benar dan mengirim, mengirim, mengirim, mengirim, mengirim, maka itu akan menjadi lebih cepat. Dan kemudian Anda mendapat manfaat langsung dari strategi cache Anda yang bisa lebih terperinci. Sangat menjengkelkan jika Anda memperbarui ukuran font pada widget pemilih tanggal Anda. Di dunia H1 Anda harus cache bust mungkin 200 kilowatt CSS lebar situs Anda. Sedangkan sekarang, Anda hanya men-cache bust datepicker.css. Jadi kita punya keuntungan cabang seperti itu, yang pasti sangat berharga.

Drew: Saya kira, dalam skenario di mana Anda secara ajaib mendapatkan semua permintaan Anda kembali sekaligus, itu jelas akan berpotensi menghambat klien, bukan?

Harry: Ya, berpotensi. Dan kemudian apa yang sebenarnya terjadi adalah klien harus melakukan beban penjadwalan sumber daya sehingga Anda akan berakhir dengan air terjun di mana semua tanggapan Anda kembali pada saat yang sama, maka Anda akan memiliki kesenjangan yang cukup besar antara respon terakhir tiba dan kemampuannya untuk mengeksekusi. Jadi idealnya, ketika kita berbicara tentang JavaScript, Anda ingin browser meminta semuanya dalam urutan permintaan, pada dasarnya urutan yang Anda tentukan, server mengembalikan semuanya dalam urutan yang benar sehingga browser dapat mengeksekusi mereka dalam urutan yang benar. Karena, seperti yang Anda katakan, jika semuanya kembali pada saat yang sama, Anda baru saja menjalankan JavaScript besar-besaran sekaligus tetapi masih perlu dijadwalkan. Jadi Anda dapat memiliki keraguan hingga detik antara file yang tiba dan itu menjadi berguna. Jadi, sebenarnya, H1… Saya kira, idealnya, yang Anda cari adalah penjadwalan permintaan H2, tanggapan gaya H1, sehingga segala sesuatunya dapat dibuat berguna saat mereka tiba.

Drew: Jadi pada dasarnya Anda mencari air terjun respons yang sepertinya Anda bisa bermain ski di bawahnya.

Harry: Ya, persis.

Drew: Tapi Anda tidak perlu parasut.

Harry: Ya. Dan itu sangat sulit… Saya pikir untuk mengatakannya dengan lantang kedengarannya sangat sepele, tetapi mengingat cara H2 dijual, saya merasa cukup… tidak menantang karena itu membuat klien saya terdengar… bodoh… tapi cukup sulit untuk dijelaskan bagi mereka… jika Anda berpikir tentang cara kerja H1, itu tidak terlalu buruk. Dan jika kita mendapatkan tanggapan yang terlihat seperti itu dan “Oh ya, saya bisa melihatnya sekarang”. Saya harus mengajar insinyur kinerja ini sebelumnya. Orang yang melakukan apa yang saya lakukan. Saya harus mengajari performance engineer bahwa kami tidak terlalu mempermasalahkan saat permintaan dibuat, kami sangat peduli saat respons menjadi berguna.

Drew: Salah satu alasan mengapa segalanya tampak bergerak cukup cepat, terutama selama lima tahun terakhir, adalah karena kinerja adalah topik besar bagi Google. Dan ketika Google memberikan bobot di belakang sesuatu seperti ini, maka ia mendapatkan daya tarik. Pada dasarnya, kinerja adalah aspek dari pengalaman pengguna, bukan?

Harry: Oh, maksudku... ini podcast yang sangat bagus, aku memikirkan ini setengah jam yang lalu, aku berjanji padamu, aku memikirkan ini setengah jam yang lalu. Kinerja adalah aksesibilitas yang diterapkan. Anda menjamin atau meningkatkan kemungkinan seseorang dapat mengakses konten Anda dan saya pikir aksesibilitas selalu adil… Oh itu pembaca layar, bukan? Itu orang tanpa penglihatan. Keputusan untuk membangun situs web daripada aplikasi… keputusannya adalah mengakses lebih banyak audiens. Jadi ya, kinerja adalah aksesibilitas yang diterapkan, yang merupakan pengalaman pengguna. Dan pengalaman pengguna itu bisa sampai ke titik "Bisakah seseorang bahkan mengalami situs Anda". Atau bisa jadi “Apakah pengalaman itu menyenangkan? Ketika saya mengklik tombol, apakah itu merespons tepat waktu?”. Jadi saya 100% setuju dan saya pikir itulah banyak alasan mengapa Google memberikan bobot di atasnya, karena hal itu mempengaruhi pengalaman pengguna dan jika seseorang akan mempercayai hasil pencarian, kami ingin mencoba dan memberikan orang itu sebuah situs yang mereka tidak akan membenci.

Drew: Dan itu... semua yang Anda pikirkan, semua manfaat yang Anda pikirkan, pengalaman pengguna, hal-hal seperti peningkatan keterlibatan, itu benar bukan? Tidak ada yang membuat pengguna menjauh dari situs lebih cepat daripada pengalaman yang lamban. Ini sangat membuat frustrasi, bukan? Menggunakan situs di mana Anda tahu bahwa mungkin navigasinya tidak begitu jelas dan jika Anda mengklik tautan dan Anda berpikir “Apakah ini yang saya inginkan? Bukan?” Dan hanya biaya untuk membuat klik itu, hanya menunggu, dan kemudian Anda harus mengklik tombol kembali dan kemudian menunggu itu, dan itu hanya… Anda menyerah.

Harry: Ya, dan itu masuk akal. Jika Anda pergi ke supermarket dan Anda melihat supermarket itu benar-benar dipenuhi orang, Anda akan melakukannya seminimal mungkin. Anda tidak akan menghabiskan banyak uang di sana, itu seperti "Oh, saya hanya butuh susu", masuk dan keluar. Sedangkan jika itu pengalaman yang menyenangkan, Anda punya "Oh, baiklah, sementara saya di sini, saya akan melihat apakah ... Oh, ya mereka punya ini ... Oh, saya akan memasak ini besok malam" atau apa pun. Saya pikir masih, tiga dekade ke dalam web, bahkan orang yang membangun untuk web berjuang, karena itu tidak berwujud. Mereka berjuang untuk benar-benar berpikir bahwa apa yang akan mengganggu Anda di toko nyata akan mengganggu Anda secara online, dan memang demikian, dan statistik menunjukkan bahwa memang demikian.

Drew: Saya pikir pada hari-hari awal, saya berpikir akhir 90-an, menunjukkan usia saya di sini, ketika kami membangun situs web, kami sangat memikirkan kinerja tetapi kami memikirkan kinerja dari sudut pandang bahwa koneksi yang dimiliki orang-orang menggunakan sangat lambat. Kita berbicara tentang dial-up, modem, melalui saluran telepon, modem 28K, 56K, dan ada tren di satu titik dengan gambar gaya bahwa setiap baris gambar lainnya akan dikosongkan dengan warna solid untuk memberikan ini ... jika Anda dapat membayangkannya seperti melihat melalui tirai venesia pada gambar. Dan kami melakukannya karena membantu kompresi. Karena setiap baris lain algoritma kompresi bisa-

Harry: Runtuh menjadi satu pointer.

Drew: Ya. Jadi Anda telah mengurangi ukuran gambar Anda secara signifikan sambil tetap bisa mendapatkan… Dan itu menjadi elemen desain. Semua orang melakukannya. Saya pikir mungkin Jeffrey Zeldman adalah salah satu orang pertama yang mempelopori pendekatan itu. Tapi apa yang kami pikirkan terutama adalah seberapa cepat kami bisa menyelesaikannya. Bukan untuk pengalaman pengguna, karena kami tidak memikirkan… Maksud saya, saya kira itu adalah pengalaman pengguna karena pada dasarnya kami tidak ingin orang meninggalkan situs kami. Tapi kami berpikir untuk tidak mengoptimalkan hal-hal menjadi sangat cepat tetapi mencoba menghindarinya menjadi sangat lambat, jika itu masuk akal.

Harry: Ya, ya.

Drew: Dan kemudian, saya pikir ketika kecepatan seperti jalur ADSL menjadi lebih umum, kami berhenti memikirkan istilah itu dan mulai tidak memikirkannya sama sekali. Dan sekarang kami berada pada situasi di mana kami menggunakan perangkat seluler dan mereka memiliki koneksi yang terbatas dan mungkin CPU yang lebih lambat dan kami harus memikirkannya lagi, tetapi kali ini dalam hal mendapatkan keuntungan. Selain dari sisi pengalaman pengguna, itu dapat memiliki manfaat bisnis nyata dalam hal biaya dan kemampuan untuk menghasilkan keuntungan. bukan?

Harry: Ya, luar biasa. Maksudku, tidak yakin bagaimana mengatakannya. Tidak menembak diri saya sendiri di sini tetapi satu hal yang saya coba dan tekankan kepada klien adalah bahwa kecepatan situs akan memberi Anda keunggulan kompetitif tetapi hanya satu hal yang dapat memberi Anda beberapa keunggulan kompetitif. Jika Anda memiliki produk yang tidak ingin dibeli siapa pun, tidak peduli seberapa cepat situs Anda. Dan sama halnya, jika seseorang benar-benar menginginkan situs web tercepat di dunia, Anda harus menghapus gambar Anda, menghapus CSS Anda, menghapus JavaScript Anda, dan kemudian melihat berapa banyak produk yang Anda kirim, karena saya jamin kecepatan situs bukanlah faktornya. Tetapi penelitian telah menunjukkan bahwa ada manfaat besar dari menjadi cepat, hingga jutaan. Saya sedang bekerja dengan klien saat kita berbicara. Kami bekerja untuk mereka bahwa jika mereka dapat membuat halaman tertentu satu detik lebih cepat, atau lebih tepatnya konten terbesar mereka untuk cat adalah satu detik lebih cepat, itu bernilai 1,8 juta per tahun, yaitu… itu jumlah yang besar.

Drew: Itu hampir akan membayar biaya Anda.

Harry: Hei! Ya, hampir. Saya memang mengatakan kepada mereka, “Lihat, setelah dua tahun ini semua akan terbayar. Anda akan impas”. Saya harap. Tapi ya, apakah aspek client-facing… maaf, aspek customer-facing jika Anda memiliki situs E-Com, mereka akan menghabiskan lebih banyak uang. Jika Anda seorang penerbit, mereka akan membaca lebih banyak artikel atau mereka akan melihat lebih banyak menit konten, atau apa pun yang Anda lakukan itu adalah KPI yang Anda ukur. Bisa jadi di situs Smashing, bisa jadi mereka tidak terpental, mereka benar-benar mengklik beberapa artikel lagi karena kami membuatnya sangat mudah dan cepat. Dan kemudian situs yang lebih cepat lebih murah untuk dijalankan. Jika Anda telah menyortir strategi penyimpanan cache, Anda akan menjauhkan orang dari server Anda. Jika Anda mengoptimalkan aset Anda, apa pun yang berasal dari server Anda akan jauh lebih ringan. Jadi jauh lebih murah untuk dijalankan.

Harry: Masalahnya, ada biaya untuk sampai ke sana. Saya pikir Scott Jehl mungkin mengatakan salah satu yang paling ... Dan saya mendengarnya dari dia terlebih dahulu, jadi saya akan berasumsi dia datang dengan itu tetapi pepatah adalah "Sangat mudah untuk membuat situs web yang cepat tetapi sulit untuk membuat situs web cepat". Dan itu sangat ringkas. Karena alasan kinerja web mungkin didorong ke bawah daftar hal yang harus dilakukan adalah karena Anda mungkin dapat mengatakan kepada klien “Jika saya membuat situs Anda lebih cepat satu detik, Anda akan menghasilkan tambahan 1,8 juta setahun” atau bisa juga "Jika Anda baru saja menambahkan Apple Pay ke pembayaran Anda, Anda akan mendapat tambahan lima juta." Jadi ini bukan semua tentang kinerja web dan itu bukan faktor penentu, ini adalah salah satu bagian dari strategi yang jauh lebih besar, terutama untuk E-Com online. Tetapi buktinya adalah saya telah mengukurnya secara langsung dengan klien ritel saya, klien E-Com saya. Kasus untuk itu ada di sana, Anda benar sekali. Ini keunggulan kompetitif, itu akan membuat Anda lebih banyak uang.

Drew: Kembali ke masa lalu, sekali lagi, saya kembali ke masa lalu, tetapi orang-orang seperti Steve Souders adalah orang pertama yang benar-benar mulai menulis dan berbicara tentang kinerja web. Dan orang-orang seperti Steve pada dasarnya mengatakan "Lupakan infrastruktur backend, di mana semua keuntungan yang bisa didapat ada di browser, di front end, di situlah segala sesuatu yang lambat terjadi." Apakah itu masih terjadi 15 tahun kemudian?

Harry: Ya, ya. Dia mengulang tes di antara dulu dan sekarang, dan celahnya benar-benar melebar, jadi sebenarnya lebih mahal melalui kabel. Tetapi ada kontra untuk itu, yaitu jika Anda memiliki kinerja backend yang sangat buruk, jika Anda keluar dari gerbang dengan perlahan, hanya ada begitu banyak Anda dapat mencakar kembali di ujung depan. Saya mendapat klien saat ini, waktu mereka untuk byte pertama adalah 1,5 detik. Oleh karena itu, kami tidak pernah dapat merender lebih cepat dari 1,5 detik, jadi itu akan menjadi batas. Kami masih dapat mencakar waktu kembali di ujung depan tetapi jika Anda memiliki waktu yang sangat, sangat buruk untuk byte pertama, Anda mengalami penurunan yang lambat, ada batasan seberapa cepat upaya kinerja ujung depan Anda bisa mendapatkan Anda. Tapi benar-benar.

Harry: Itu, bagaimanapun, berubah karena... Yah, tidak, itu tidak berubah, kurasa, itu semakin buruk. Kami mendorong lebih banyak ke klien. Dulu kasus "Server Anda secepat itu tetapi kemudian setelah itu kami mendapat banyak tanda tanya." karena saya mendengar ini sepanjang waktu “Semua pengguna kami menggunakan WiFi. Mereka semua memiliki mesin desktop karena semuanya bekerja dari kantor kami.” Nah, tidak, sekarang mereka semua bekerja dari rumah. Anda tidak bisa memilih. Jadi, di situlah semua tanda tanya muncul di mana perlambatan terjadi, di mana Anda tidak dapat benar-benar mengendalikannya. Setelah itu, faktanya sekarang kita cenderung lebih mengutamakan klien. Maksud saya, seluruh waktu berjalan pada klien. Anda telah memindahkan semua logika aplikasi Anda dari server sehingga waktu Anda untuk byte pertama harus sangat, sangat minimal. Seharusnya kasus mengirim beberapa bundel dari CDM ke ... tetapi Anda telah beralih dari kemampuan untuk menentukan ke server Anda sendiri menjadi berharap bahwa seseorang tidak menjalankan Netflix di mesin yang sama dengan yang mereka coba lihat di situs web Anda. .

Drew: Ini adalah poin yang sangat bagus tentang cara kami mendesain situs dan saya pikir praktik terbaik tradisional selalu Anda harus mencoba dan melayani semua jenis browser, semua jenis kecepatan koneksi, semua jenis ukuran layar, karena Anda tidak tidak tahu apa yang diharapkan pengguna. Dan, seperti yang Anda katakan, Anda memiliki skenario di mana orang-orang berkata "Oh tidak, kami tahu semua pengguna kami menggunakan mesin desktop yang dikeluarkan untuk pekerjaan mereka, mereka menjalankan browser ini, ini adalah versi terbaru, mereka terhubung ke LAN" tapi kemudian hal-hal terjadi. Salah satu manfaat besar memiliki aplikasi web adalah kita dapat melakukan hal-hal seperti mendistribusikan tenaga kerja kita secara tiba-tiba kembali ke rumah mereka dan mereka dapat terus bekerja, tetapi itu hanya berlaku jika kualitas tekniknya sedemikian rupa sehingga seseorang yang berputar up mesin rumah mereka yang mungkin memiliki IE11 di atasnya atau apa pun, apakah kualitas pekerjaannya ada yang berarti bahwa web memenuhi potensinya untuk menjadi media yang benar-benar dapat diakses.

Drew: Seperti yang Anda katakan, ada tren untuk menggeser lebih banyak barang ke dalam browser, dan, tentu saja, jika browser lambat, di situlah kelambatan terjadi. Anda harus bertanya-tanya “Apakah ini tren yang bagus? Haruskah kita melakukan ini?” Saya punya satu situs yang secara khusus saya pikirkan, perhatikan bahwa hampir 100% server dirender. Ada sangat sedikit JavaScript dan sangat cepat. Setiap kali saya pergi ke sana saya berpikir "Oh, ini cepat, siapa yang menulis ini?" Dan kemudian saya menyadari "Oh ya, itu saya".

Harry: Itu karena Anda berada di localhost, tidak heran rasanya cepat. Ini adalah situs pengembang Anda.

Drew: Kemudian, pekerjaan harian saya, kami sedang membangun aplikasi satu halaman kami dan memindahkan barang-barang dari server karena server adalah penghambat dalam kasus itu. Bisakah Anda mengatakan bahwa lebih baik berada di browser? Atau lebih berkinerja untuk berada di server? Apakah ini hanya kasus mengukur dan mengambilnya berdasarkan kasus per kasus?

Harry: Saya pikir Anda harus sangat, sangat, sangat menyadari konteks Anda dan… sungguh, saya pikir kesalahannya adalah… narsisme di mana orang-orang berpikir “Oh, blog saya layak di-render di browser seseorang. Blog saya dengan rasio pentalan 89% membutuhkan runtime sendiri di browser, karena saya membutuhkan navigasi selanjutnya agar cepat, saya hanya ingin mengambil… pada dasarnya perbedaan data.” Tidak ada yang mengklik artikel Anda berikutnya, sobat, jangan memaksakan runtime ke pipa. Jadi, Anda harus sangat menyadari konteks Anda.

Harry: Dan saya tahu bahwa... jika Jeremy Keith mendengarkan ini, dia mungkin akan menyerang saya, tetapi, menurut saya, ada perbedaan antara situs web dan aplikasi web dan definisinya sangat, sangat keruh. Tetapi jika Anda memiliki aplikasi yang banyak membaca dan menulis, jadi sesuatu di mana Anda memasukkan data, memanipulasi data, dan lain-lain. Pada dasarnya situs saya bukan aplikasi web, ini adalah situs web, hanya dapat dibaca, yang akan saya masukkan dengan tegas ke dalam kamp situs web. Sesuatu seperti perangkat lunak akuntansi saya adalah aplikasi web, menurut saya adalah aplikasi web dan saya siap menanggung sedikit biaya waktu boot, karena saya tahu saya akan berada di sana selama 20 menit, satu jam, apa pun. Jadi Anda perlu sedikit konteks, dan sekali lagi, mungkin narsisme agak keras tetapi Anda harus memiliki "Apakah kita perlu membuat surat kabar ini sebagai aplikasi sisi klien?" Tidak. Tidak. Orang-orang telah mengaktifkan pemblokir iklan, orang-orang tidak menyukai situs surat kabar komuter. Mereka mungkin bahkan tidak akan membaca artikel itu dan mengoceh tentangnya di Facebook. Hanya saja, jangan membangun sesuatu seperti itu sebagai aplikasi yang diberikan klien, itu tidak cocok.

Harry: Jadi saya pikir pasti ada titik di mana bergerak lebih banyak ke klien akan membantu, dan saat itulah Anda kurang sensitif terhadap churn. Jadi semua jenis com, misalnya, saya melakukan audit sejenak untuk situs yang… Saya pikir itu situs E-Com tapi 100% pada klien. Anda menonaktifkan JavaScript dan Anda tidak melihat apa-apa, hanya div id=“aplikasi” yang kosong. E-Com adalah ... Anda sangat sensitif terhadap masalah apapun. Alur checkout Anda bahkan secara halus salah, saya pergi ke tempat lain. Ini terlalu lambat, aku pergi ke tempat lain. Anda tidak memiliki konteks di mana seseorang bersedia tidur di aplikasi itu untuk sementara waktu.

Harry: Photoshop. Saya membuka Photoshop dan saya cukup senang mengetahui bahwa itu akan memakan waktu 45 detik dari layar splash karena saya akan berada di sana selama ... pada dasarnya 45 detik bernilai 45 menit. Dan itu sangat sulit untuk didefinisikan, itulah sebabnya saya benar-benar berjuang untuk meyakinkan klien "Tolong jangan lakukan ini" karena saya tidak bisa hanya mengatakan "Menurut Anda berapa lama pengguna Anda akan berada di sana". Dan Anda dapat memproksinya dari… jika rasio pentalan Anda 89% tidak dioptimalkan untuk tampilan halaman kedua. Turunkan rasio pentalan itu terlebih dahulu. Saya pikir pasti ada perpecahan tetapi apa yang akan saya katakan adalah bahwa kebanyakan orang jatuh di sisi yang salah dari garis itu. Kebanyakan orang menaruh barang-barang di klien yang seharusnya tidak ada di sana. CNN, misalnya, Anda tidak dapat membaca satu judul pun di situs web CNN sampai aplikasi JavaScript di-boot sepenuhnya. Satu-satunya hal yang diberikan server adalah header dan footer yang merupakan satu-satunya hal yang tidak dipedulikan orang.

Harry: Dan saya merasa itu hanya... Saya tidak tahu bagaimana kita sampai pada titik itu. Itu tidak akan pernah menjadi pilihan yang lebih baik. Anda mengirimkan halaman yang secara efektif tidak berguna yang kemudian mengatakan “Keren, saya akan mengambil apa yang akan menjadi aplikasi web tetapi kami akan menjalankannya di browser, lalu saya akan pergi dan meminta judul , lalu kamu bisa mulai… oh, kamu pergi.” Itu benar-benar membuatku kesal.

Harry: Dan itu bukan salah siapa-siapa, saya pikir ini adalah awal dari ekosistem JavaScript semacam ini, hype di sekitarnya, dan juga, ini akan terdengar sangat kasar tapi… Ini pada dasarnya banyak implementasi yang naif. Tentu, Facebook telah menemukan React dan apa pun, itu bekerja untuk mereka. Sembilan dari 10 Anda tidak bekerja pada skala Facebook, 95 kali dari 100 Anda mungkin bukan insinyur Facebook yang paling cerdas, dan itu benar-benar kejam dan kedengarannya mengerikan untuk dikatakan, tetapi Anda hanya bisa mendapatkan… Tidak satu pun dari hal-hal ini cepat secara default. Anda memerlukan implementasi yang sangat, sangat elegan dari hal-hal ini untuk membuatnya benar.

Harry: Saya sedang berdiskusi dengan teman lama saya ... dia adalah seorang insinyur utama di skuad yang saya ikuti 10 tahun yang lalu di Sky. Saya berbicara dengannya beberapa hari yang lalu tentang ini dan dia harus bekerja sangat keras untuk membuat aplikasi yang dirender klien dengan cepat, sedangkan membuat aplikasi yang dirender server dengan cepat, Anda tidak perlu melakukan apa pun. Anda hanya perlu tidak membuatnya lambat lagi. Dan saya merasa seperti ada banyak kacamata berwarna mawar, kenaifan, pemasaran… Saya terdengar sangat suram, kita harus pindah sebelum saya benar-benar kehilangan orang di sini.

Drew: Apakah menurut Anda kami memiliki kecenderungan, sebagai industri, untuk lebih fokus pada pengalaman pengembang daripada pengalaman pengguna kadang-kadang?

Harry: Tidak secara keseluruhan, tapi saya pikir masalah itu muncul di tempat yang Anda harapkan. Jika Anda melihat perbedaannya… Saya tidak tahu apakah Anda pernah melihat ini, tetapi saya akan menganggap Anda pernah melihatnya, Anda tampaknya sangat memperhatikan, perbedaan antara data arsip HTTP tentang kerangka kerja dan Pustaka JavaScript digunakan di alam liar versus keadaan survei JavaScript, jika Anda mengikuti keadaan survei JavaScript, itu akan mengatakan "Oh ya, 75% pengembang menggunakan React" sedangkan kurang dari 5% situs menggunakan React. Jadi, saya merasa seperti, secara massal, saya tidak berpikir itu masalah, tapi saya pikir di bidang yang Anda harapkan, loyalitas yang tinggi untuk satu kerangka misalnya, pengalaman pengembang adalah ... diinjili mungkin di depan pengguna. Saya tidak berpikir pengalaman pengembang harus diabaikan, maksud saya, semuanya memiliki biaya pemeliharaan. Mobilmu. Ada keputusan ketika dirancang bahwa "Yah, jika kita menyembunyikan kunci ini, fungsi itu, dari seorang mekanik, itu akan memakan waktu lebih lama untuk memperbaikinya, oleh karena itu kita tidak melakukan hal-hal seperti itu". Jadi memang perlu ada keseimbangan antara ergonomi dan kegunaan, menurut saya itu penting. Saya pikir berfokus terutama pada pengalaman pengembang hanya membingungkan saya. Jangan optimalkan untuk Anda, optimalkan untuk pelanggan Anda, pelanggan Anda membayar Anda, bukan sebaliknya.

Drew: Jadi ruang gema online tidak sepenuhnya mewakili kenyataan ketika Anda melihat semua orang berkata "Oh Anda harus menggunakan ini, Anda harus melakukan itu" maka itu sebenarnya hanya sebagian kecil orang.

Harry: Benar, dan itu hal yang baik, itu meyakinkan. Ruang gema… mungkin tidak sehat memiliki monokultur seperti itu, jika Anda ingin menyebutnya demikian. Tetapi juga, saya merasa seperti… dan saya telah melihatnya di banyak pekerjaan saya sendiri, banyak pengembang… Sebagai konsultan, saya bekerja dengan banyak perusahaan yang berbeda. Banyak orang melakukan pekerjaan luar biasa di WordPress. Dan WordPress mendukung 24% web. Dan saya rasa bisa sangat mudah bagi pengembang seperti itu yang bekerja di sesuatu seperti WordPress atau PHP di backend, kode kustom, apa pun itu, untuk merasa seperti “Oh, saya kira semua orang menggunakan React dan kami tidak. ” tapi sebenarnya, tidak. Semua orang berbicara tentang Bereaksi tetapi Anda masih mengikuti arus, Anda masih dengan mayoritas. Ini cukup meyakinkan untuk menemukan mayoritas diam.

Drew: Tren menuju generator situs statis dan kemudian menghosting situs sepenuhnya pada CDN, semacam pendekatan JAMstack, saya kira ketika kita berbicara tentang jenis situs jenis penerbitan itu, daripada situs jenis perangkat lunak, saya kira itu tren yang sangat sehat , menurutmu?

Harry: Saya suka itu, tentu saja. Anda ingat ketika kami biasa memanggil SSG "file flap", bukan?

Drew: Ya.

Harry: Jadi, saya membangun CSS Wizardry di Jekyll saat Jekyll disebut sebagai situs web file flap. But now we service our generator, huge, huge fan of that. There's no disadvantage to it really, you pay maybe a slightly larger up front compute cost of pre-compiling the site but then your compute cost is… well, Cloudflare fronts it, right? It's on a CDN so your application servers are largely shielded from that.

Harry: Anything interactive that does need doing can be done on the client or, if you want to get fancy, what one really nice approach, if you are feeling ambitious, is use Edge Side Includes so you can keep your shopping cart server rendered, but at the edge. You can do stuff like that. Tremendous performance benefits there. Not appropriate for a huge swathe of sites, but, like you say, if we're thinking publishing… an E-Com site it wouldn't work, you need realtime stock levels, you need… search that doesn't just… I don't know you just need far more functionality. But yeah, I think the Smashing site, great example, my site is an example, much smaller than Smashing but yeah, SSG, flap filers, I'm really fond of it.

Drew: Could it work going deeper into the JAMstack approach of shifting everything into the client and building an E-Commerce site? I think the Smashing E-Commerce site is essentially using JavaScript in the client and server APIs to do the actual functionality as service functions or what have you.

Harry: Yeah. I've got to admit, I haven't done any stuff with serverless. But yeah, that hybrid approach works. Perhaps my E-Commerce example was a bit clunky because you could get a hybrid between statically rendering a lot of the stuff, because most things on an E-Com site don't really change. You filter what you can do on the client. Search, a little more difficult, stock levels does need to go back to an API somewhere, but yeah you could do a hybrid for a definite, for an E-Com site.

Drew: Okay, so then it's just down to monitoring all those performance metrics again, really caring about the network, about latency, about all these sorts of things, because you're then leaning on the network a lot more to fetch all those individual bits of data. It hosts a new set of problems.

Harry: Yeah, I mean you kind of… I wouldn't say “Robbing Peter to pay Paul” but you are going to have to keep an eye on other things elsewhere. I've not got fully to the bottom of it, before anyone tweets it at us, but a client recently moved to an E-Commerce client. I worked with them two years ago and that site was already pretty fast. It was built on… I can't remember which E-Com platform, it was .net, hosted on IIS, server rendered, obviously, and it was really fast because of that. It was great and we just wanted to maintain, maybe find a couple of hundred milliseconds here and there, but really good. Half way through last year, they moved to client side React for key pages. PP… product details page, product listing page, and stuff just got marketable slower lower, much slower. To the point they got back in touch needing help again.

Harry: And one of the interesting things I spotted when they were putting a case for “We need to actually revert this”. I was thinking about all the…what's slower, obviously it's slower, how could doing more work ever be faster, blah blah blah. One of their own bullet points in the audit was: based on projections, their yearly hosting costs have gone up by a factor of 10 times. Because all of a sudden they've gone from having one application server and a database to having loads of different gateways, loads of different APIs, loads of different microservers they're calling on. It increased the surface area of their application massively. And the basic reason for this, I'll tell you exactly why this happened. The developer, it was a very small team, the developer who decided “I'm going to use React because it seems like fun” didn't do any business analysis. It was never expected of them to actually put forward a case of how much is it going to cost the dude, how much is it going to return, what's the maintenance cost of this?

Harry: And that's a thing I come up against really frequently in my work and it's never the developer's fault. It's usually because the business keeps financials away from the engineering team. If your engineers don't know the cost or value of their work then they're not informed to make those decisions so this guy was never to know that that was going to be the outcome. But yeah, interestingly, moving to a more microservice-y approach… And this is an outlier, and I'm not going to say that that 10 times figure is typical, it definitely seems atypical, but it's true that there is at least one incident I'm aware of when moving to this approach, because they just had to use more providers. It 10x'ed their… there's your 10 times engineer, increased hosting by 10 times.

Drew: I mean, it's an important point, isn't it? Before starting out down any particular road with architectural changes and things about doing your research and asking the right questions. If you were going to embark on some big changes, say you've got a really old website and you're going to structure it and you want it to be really fast and you're making all your technology choices, I mean it pays, doesn't it, to talk to different people in the business to find out what they want to be doing. What sort of questions should you be asking other people in the business as a web developer or as a performance engineer? Who should you be talking to you and what should you be asking them?

Harry: I've got a really annoying answer to the “Who should you be talking to?” And the answer is everyone should be available to you. And it will depend on the kind of business, but you should be able to speak to marketing “Hey, look, we're using this AB testing tool. How much does that cost as a year and how much do you think it nets as a year?” And that developer should feel comfortable. I'm not saying developers need to change their attitude, what I mean is the company should make the developers able to ask those kind of questions. How much does Optimizely cost as a year? Right, well that seems like a lot, does it make that much in return? Okay, whatever we can make a decision based on that. That's who you should be talking to and then questions you should ask, it should be things like…

Harry: The amount of companies I work will, they won't give their own developers to Google Analytics. How are you meant to build a website if you don't know who you're building it for? So the question should be… I work a lot with E-Com clients so every developer should things like “What is our average order value? What is our conversion rate? What is our revenue, how much do we make?” These things mean that you can at least understand that “Oh, people spend a lot of money on this website and I'm responsible for a big chunk of that and I need to take that responsibility.”

Harry: Beyond that, other things are hard to put into context, so for me, one of things that I, as a consultant, so this is very different to an engineer in the business, I need to know how sensitive you are to performance. So if a client gives me the average order value, monthly traffic, and their conversion rate, I can work out how much 100 milliseconds, 500 a second will save them a year, or return them, just based on those three numbers I can work out roughly “Well a second's worth 1.8 mil”. It's a lot harder for someone in the business to get all the back information because as a performance engineer it's second nature to me. But if you can work that kind of stuff out, it unlocks a load of doors. Okay, well if a second's work this much to us, I need to make sure that I never lose a second and if I can, gain a second back. And that will inform a lot of things going forward. A lot of these developers are kept quite siloed. “Oh well, you don't need to know about business stuff, just shut up and type”.

Drew: I've heard you say, it is quite a nice soundbite, that nobody wants a faster website.

Harry: Yeah.

Drew: What do you mean by that?

Harry: Well it kind of comes back to, I think I've mentioned it already in the podcast, that if my clients truly wanted the world's fastest website, they would allow me to go in and delete all their JavaScript, all their CSS, all their images. Give that customer a Times New Roman stack.

Harry: But fast for fast sake is… not chasing the wrong thing but you need to know what fast means to you, because, I see it all the time with clients. There's a point at which you can stop. You might find that your customer's only so sensitive to web perf that it might mean that getting a First Contentful Paint from four seconds to two seconds might give you a 10% increase in revenue, but getting from that two to a one, might only give you a 1% increase. It's still twice as fast, but you get minimal gains. So what I need to do with my clients is work out “How sensitive are you? When can we take our foot off the gas?” And also, like I said, towards the top of the show… You need to have a product that people want to buy.

Harry: If people don't want to buy your product, it doesn't matter how quickly you show them it, it'll just disgust them faster, I guess. Is your checkout flow really, really, really seamless on mobile, for example. So there's a number of factors. For me, and my clients, it'll be working out a sweet spot, to also working out “If getting from here to here is going to make you 1.8 mil a year, I can find you that second for a fraction of that cost.” If you want me to get you an additional second on top of that, it's going to get a lot harder. So my cost to you will probably go up, and that won't be an extra 1.8, because it's not lineal, you don't get 1.8 mil for every one second.

Harry: It will tail off at some point. And clients will get to a point where… they'll still be making gains but it might be a case of your engineering effort doubles, meaning your returns halve, you can still be in the green, hopefully it doesn't get more expensive and you're losing money on performance, but there's a point where you need to slow down. And that's usually things that I help clients find out because otherwise they will just keep chasing speed, speed, speed and get a bit blinkered.

Drew: Yeah, it is sort of diminishing returns, isn't it?

Harry: That's what I was look for-

Drew: Ya.

Harry: … diminishing returns, that's exactly it. Yeah, exactly.

Drew: And in terms of knowing where to focus your effort… Say you've got the bulk of your users, 80% of your users are getting a response within two, three seconds, and then you've got 20% who may be in the long-tail that might end up with responses five, ten seconds. Is it better to focus on that 80% where the work's really hard, or is it better to focus on the 20% that's super slow, where the work might be easier, but it's only 20%. How do you balance those sorts of things?

Harry: Drew, can you write all podcast questions for everyone else? Ini sangat bagus. Well, a bit of a shout out to Tim Kadlec, he's done great talks on this very topic and he calls it “The Long-Tail of Web Performance” so anyone listening who wants to look at that, Tim's done a lot of good firsthand work there. The 80, 20, let's just take those as good example figures, by the time you're dealing with the 80th percentile, you're definitely in the edge cases. All your crooks and web file data is based around 75th percentile. I think there's a lot of value investing in that top 20th percentile, the worst 20%. Several reasons for this.

Harry: First thing I'm going to start with is one of the most beautiful, succinct soundbites I've ever heard. And the guy who told me it, I can guarantee, did not mean it to be this impactful. I was 15 years old and I was studying product design, GCSE. Finally, a project, it was a bar stool so it was a good sign of things to come. And we were talking about how you design furniture. And my teacher basically said… I don't know if I should… I'm going to say his name, Mr. Brocklesby.

Harry: Dia menuntut rasa hormat tetapi dia adalah salah satu pemain, kami semua sangat menyukainya. Tapi dia sangat besar di setiap dimensi. Tingginya lebih dari enam kaki, tapi hanya anak besar. Orang besar, besar, besar, besar. Dan dia berkata kepada kami, “Jika Anda mendesain pintu, apakah Anda akan mendesainnya untuk orang kebanyakan?” Dan otak berusia 15 tahun berkata, "Yah, jika semua orang kira-kira 5'9 maka ya" Dia seperti, "Yah, segera, Harry tidak bisa menggunakan pintu itu." Anda tidak mendesain untuk rata-rata orang, Anda mendesain untuk ekstremitas karena Anda ingin itu berguna bagi kebanyakan orang. Jika Anda mendesain kursi untuk orang kebanyakan, Mr. Brocklesby tidak akan muat di dalamnya. Jadi dia mengajari saya dari usia yang sangat, sangat, desain hingga ekstremitas Anda.

Harry: Dan di mana itu menjadi sangat menarik di web perf adalah... Jika Anda membayangkan sebuah tangga, dan Anda mengambil tangga itu dengan bot... Oke, saya baru menyadari metafora saya mungkin... Saya akan tetap menggunakannya dan Anda bisa menertawakannya saya setelah itu. Bayangkan sebuah tangga dan Anda mengangkat tangga ke atas dengan anak tangga paling bawah. Dan itulah pengalaman terburuk Anda. Anda memilih anak tangga terbawah di tangga untuk mengangkatnya. Seluruh tangga menyertainya, seperti air pasang yang mengapungkan semua perahu. Alasan metafora tidak berfungsi adalah jika Anda mengambil tangga di anak tangga teratas, semuanya terangkat juga, itu adalah tangga. Dan metafora itu bahkan tidak berfungsi jika saya mengubahnya menjadi tangga tali, karena tangga tali kemudian, Anda mengangkat anak tangga terbawah dan tidak terjadi apa-apa selain… maksud saya adalah, jika Anda dapat meningkatkan pengalaman untuk persentil ke-90 Anda, itu harus naikkan itu untuk persentil ke-10 Anda, bukan?

Harry: Dan inilah mengapa saya memberi tahu klien, mereka akan mengatakan kepada saya hal-hal seperti "Oh, sebagian besar pengguna kami menggunakan 4G di iPhone" jadi oke, oke, dan kami mulai menguji 3G di Android, seperti "Tidak, tidak, sebagian besar pengguna kami adalah iPhone” oke… itu berarti rata-rata pengguna Anda akan memiliki pengalaman yang lebih baik tetapi siapa pun yang belum berada di persentil ke-50 akan semakin tertinggal. Jadi tetapkan standar yang cukup tinggi untuk diri Anda sendiri dengan menetapkan ekspektasi yang cukup rendah.

Harry: Maaf, saya punya kebiasaan buruk dalam memberikan jawaban yang sangat panjang untuk pertanyaan pendek. Tapi itu adalah pertanyaan yang fantastis dan, untuk mencoba dan menyimpulkan, 100% pasti saya setuju dengan Anda bahwa Anda ingin melihat ekor panjang itu, Anda ingin melihat itu… persentil ke-80 Anda karena jika Anda mengambil semua pengalaman di situs dan melihat median, dan Anda meningkatkan median, itu berarti Anda telah membuatnya lebih baik untuk orang-orang yang sudah cukup puas. 50% orang yang diabaikan secara efektif bukanlah pendekatan yang tepat. Dan ya, itu selalu kembali ke Mr Brocklesby yang mengatakan kepada saya "Jangan mendesain untuk orang biasa karena Harry tidak bisa menggunakan pintu". Oh, bagi siapa pun yang mendengarkan, saya 193 sentimeter, jadi saya cukup kurus, begitulah.

Drew: Dan semua lengan dan kaki itu.

Harry: Ya. Ini satu lagi yang bagus. Pacar saya baru-baru ini menemukan pengaturan aksesibilitas di iOS… jadi semua orang memiliki ponsel mereka dalam mode senyap, bukan? Tidak ada yang benar-benar memiliki telepon yang benar-benar berdering, semua orang mengaktifkannya dalam mode senyap. Dia menemukan bahwa “Oh Anda tahu, Anda dapat mengaturnya sehingga ketika Anda menerima pesan, blitz akan berkedip. Dan jika Anda mengetuk bagian belakang ponsel dua kali, itu akan melakukan tangkapan layar.” Dan ini adalah pengaturan aksesibilitas, ini dirancang untuk persentil ke-95 itu. Namun dia seperti "Oh, ini sangat berguna".

Harry: Sama dengan OXO Good Grips. OXO Good Grips, peralatan dapur. Aku punya banyak dari mereka di dapur. Mereka dirancang karena istri pendiri menderita radang sendi dan dia ingin membuat peralatan yang lebih nyaman. Dia merancang untuk persentil ke-99, kebanyakan orang tidak menderita radang sendi. Tetapi dengan merancang untuk persentil ke-99, secara tidak sengaja, semua orang seperti "Ya Tuhan, mengapa semua pengupas kentang tidak bisa senyaman ini?" Dan saya merasa seperti itu benar-benar... Saya suka perasaan senang atau anekdot yang saya suka keluarkan dalam skenario semacam ini. Tapi ya, jika Anda mengoptimalkannya… Nah, pasang naik mengapungkan semua perahu dan oleh karena itu mengoptimalkan ujung ekor orang dan Anda akan menangkap lebih banyak pelanggan yang lebih bahagia di atas itu.

Drew: Apakah Anda memiliki pengocok tangan manual OXO Good Grips?

Harry: Saya tidak. Saya tidak, apakah itu baik?

Drew: Lihat ke dalamnya. Ini sangat bagus.

Harry: Saya memiliki alat pengiris mandolin OXO Good Grips yang ujung jari saya lepas minggu lalu.

Drew: Ya, saya tidak akan mendekati salah satunya.

Harry: Ya, itu kesalahan bodoh saya sendiri.

Drew: Contoh lain dari pengalaman saya sendiri dengan katering untuk ekor panjang itu adalah, dalam proyek yang sedang saya kerjakan saat ini, ekor panjang itu tepat di akhir, Anda memiliki orang dengan kinerja paling lambat, tetapi jika ternyata jika Anda melihat siapa pelanggan itu, mereka adalah pelanggan paling berharga bagi bisnis-

Harry: Oke.

Drew: … karena mereka adalah organisasi terbesar dengan jumlah data paling banyak.

Harry: Benar.

Drew: Jadi mereka mengalami kemacetan karena mereka memiliki begitu banyak data untuk ditampilkan pada halaman dan halaman tersebut perlu difaktorkan ulang sedikit untuk membantu kasus penggunaan tersebut. Jadi mereka mengalami pengalaman paling lambat dan mereka, ketika sampai pada itu, membayar uang paling banyak dan membuat lebih banyak perbedaan daripada semua orang yang memiliki pengalaman yang sangat cepat karena mereka adalah pengguna gratis dengan sejumlah kecil data dan semuanya berfungsi dengan baik dan cepat.

Harry: Itu dimensi yang menarik, bukan? Sebenarnya, saya mengalami hal serupa… Saya tidak memiliki dampak bisnis yang sama seperti yang baru saja Anda jelaskan, tetapi saya bekerja dengan klien beberapa tahun yang lalu, dan CEO mereka menghubungi karena situs mereka lambat. Seperti, lambat, lambat, lambat. Benar-benar pria yang baik juga, dia hanya pria yang sangat baik, tapi dia dibimbing, seperti orang kaya. Dan dia punya iPhone terbaru, dia mampu membelinya. Dia seorang multijutawan, dia menghabiskan banyak waktunya terbang antara Australia, tempat dia berasal, dan Estonia, tempat dia tinggal sekarang.

Harry: Dan dia terbang dengan kelas satu, tentu saja. Tapi itu berarti sebagian besar waktunya di iPhone 12 Pro Max yang bagus dan mengkilap, apa pun, apa pun, melalui WiFi pesawat, yang mengerikan. Dan itu adalah penjajaran yang sangat menakjubkan di mana dia memiliki situs dan dia sering menggunakannya, itu adalah situs yang dia gunakan. Dan dia mendorongnya… Maksudku dengan mudah pelanggan terkaya mereka adalah CEO mereka. Dan dia berada dalam posisi istimewa yang aneh ini di mana dia memiliki koneksi yang lebih buruk daripada Joe Public karena dia berada di suatu tempat di atas Singapura dalam penerbangan Quantas yang mendapatkan sampanye dituangkan ke lehernya, dan dia berjuang. Dan itu adalah wawasan yang sangat menarik bahwa… Oh ya, karena Anda memiliki persentil ke-95, pada dasarnya Anda dapat pergi ke kedua arah.

Drew: Ya, saat Anda mulai mengoptimalkan penggunaan situs dengan segelas sampanye di satu tangan, Anda berpikir "Mungkin kita mulai sedikit tersesat."

Harry: Ya, persis.

Drew: Kami berbicara sedikit tentang pengukuran kinerja, dan dalam pengalaman saya sendiri dengan pekerjaan kinerja, sangat penting untuk mengukur setiap A sehingga Anda dapat mengidentifikasi di mana masalahnya tetapi B sehingga ketika Anda benar-benar mulai menangani sesuatu, Anda dapat mengetahui apakah Anda membuat perbedaan dan seberapa besar perbedaan yang Anda buat. Bagaimana seharusnya kita mengukur kinerja situs kita? Alat apa yang bisa kita gunakan dan dari mana kita harus mulai?

Harry: Ya ampun, pertanyaan bagus lainnya. Jadi ada berbagai jawaban tergantung pada berapa banyak waktu, sumber daya, kecenderungan yang ada untuk memperbaiki kecepatan situs. Jadi apa yang akan saya coba dan lakukan dengan klien adalah… Metrik tertentu sangat bagus. Waktu muat, jangan pedulikan itu lagi. Ini sangat, sangat, sangat… Maksud saya, ini adalah proxy yang bagus jika waktu muat Anda 120 detik. Saya akan menebak Anda tidak memiliki situs web yang sangat cepat, tetapi terlalu tidak jelas dan tidak benar-benar berhadapan dengan pelanggan. Saya benar-benar berpikir vital adalah langkah yang sangat bagus ke arah yang benar karena mereka mengukur pengalaman pengguna tetapi mereka didasarkan pada masukan teknis. Cat Contentful Terbesar adalah hal yang sangat bagus untuk visual tetapi hal-hal teknis di sana membuka blokir jalur kritis Anda, pastikan gambar pahlawan tiba dengan cepat dan pastikan strategi font web Anda layak. Ada arus bawah teknis untuk metrik ini. Mereka benar-benar baik dari rak.

Harry: Namun, jika klien punya waktu, biasanya waktunya, karena Anda ingin mengambil data tetapi Anda perlu waktu untuk benar-benar menangkap data. Jadi apa yang saya coba dan lakukan dengan klien adalah mari kita pergi “Dengar, kita tidak bisa bekerja sama selama tiga bulan ke depan karena saya sudah penuh dipesan. Jadi, yang dapat kami lakukan adalah dengan sangat cepat menyiapkan Anda dengan uji coba Speedcurve gratis, menyiapkan beberapa metrik khusus” sehingga itu berarti bahwa untuk klien penerbit, surat kabar, saya akan mengukur “Seberapa cepat berita utama dari artikel yang diberikan? Seberapa cepat gambar utama untuk artikel tersebut ditampilkan?” Untuk klien E-Commerce yang ingin saya ukur, karena jelas Anda mengukur hal-hal seperti start render secara pasif. Segera setelah Anda mulai menggunakan perangkat lunak pemantauan kinerja, Anda menangkap metrik kinerja Anda yang sebenarnya secara gratis. Jadi Cat Contentful Pertama Anda, Contentful Terbesar, dll. Yang benar-benar ingin saya tangkap adalah hal-hal yang penting bagi mereka sebagai bisnis.

Harry: Jadi, bekerja dengan klien E-Com pada saat di mana kami dapat menghubungkan... Semakin cepat Anda memulai render, berapa probabilitas untuk menambahkan ke keranjang. Jika Anda dapat menunjukkan produk kepada mereka lebih cepat, kemungkinan besar mereka akan membelinya. Dan ini adalah banyak upaya untuk menyiapkan, ini adalah semacam tujuan peregangan untuk klien yang benar-benar berambisi, tetapi apa pun yang benar-benar ingin Anda ukur, karena seperti yang saya katakan, Anda tidak benar-benar ingin mengukur apa yang Terbesar Anda Contentful Paint adalah, Anda ingin mengukur pendapatan Anda dan apakah itu dipengaruhi oleh Large Contentful Paint? Jadi, tujuan utama, adalah apa pun yang Anda lihat sebagai KPI untuk bisnis itu. Bisa jadi, di surat kabar, seberapa jauh seseorang menggulir artikel ke bawah? Dan apakah itu berkorelasi dengan cara apa pun dengan penundaan input pertama? Apakah orang membaca lebih banyak artikel jika CLS lebih rendah? Tapi kemudian sebelum kita mulai melakukan custom, custom metrics, sejujurnya menurut saya web vitals adalah tempat yang sangat baik untuk memulai dan juga telah dinormalisasi dengan cukup baik. Itu menjadi ... Saya tidak tahu apa kata itu. Penyebut umum terendah saya kira, di mana semua orang di industri sekarang dapat mendiskusikan kinerja di lapangan permainan level ini.

Harry: Satu masalah yang saya punya, dan saya benar-benar perlu mengatur pertemuan dengan tim vitals, saya juga benar-benar berpikir Lighthouse itu hebat, tetapi CLS adalah 33% dari web vitals. Anda punya LCP, FID, CLS. CLS adalah 33% dari vital Anda. Vitals adalah apa yang biasanya ditampilkan di depan tim pemasaran Anda, departemen analitik Anda, karena muncul di konsol pencarian, disebutkan dalam konteks halaman hasil pencarian, sedangkan vital terkait, Anda mendapat bobot berat, 33%, sepertiga vitals adalah CLS, itu hanya 5% dari skor Lighthouse kami. Jadi yang akan Anda dapatkan adalah pengembang yang membangun di sekitar Lighthouse, karena dapat diintegrasikan ke dalam perkakas, ini adalah metrik lab. Vitals adalah data lapangan, itu rum.

Harry: Jadi, Anda mengalami keterputusan besar-besaran di mana Anda membuat tim pemasaran Anda mengatakan "CLS benar-benar buruk" dan pengembang berpikir "Yah, ini 5% dari skor Lighthouse yang diberikan DevTools kepada saya, ini 5% dari skor yang diberikan Lighthouse CLI kepada kami di CircleCI” atau apa pun yang Anda gunakan, namun bagi tim pemasaran, 33% dari apa yang mereka pedulikan. Jadi masalahnya ada sedikit pemutusan karena saya pikir Lighthouse sangat berharga, tapi saya tidak tahu bagaimana mereka mendamaikan perbedaan yang cukup besar di mana dalam vital, CLS adalah 33% dari skor Anda ... yah, bukan skor karena Anda tidak benar-benar memilikinya, dan Lighthouse hanya 5%, dan hal-hal seperti itu masih perlu diselesaikan sebelum kita dapat membuat diskusi ini mulus.

Harry: Tapi, sekali lagi, jawaban panjang untuk pertanyaan singkat. Vitals sangat bagus. LCP adalah metrik pengalaman pengguna yang baik yang dapat diringkas menjadi solusi teknis, sama dengan CLS. Jadi saya pikir itu titik lompatan yang sangat bagus. Di luar itu, ini adalah metrik khusus. Apa yang saya coba dan dapatkan dari klien saya adalah titik di mana mereka tidak terlalu peduli seberapa cepat situs mereka, mereka hanya peduli bahwa mereka menghasilkan lebih banyak uang dari kemarin, dan jika ya, apakah itu karena berjalan cepat? Jika dibuat lebih sedikit apakah itu karena berjalan lebih lambat? Saya tidak ingin mereka mengejar LCP dua detik yang mistis, saya ingin mereka mengejar LCP yang optimal. Dan jika itu ternyata lebih lambat dari yang Anda pikirkan, maka terserah, tidak apa-apa.

Drew: Jadi, untuk pengembang web yang hanya tertarik pada… mereka tidak memiliki anggaran untuk membeli alat seperti Speedcurve dan lainnya, mereka jelas dapat menjalankan alat seperti Lighthouse hanya di dalam browser mereka, untuk mendapatkan pengukuran yang baik… Apakah hal-hal seperti Google Analytics berguna untuk level itu?

Harry: Mereka dan mereka dapat dibuat lebih berguna. Analytics, selama bertahun-tahun sekarang, telah menangkap informasi kinerja yang belum sempurna. Dan itu akan menjadi waktu DNS, TCP dan TLS, waktu untuk byte pertama, waktu pengunduhan halaman, yang merupakan proxy… yah, terserahlah, hanya waktu unduh halaman dan waktu muat. Jadi metrik yang cukup kikuk. Tapi ini adalah titik awal yang baik dan biasanya setiap proyek yang saya mulai dengan klien, jika mereka tidak memiliki Relik Baru atau Speedcurve atau apa pun, saya hanya akan mengatakan "Baiklah, biarkan saya melihat analitik Anda" karena saya dapat melakukannya setidaknya proxy situasi dari sana. Dan itu tidak akan pernah sebagus sesuatu seperti Speedcurve atau New Relic atau Dynatrace atau apa pun. Anda dapat mengirim metrik khusus dengan sangat, sangat, sangat mudah ke analitik. Jika ada yang mendengarkan ingin dapat mengirim ... situs saya misalnya. Saya memiliki metrik seperti “Seberapa cepat Anda dapat membaca judul salah satu artikel saya? Pada titik mana gambar halaman Tentang dirender? Pada titik apa ajakan bertindak yang meminta Anda untuk mempekerjakan saya? Seberapa cepat itu ditampilkan ke layar? ” Sangat sepele untuk menangkap data ini dan hampir sama sepelenya untuk mengirimkannya ke analitik. Jadi, jika ada yang ingin melihat sumber di situs saya, gulir ke bawah ke tag body penutup dan temukan cuplikan analitik, Anda akan melihat betapa mudahnya bagi saya untuk menangkap data khusus dan mengirimkannya ke analitik. Dan, di UI analitik, Anda tidak perlu melakukan apa pun. Biasanya Anda harus menyiapkan laporan khusus dan menambang data dan membuatnya rapi. Ini adalah warga kelas satu di Google Analytics. Jadi saat Anda mulai menangkap analitik khusus, ada seluruh bagian dasbor yang didedikasikan untuk itu. Tidak ada pengaturan, tidak ada beban berat di GA itu sendiri, jadi itu benar-benar sepele dan, jika klien memiliki anggaran nyata atau mungkin saya ingin menunjukkan kepada mereka kekuatan pemantauan kustom, saya tidak ingin mengatakan “Oh ya, saya berjanji itu akan sangat bagus, bisakah saya memiliki 24 ribu untuk Speedcurve?” Saya bisa mulai dengan hanya mengatakan, “Lihat, ini belum sempurna. Mari kita lihat kemungkinannya di sini, sekarang kami mungkin dapat meyakinkan Anda untuk meningkatkan ke sesuatu seperti Speedcurve.”

Drew: Saya sering menemukan bahwa insting saya tentang seberapa cepat sesuatu seharusnya, atau apa dampak perubahan yang seharusnya, bisa salah. Saya akan membuat perubahan dan berpikir saya membuat segalanya lebih cepat dan kemudian saya mengukurnya dan sebenarnya saya telah membuat segalanya lebih lambat. Apakah itu hanya saya yang menjadi sampah di web perf?

Harry: Tidak sama sekali. Saya punya contoh yang benar-benar relevan tentang ini. Pramuat… intro yang sangat cepat bagi siapa saja yang belum pernah mendengar tentang pramuat, memuat aset tertentu di web secara inheren sangat lambat dan dua kandidat utama di sini adalah gambar latar belakang dalam CSS dan font web, karena sebelum Anda dapat mengunduh gambar latar belakang, Anda harus untuk mengunduh HTML, yang kemudian mengunduh CSS, dan kemudian CSS mengatakan "Oh, div ini di beranda membutuhkan gambar latar belakang ini." Jadi secara inheren sangat lambat karena Anda memiliki seluruh waktu CSS di antaranya. Dengan preload, Anda dapat menempatkan satu baris dalam HTML di tag kepala yang mengatakan "Hei, Anda belum mengetahuinya tetapi, percayalah, Anda akan membutuhkan gambar ini benar-benar, sangat, sangat segera." Jadi, Anda dapat menempatkan pramuat dalam HTML yang secara preemptif menjalankan unduhan ini. Pada saat CSS membutuhkan gambar latar belakang, itu seperti "Oh keren, kami sudah mendapatkannya, itu cepat." Dan ini digembar-gemborkan sebagai Mesias dengan kinerja web ini… Ini masalahnya, dan saya berjanji kepada Anda, saya menge-tweet minggu lalu dan saya telah terbukti benar dua kali sejak itu. Orang-orang mendengar tentang pramuat, dan janji yang diberikannya, dan juga sangat didorong oleh Lighthouse, secara teori, ini membuat situs Anda lebih cepat. Orang-orang begitu terikat dengan gagasan pramuat sehingga bahkan ketika saya dapat membuktikan bahwa itu tidak berhasil, mereka tidak akan menghapusnya lagi. Karena “Tidak, tapi Lighthouse berkata.” Sekarang ini adalah salah satu hal di mana teorinya masuk akal. Jika Anda harus menunggu font web Anda, dibandingkan mengunduhnya lebih awal, Anda akan melihat hal-hal lebih cepat. Masalahnya adalah, ketika Anda memikirkan bagaimana web sebenarnya bekerja, halaman mana pun yang pertama kali Anda buka, domain baru apa pun yang Anda klik, Anda memiliki jumlah bandwidth yang terbatas dan browser sangat pintar menghabiskan bandwidth itu dengan benar. Ini akan melihat HTML Anda dengan sangat cepat dan membuat daftar belanja. Yang paling penting adalah CSS, lalu jQuery ini, lalu ini… dan kemudian beberapa hal berikutnya adalah ini, ini, dan ini yang kurang diprioritaskan. Segera setelah Anda mulai memuat HTML Anda dengan pramuat, Anda memberi tahu browser “Tidak, tidak, tidak, ini bukan daftar belanja Anda lagi, sobat, ini milik saya. Anda harus pergi dan mendapatkan ini.” Jumlah bandwidth yang terbatas itu masih terbatas tetapi tidak dihabiskan di lebih banyak aset, jadi semuanya menjadi sedikit lebih lambat. Dan saya harus mencemooh ini dua kali dalam seminggu terakhir, dan tetap saja orang-orang seperti "Ya tapi tidak, itu karena mengunduh lebih cepat." Tidak, ini diminta lebih cepat, tetapi mencuri bandwidth dari CSS Anda. Anda benar-benar dapat melihat font web Anda mencuri bandwidth dari CSS Anda. Jadi itu salah satu hal di mana Anda harus, harus, harus mengikuti angka. Saya telah melakukannya sebelumnya pada klien skala besar. Jika Anda mendengarkan ini, Anda pernah mendengar tentang klien ini, dan saya cukup bersikeras bahwa “Tidak, tidak, tag kepala Anda berada dalam urutan yang salah karena begitulah seharusnya dan Anda harus memilikinya di sini. memesan karena secara teoritis itu mengisyaratkan hal itu…” Bahkan dalam apa yang saya lakukan kepada klien, saya tahu bahwa saya membuat diri saya bodoh. Karena cara kerja browser, itu harus lebih cepat. Jadi saya membuat taktik, perubahan ini... ke jutaan orang, dan itu menjadi lebih lambat. Itu menjadi lebih lambat. Dan saya duduk di sana, dengan marah bersikeras "Tidak, tetapi, browser bekerja seperti ini" tidak berguna karena tidak berfungsi. Dan kami mengembalikannya dan saya seperti “Maaf! Masih akan menagih Anda untuk itu! ” Jadi itu sama sekali bukan kamu.

Drew: Ikuti angka-angka ini.

Harry: Ya, persis. “Saya sebenarnya harus menagih Anda lebih banyak, karena saya menghabiskan waktu untuk mengembalikannya, butuh waktu lebih lama.” Tapi ya, Anda benar sekali, itu bukan Anda, itu salah satu hal di mana... Saya telah melakukannya beberapa kali dalam skala yang jauh lebih kecil, di mana saya akan seperti "Yah ini secara teoritis harus bekerja" dan tidak 'T. Anda hanya harus mengikuti apa yang terjadi di dunia nyata. Itulah mengapa pemantauan itu sangat penting.

Drew: Saat lanskap berubah dan teknologi berkembang, Google meluncurkan teknologi baru yang membantu kami membuat segalanya lebih cepat, apakah ada cara yang baik agar kami dapat mengikuti perubahan? Apakah ada sumber daya yang harus kita perhatikan untuk menjaga agar keterampilan kita tetap mutakhir dalam hal kinerja web?

Harry: Untuk dengan cepat mengatasi seluruh "pembuatan Google"... Saya tahu ini sedikit tidak masuk akal, tetapi saya akan fokus pada hal ini. Saya kira tepat di awal, bertaruh pada browser. Hal-hal seperti AMP, misalnya, merupakan solusi terbaik setelah dipikirkan. Tidak ada pengganti untuk membangun situs yang cepat, dan saat Anda mulai menggunakan hal-hal seperti AMP, Anda harus berpegang pada standar non-standar tersebut, belas kasihan tim AMP berubah pikiran. Saya memiliki klien yang menghabiskan banyak uang untuk melisensikan font dari penyedia font AMP yang diizinkan, kemudian pada titik tertentu, AMP memutuskan "Oh sebenarnya tidak, font itu disediakan, kami akan memblokir daftarnya sekarang" Jadi saya punya klien yang berinvestasi besar-besaran di AMP dan penyedia font ini dan harus memilih “Nah, apakah kita membatalkan semua pekerjaan AMP atau kita hanya menyia-nyiakan jumlah yang sangat besar ini dalam setahun di font web” bla, bla, bla. Jadi saya akan sangat berhati-hati terhadap siapa pun… Saya adalah pakar Pengembang Google tetapi saya tidak tahu ada perintah tersedak… Saya bisa kritis, dan saya akan mengatakan… hindari hal-hal yang dipuji sebagai satu ukuran -cocok untuk semua solusi, hal-hal seperti AMP.

Harry: Dan untuk membuang orang lain sebentar, Cloudflare memiliki sesuatu yang disebut Rocket Loader, yang merupakan AMP-esque dalam usahanya. Ini dirancang seperti "Oh, nyalakan saja CDN Anda, itu akan membuat situs Anda lebih cepat." Dan sebenarnya itu hanya pengganti untuk membangun situs Anda dengan benar sejak awal. Jadi… untuk mengatasi aspek itu, cobalah dan tetap seindependen mungkin, ketahui cara kerja browser, yang langsung berarti bahwa monokultur Chrome, Anda kembali ke pangkuan Google, tetapi ketahui cara kerja browser, tetap berpegang pada beberapa ideologi fundamental. Saat Anda membuat situs, lihat halaman. Baik itu di Figma, atau Sketch, atau di mana pun itu, lihat desainnya dan katakan “Nah, itulah yang ingin dilihat pengguna terlebih dahulu, jadi saya tidak akan menghalanginya. Saya tidak akan malas memuat gambar utama ini karena itu gila, mengapa saya melakukan itu? Jadi pikirkan saja "Apa yang Anda inginkan agar pengguna menjadi yang pertama?" Di situs E-Com, itu akan menjadi gambar produk itu, mungkin nav pada saat yang sama, tetapi ulasan produk, Q dan A produk, malas memuat itu. Selipkan itu di belakang JavaScript.

Harry: Cara kerja mendasar tertentu yang akan melayani Anda dengan benar, apa pun teknologi yang Anda baca, yaitu "Prioritaskan apa yang diprioritaskan pelanggan Anda". Melakukan lebih banyak pekerjaan akan lebih cepat, jadi jangan menghalangi hal itu, tetapi kemudian hal-hal yang lebih taktis untuk diperhatikan orang, ikuti terus… dan sekali lagi, langsung kembali ke Google, tetapi web.dev terbukti menjadi sumber yang fenomenal untuk kerangka kerja agnostik, tumpukan wawasan agnostik… Jadi jika Anda ingin belajar tentang vitals, Anda ingin belajar tentang PWA, jadi web.dev benar-benar hebat.

Harry: Sebenarnya hanya ada sedikit publikasi yang berpusat pada kinerja. Email Calibre adalah, saya pikir email perf dua minggunya sangat fenomenal, itu intisari yang sangat bagus. Awasi platform web secara umum, jadi ada Performance Working Group, mereka punya banyak hal tentang proposal GitHub. Sekali lagi, kembali ke Google, tetapi tidak ada yang tahu tentang situs web ini dan fenomenalnya: chromestatus.com. Ini memberi tahu Anda dengan tepat apa yang sedang dikerjakan Chrome, apa sinyalnya dari browser lain, jadi jika Anda ingin melihat apa pekerjaannya di petunjuk prioritas, Anda bisa pergi dan mendapatkan tautan ke semua pelacak bug yang relevan. Status Chrome menunjukkan tonggak pencapaian untuk setiap… “Ini keluar di MAT8, ini dirilis di '67” atau apa pun, itu hal yang sangat bagus untuk wawasan teknis yang cukup.

Harry: Tapi saya terus kembali ke hal ini, dan saya tahu saya mungkin terdengar seperti "Orang tua berteriak di Cloud" tetapi tetap berpegang pada dasar-dasarnya, hampir setiap pound atau dolar, euro, yang pernah saya dapatkan, telah mengajar klien bahwa "Anda tahu browser sudah melakukan ini, kan" atau "Anda tahu bahwa ini tidak mungkin lebih cepat" dan kedengarannya sangat tepat bagi saya... Saya tidak pernah membuat satu sen pun dari penjualan teknologi ekstra. Setiap sedikit uang yang saya hasilkan adalah tentang menghapus, mengurangi. Jika Anda menemukan diri Anda menambahkan sesuatu untuk membuat situs Anda lebih cepat, Anda berada di arah yang salah.

Harry: Contoh kasus, saya tidak akan menyebutkan... perusahaan periklanan/mesin telusur/browser besar sama sekali, tidak akan menyebutkan nama mereka, dan saya tidak akan menyebutkan kerangka kerja JavaScript, tapi saat ini saya masuk diskusi dengan kerangka kerja JavaScript yang sangat, sangat besar, dan sangat populer tentang menghapus sesuatu yang secara aktif merugikan, atau secara opsional menghapus sesuatu yang akan membahayakan kinerja sejumlah besar situs web. Dan mereka seperti "Oh, kita akan masuk ..." seseorang dari perusahaan besar ini, karena mereka melakukan penelitian... dan itu seperti "Kami membutuhkan opsi untuk menghapus hal ini karena Anda dapat melihat di sini, dan di sini, dan di sini itu membuat situs ini lebih lambat.” Dan solusi mereka adalah menambahkan lebih banyak, seperti "Oh, tetapi jika Anda melakukan ini juga, maka Anda dapat menghindarinya" dan itu seperti "Tidak, tidak, menambahkan lebih banyak untuk membuat situs lebih cepat pasti merupakan solusi yang salah. Tentunya Anda dapat melihat bahwa Anda menuju ke arah yang salah jika dibutuhkan lebih banyak kode untuk mendapatkan situs yang lebih cepat.”

Harry: Karena cepat untuk memulai, dan semua yang Anda tambahkan adalah yang membuatnya lebih lambat. Dan ide untuk menambahkan lebih banyak untuk membuatnya lebih cepat, meskipun… mungkin terwujud dalam situs web yang lebih cepat, itu adalah cara yang salah. Ini adalah perlombaan ke bawah. Maaf, saya benar-benar marah, Anda bisa tahu saya sudah lama tidak mengoceh. Jadi itu hal lain, jika Anda menemukan diri Anda menambahkan fitur untuk membuat situs lebih cepat, Anda mungkin menuju ke arah yang salah, itu jauh lebih efektif untuk membuat lebih cepat dengan menghapus sesuatu daripada menambahkannya.

Drew: Anda telah menyusun kursus video berjudul "Semua yang Telah Saya Lakukan untuk Membuat Sihir CSS Cepat".

Harry: Ya!

Drew: Ini sedikit berbeda dari kursus video online tradisional, bukan?

Harry: Itu. Saya akan jujur, itu sebagian… Saya tidak ingin mengatakan kemalasan di pihak saya, tetapi saya tidak ingin merancang kurikulum yang harus sangat kaku dan membawa Anda dari nol menjadi pahlawan karena waktu yang terlibat dalam melakukan itu sangat besar dan waktu yang saya tidak tahu apakah saya akan melakukannya. Jadi yang saya inginkan adalah memiliki materi yang siap digunakan, cukup screencast diri saya berbicara melaluinya sehingga tidak dimulai dengan "Ini adalah browser dan inilah cara kerjanya" jadi Anda setidaknya harus menyadari dasar-dasar kinerja web, tetapi ini adalah peretasan dan tip pro dan contoh kehidupan nyata.

Harry: Dan karena saya tidak perlu melakukan kurikulum penuh, saya bisa menurunkan harga. Jadi itu bukan kursus 10 jam besar yang akan membawa Anda dari nol menjadi pahlawan, itu masuk dan keluar sesuai keinginan Anda. Ini pada dasarnya hanya melihat situs saya yang merupakan taman bermain yang sangat baik untuk hal-hal yang tidak stabil atau… risikonya sangat rendah bagi saya untuk bereksperimen di sana. Jadi saya baru saja melakukan serial video. Itu sangat menyenangkan untuk direkam. Hanya merobohkan situs saya sendiri dan berbicara tentang "Nah ini cara kerjanya dan inilah cara Anda bisa menggunakannya".

Drew: Saya pikir itu benar-benar hebat bagaimana itu dibagi menjadi memecahkan masalah yang berbeda. Jika saya ingin mengetahui lebih lanjut tentang mengoptimalkan gambar atau apa pun, saya dapat berpikir "Benar, apa yang pasangan saya Harry katakan tentang ini?", Masuk ke video tentang gambar dan pergilah. Ini benar-benar dapat diakses dengan cara itu, Anda tidak perlu duduk berjam-jam, Anda bisa pergi ke bagian yang Anda inginkan dan mempelajari apa yang perlu Anda pelajari dan kemudian keluar.

Harry: Saya rasa saya mencoba untuk membuatnya lebih… Manfaat dari tidak menerapkan kurikulum yang kaku adalah Anda tidak perlu menonton video tertentu terlebih dahulu, tidak ada intro, hanya “Pergi dan lihat-lihat dan lihat apa yang menurut Anda menarik” yang berarti bahwa seseorang yang menderita masalah LTP mereka seperti "Oh, baiklah, saya harus masuk ke folder ini di sini" atau jika mereka menderita masalah CSS, mereka dapat masuk ke folder itu. Jelas saya tidak memiliki statistik, tetapi saya membayangkan ada tingkat pengabaian yang tinggi pada kursus, murni karena Anda harus berjalan dengan susah payah melalui tiga jam intro jika Anda melewatkan sesuatu, dan itu seperti "Oh, tahukah Anda, saya tidak bisa terus lakukan ini setiap hari” dan orang mungkin mengabaikan banyak kursus. Jadi pemikiran saya baru saja menyelam, Anda tidak perlu melihat tiga jam sebelumnya, Anda bisa pergi dan menemukan apa pun yang Anda inginkan. Dan umpan baliknya benar-benar… Sebenarnya, yang akan saya lakukan adalah, itu belum ada, tetapi saya akan melakukannya langsung setelah panggilan, siapa pun yang menggunakan kode diskon SMASHING15, mereka akan mendapatkan diskon 15% itu.

Drew: Jadi hampir seperti Anda telah mengoptimalkan kinerja kursus itu sendiri, karena Anda bisa langsung ke bagian yang Anda inginkan dan Anda tidak perlu melakukan semua negosiasi dan-

Harry: Ya, tidak disengaja, tetapi saya akan menerima pujian untuk itu.

Drew: Jadi, saya telah mempelajari semua tentang kinerja web, apa yang telah Anda pelajari akhir-akhir ini, Harry?

Harry: Hal-hal teknis ... tidak juga. Saya punya banyak hal dalam daftar "untuk dipelajari", jadi QUIC, H3 semacam hal yang saya ingin dapatkan sedikit lebih banyak pengetahuan tentang itu, tapi saya menulis E-Book selama penguncian pertama di Inggris jadi saya belajar cara membuat E-Books yang sangat menyenangkan karena hanya HTML dan CSS dan saya tahu caranya jadi itu sangat menyenangkan. Saya belajar pengeditan video yang sangat sederhana untuk kursus ini, dan apa yang saya sukai dari itu bukanlah pekerjaan konseptual. Jelas, belajar bahasa pemrograman, Anda harus bergulat dengan konsep, sedangkan mempelajari E-Book hanyalah alur kerja dan… hal-hal yang belum pernah saya utak-atik sebelumnya sehingga menarik untuk dipelajari tetapi tidak memerlukan perubahan karir , jadi itu cukup bagus.

Harry: Dan kemudian, hal-hal non teknis… Saya mengendarai banyak sepeda, saya jatuh dari banyak sepeda… dan karena saya tidak bepergian sama sekali sejak Maret lalu, hampir satu tahun sekarang, saya telah melakukan lebih banyak lagi bersepeda dan lebih fokus pada… meningkatkannya. Jadi saya telah melakukan banyak penelitian seputar output daya dan kekuatan ambang batas fungsional, saya sedang melakukan program pelatihan saat ini, begitu terus-menerus, kaki terus-menerus lelah tetapi saya belajar banyak tentang fisiologi seputar bersepeda. Saya tidak tahu mengapa karena saya tidak punya rencana untuk melakukan apa pun dengannya selain terus berkendara. Ini benar-benar menarik. Saya merasa sangat beruntung selama penguncian, jamak, tetapi saya berhasil tetap aktif. Banyak orang akan kehilangan hal-hal sederhana seperti perjalanan sehari-hari ke kantor, kesempatan bagus untuk meregangkan kaki. Di Inggris, seperti yang Anda ketahui, bersepeda telah sangat diperjuangkan, jadi saya telah bermain-main lebih banyak dengan belajar lebih banyak tentang mengendarai sepeda dari aspek yang lebih fisiologis yang berarti ... tidak tahu, hanya menjadi seorang nerd tentang sesuatu yang lain untuk perubahan.

Drew: Apakah mungkin tidak ada banyak perbedaan antara pengoptimalan kinerja di web dan pengoptimalan kinerja dalam bersepeda, itu semua keuntungan kecil, bukan?

Harry: Ya, persis. Dan jumlah grafik yang telah saya lihat pada sepeda… Saya mendapatkan data daya dari sepeda, saya akan berkendara dan kembali seperti “Oh, jika saya memiliki lima watt lagi di sini, tetapi kemudian menghemat 10 watt di sana, saya bisa melakukan ini, ini, dan ini tercepat yang pernah ada” dan… menjadi anorak besar-besaran tentang hal itu. Tapi ya, kamu benar. Tahukah Anda, saya pikir Anda telah menemukan sesuatu yang sangat menarik di sana. Saya pikir hal semacam itu adalah olahraga/kesenangan yang bagus untuk seseorang yang sedikit obsesif, yang suka mengejar angka. Ada beberapa hal, maksudku kau akan tahu ini tapi, Strava, kau punya KOMmu. Saya mengantongi 19 dari mereka tahun lalu yang, bagi saya, jumlah yang fenomenal. Dan itu hampir semua dari terobsesi dengan data yang tersedia dan melihat "Orang ini yang saya coba kalahkan, dia melakukan 700 watt pada saat ini, jika saya bisa mendapatkan hingga 1000 dan kemudian berhenti" dan bla, bla, bla ... itu menjadi obsesif. kutu buku. Tapi Anda benar, saya kira itu hal yang serupa, bukan? If you could learn where you afford to tweak things from or squeeze last little drops out…

Drew: And you've still got limited bandwidth in both cases. You've got limited energy and you've got limited network connection.

Harry: Exactly, you can't just magic some more bandwidth there.

Drew: If you, the listener, would like to hear more from Harry, you can find him on Twitter, where he's @csswizardty, or go to his website at csswizardry.com where you'll find some fascinating case studies of his work and find out how to hire him to help solve your performance problems. Harry's E-Book, that he mentioned, and video course we'll link up from the show notes. Thanks for joining us today, Harry, do you have any parting words?

Harry: I'm not one for soundbites and motivation quotes but I heard something really, really, really insightful recently. Everyone keeps saying “Oh well we're all in the same boat” and we're not. We're all in the same storm and some people have got better boats than others. Some people are in little dinghies, some people have got mega yachts. Oh, is that a bit dreary to end on… don't worry about Corona, you'll be dead soon anyway!

Drew: Keep hold of your oars and you'll be all right.

Harry: Ya. I was on a call last night with some web colleagues and we were talking about this and missing each other a lot. The web is, by default, remote, that's the whole point of the web. But… missing a lot of human connection so, chatting to you for this hour and a bit now has been wonderful, it's been really nice. I don't know what my parting words really are meant to be, I should have prepared something, but I just hope everyone's well, hope everyone's making what they can out of lockdown and people are keeping busy.