Ngobrolin Core Web Vitals
Ringkasan Episode
Bantu KoreksiCore Web Vitals dibahas mulai dari alasan kemunculannya. Sebelum ada patokan bersama, orang mengukur kecepatan dengan YSlow, PageSpeed, dan GTmetrix yang berlomba memberi skor huruf, dan semuanya cenderung berbicara soal angka teknis. Pemicunya adalah kenyataan bahwa halaman web makin berat sejak era framework JavaScript modern — bundle-nya saja bisa menembus 4 MB sebelum menghitung gambar — sementara kecepatan internet dan kemampuan ponsel Android awal 3,5G tidak melaju secepat itu. Google akhirnya merumuskan Web Vitals lewat Lighthouse dan Performance API supaya ada standar bersama. Yang membedakannya adalah sudut pandang. Alih-alih mengukur seberapa cepat server menjawab atau seberapa cepat berkas terunduh, Core Web Vitals berangkat dari apa yang benar-benar dirasakan pengunjung. Contoh yang dipakai: kotak pencarian yang langsung menampilkan huruf yang kita ketik terasa jauh lebih responsif daripada yang menahannya dulu, meski hasil pencariannya sama-sama datang dalam waktu yang sama. Karena itu pula TTFB (Time to First Byte) tetap diukur tapi tidak masuk ke dalam tiga metrik inti — ia penting dan memengaruhi LCP maupun yang lain, tapi tidak langsung terlihat oleh pengunjung. Tiga metriknya dibedah satu per satu: LCP dan kenapa nilainya bisa memburuk tanpa disadari karena elemen terbesarnya bisa berpindah — kalau gambar utama dibiarkan lazy load, mula-mula judulnya yang terhitung lalu berganti ke gambar begitu selesai dimuat. Lalu CLS, yang disebut paling sulit diperbaiki karena skornya rata-rata seluruh halaman dan sumber terparahnya adalah iklan dan embed TikTok atau Twitter yang tingginya tak bisa ditebak; obatnya aspect-ratio CSS, font fallback yang dimensinya dicocokkan, dan untuk embed hanya bisa diakali lewat field data seperti yang ditulis BuzzFeed. Terakhir FID yang akan digantikan INP mulai tahun depan. Ditutup dengan penelusuran langsung lewat Performance Insights di Chrome DevTools dan PageSpeed Insights, plus catatan bahwa data lapangan di Search Console berasal dari CrUX dan baru terlihat setelah 28 hari.
Poin-poin Utama
- •Core Web Vitals lahir sebagai inisiatif Google karena halaman web makin berat sejak era framework JavaScript modern, sementara kecepatan internet dan kemampuan ponsel tidak melaju secepat itu
- •Sebelumnya orang mengukur dengan YSlow, PageSpeed, dan GTmetrix yang berlomba memberi skor huruf; Lighthouse hanyalah pelapor, data sebenarnya datang dari Performance API
- •TTFB tetap diukur tapi tidak masuk tiga metrik inti — ia memengaruhi LCP dan semuanya, tapi tidak langsung terlihat oleh pengunjung
- •Elemen LCP bisa berpindah: kalau gambar utama dibiarkan lazy load, mula-mula judulnya yang terhitung lalu berganti ke gambar, dan skornya ikut melar di atas 3 detik
- •CLS disebut paling sulit diperbaiki karena skornya rata-rata seluruh halaman; aspect-ratio CSS menolong untuk gambar dan video, tapi embed TikTok atau Twitter hanya bisa diakali lewat field data seperti yang ditulis BuzzFeed
- •FID hanya mengukur interaksi pertama dan akan digantikan INP, yang mengukur semua klik, tap, dan keypress — diumumkan di Google I/O 2023 agar developer punya waktu bersiap
- •Semuanya bisa ditelusuri lewat Performance Insights di Chrome DevTools atau PageSpeed Insights, sementara field data di Search Console berasal dari CrUX dan baru terlihat setelah 28 hari
- Belum. - Belum.
Yeh, itu udah muncut.
- Halo. - Halo semua.
Selamat malam.
Selamat Hari Selasa.
Selamat Hari Selasa. Seperti biasa, Hari Selasa ketemu lagi sama kita bertiga di acara...
Nge-blogging web.
Kita bertiga itu trio web-web.
Trio web-web.
Trio web-web.
Kalau kids jaman now, mungkin nggak rilis ya. Dua jaman dulu ada trio kuek-kuek ya.
Jebakan umur.
Jebakan umur ya.
Oke, malam hari ini ketemu lagi ya.
Seperti biasa, setiap Selasa malam kita ngobrolin tentang teknologi web.
Dan malam hari ini, topiknya sangat menarik.
Karena berhubungan kembali dengan performance.
Kita udah lama nggak ngomongin performance.
Jadi performance itu kan, gimana caranya meningkatkan performance dari sebuah aplikasi atau halaman web itu...
Satu cara yang harus kita lakukan pertama adalah mengukur.
Kalau nggak diukur, kita nggak tahu kan.
Kalau nggak diukur, apa? Di laptop saya cepet kok.
Nah, words kan ada istilah "words on my machine".
Ini juga mungkin ada istilah "it's fast on my machine".
Yes.
Cepat itu juga relatif kan?
- Cepat dikira lebih cepat buat orang. - Menurut saya, cepat di mesin saya.
Iya.
Bahkan di mesin saya itu sangat subjektif.
Iya.
Lihat transkrip lengkap (1256 segmen lagi)
Terus masih ada bahasanya "perceive speed".
Nah, "perceive speed".
Perceive speed itu apa?
Jadi cepat itu yang...
Cepat yang dirasakan sebenarnya nggak cepat.
- Perasaan aja ya? Perasaan cepat gitu ya? - Perasaannya aja. Perceive speed.
Itu juga sering...
- Tapi itu biasa. - Rasa solo. Atau solo tambat?
Contohnya, kalau kita ada input sesuatu ya.
Input sesuatu. Misalnya...
Apa ya? Tahu nggak sih kalau search bar yang bisa ada autocompletenya?
Ya.
Kalau misalnya kita typing something, terus kita typing aja, terus...
Karakter kita munculnya lama, itu orang aja udah merasa "wah lambat banget nih website".
- "Nge-lag nih website" gitu ya. - Nge-lag, iya.
- Meskipun... - Padahal...
- Iya, lanjut. - Meskipun...
Hasilnya mungkin sama aja gitu ya.
Kalau dibandingkan dengan...
Kalau kita typing, ternyata tulisannya muncul duluan, ada loadingnya, terus baru muncul.
Meskipun si hasil search result-nya untuk querinya ya...
Sama aja jatuhnya.
1 detik, 2 detik butuh waktunya, tetapi...
- Variable-nya banyak sekali ya. - Iya.
Tetapi waktu si user yang menggunakannya...
Sudah merasa, oh, ada feedback, ada response nih kalau gue typing something.
Ada response dari aplikasinya.
Nah, jadi beneran merahnya mengurangi subjektivitas...
Biar nggak tentu saya cepat atau di mesin saya cepat, dan kedua kan...
Itu tadi perkara apa yang diukur kan.
- Iya, apa? - Kalau apa yang diukur...
Buat mengekspresikan atau menggambarkan kecepatan.
Nah, itu tuh nanti semua bakal kita bahas di topik lower web finals ini.
Topik malam ini.
Nah, teman-teman yang di chat, yang di kolom chat...
Mungkin bisa share juga pakai tools apa nih buat mengukur dan...
Bikin performa web kita jadi lebih cepat, mengetahui apakah...
Misalkan setelah update, nambah fitur, apakah web kita performanya sama lebih cepat atau lebih lambat.
Mungkin bisa di-share juga.
Dan kalau malam hari ini kita akan bahas tentang satu tools yang lagi apa ya...
Yang lagi digadah-gadangkan salah satunya oleh Google...
Di beberapa tahun terakhir, yang namanya adalah core web finals.
Nah, ini dia.
Apa sih core web finals itu?
Kayaknya pertama kali launching kapan ya? 2020 ya apa ya?
- Saya ingat 2019. - Kayaknya masih 2019.
Mas Yohan yang present.
Maksudnya kenapa sih ada web finals- web finals segara gitu ya?
Iya.
Ini tujuannya apa?
Web finals ini adalah inisiatif dari Google memang.
Dan tujuannya adalah untuk menyediakan guidance itu adalah apa ya?
- Stunt. - Panduan.
- Panduan lah. - Panduan, umum.
Panduan atau panduan, gimana biar UX-nya bagus.
Jadi ini menarik sih karena term yang perspektif menipak itu dari usernya jadi bukan detail.
Jadi sebetulnya kan implementation detail-nya bisa server-nya segera cepat di-demand response.
Atau browser thread-nya segera cepat render suatu download.
Misalnya itu kan hal yang teknis.
Tapi di sini justru core web finals-nya sendiri,
Deskripsi utamanya, definisi utamanya itu yang penting deliver user experience.
Yang baik user merasa mendapatkan pengalamannya yang baik dengan metric-metric ini.
Jadi user experience ini nggak ada hubungan, bukan nggak ada hubungannya.
Kalau UX itu biasanya kan temannya itu UI, sebenarnya nggak gitu kan.
UX itu adalah pengalaman pengguna.
Cepat, snappy, nggak nge-lag, itu adalah salah satu pengalaman pengguna yang bagus.
Nah, tapi pertanyaannya kenapa kita butuh core web finals-nya ini?
Sebelum kita harus nilai sedikit satu langkah ke belakang.
Kenapa sampai si Google ini capek-capek initiate ini gitu.
Nah, ini pertanyaan saya juga nih.
Sebelum web finals kita mengukur core format web kita tuh dengan apa?
Kalau jaman saya dulu tuh, yang paling senang itu ada YSlow.
- Dari Yahoo. - Apa? PageSpeed bukan?
Nah, YSlow.
- PageSpeed itu punya Google. - Punya Google tapi masih belum pakai core web finals.
Tapi ada juga dulu, PageSpeed ada memang.
Terus ada GTmetrics.
Semua berlomba-lomba pakai skor A, skor A gitu.
Nah, namun sebelumnya kalau kita tilik sejarahnya ya,
ini berasal dari modern JavaScript framework si awalnya kalau menurut saya.
- Pemicu-nya ya? - Pemicu-nya.
Jadi makin ke belakang,
jadi semenjak munculnya modern-modern JavaScript framework,
itu berlomba-lomba semuanya serba JavaScript.
Sampai nge-generate DOM aja pakai JavaScript.
- SBA gitu ya? - Iya, pakai SBA juga.
Jadi untuk download file bundle-nya aja sudah sampai...
- Berapa mega? - Saya pernah sampai 4 mega sendiri hanya bundle-nya aja.
- Jaman itu ya. - Itu belum image sih.
- Belum ada menimpa ya? - Iya, image aja juga jaman dulu itu gede-gede kan.
Ingat gak jamannya ada slider yang revolution slider yang dia bisa kudu-kudu terus bisa...
Terus ingat gak jamannya Apple itu punya situs yang dia kalau di-scroll bisa paralaks-paralaks gitu.
Semakin animasi, semakin besar, semakin bervariasi JavaScript, semakin banyak tools dan library-nya.
Mengakibatkan wake dari setiap situs website itu, wake-nya meningkat tajam.
- Jadi makin lama loading-nya. - Makin lama, user itu makin merasa berat memakai website-nya.
Apalagi jaman itu penggunaan mobile phone semakin tinggi.
Kita tilik kembali sebelum 2019 ya, berarti sekitar 2015, 2016 itu jamannya mulai handphone-handphone Android mulai naik kan.
- Handphone Android kemudian iOS. - Mulai bisa buka website dari Apple. - Dan jaman itu masih 4G kayaknya ya, 4G awal-awal.
- Bahkan 3.5G. - Iya, 3.5G gitu ya, jaman itu ya.
Jadi si teknologi internet speed dan teknologi browser gak seimbang dengan kemajuan teknologi JavaScript.
Jadi mau browser mau secepat apa? Gimana lagi supaya kita gak performance battle nih?
Gak perlu, jadi mau cepet-cepetan gak bisa kalau dari sisi developer-nya gak di balasanya ditatar.
Hey, ayo jangan bundle semuanya, perlunya cuma underscore debounce tapi seluruh sabruk-sabruk loadas dipakai misalnya.
Jadi makanya muncul Web Vitals ini, jadi untuk menstandarisasi.
Sebelum web vitals ya, performance matrix mungkin. - Lebih tepatnya saat mereka nge-launching Lighthouse.
- Lighthouse ya, awalnya Lighthouse. - Lighthouse, dan jaman itu kan mau si Google nge-push untuk PWA ya.
Cuma salah satu syarat PWA itu kan harus cepet.
Dulu tuh sudah ada Lighthouse sama speed matrix ya, jadi dulu yang sampai sekarang juga masih ada.
Cuma dulu belum di-codify sebagai Core Web Vitals matrixnya.
- Betul, nah setelah ada inisiatif ini, karena melihat data ya, data itu semakin lama situs-situs yang top 20 itu makin lama makin berat.
Akhirnya harus di-tone down, harus bagaimana mengajarkan developer untuk hemat.
- Nanti ada itu lagi kan, budget, tapi itu nanti bisa buat topik yang lain.
Tapi intinya adalah hemat, kita harus menghemat bandwidth, user.
- Ya betul, jadi muncul ide untuk kita menstandarisasi vital-vital apa saja yang perlu diukur.
Makanya ada performance API, munculnya performance API itu juga sejalan kan.
Terus dari vital-vital tersebut, ada banyak sebenarnya vital, jadi Core Web Vitals itu adalah cornyah.
Web Vitals itu ada banyak, ada TTFB, Time to First Buy.
- Itu salah satu pertama tuh, ingat banget.
Pas belom ada Web Vitals, yang merupakan Speed Insight sama Lighthouse kan, itu Time to First Buy.
- Terus ada First Content Full Payne, ini TTFB dulu.
- Ya, TTFB, Time to First Buy.
- Waktu sampai, buy pertama.
Coba Mas Rizal refresh, saya pengen tahu browser-nya supportnya ini, ada enggak?
Oke, coba sekali lagi, sekali lagi, sorry, sekali lagi.
- Mau lihat apa?
- Tunggu, oh nggak kelihatan.
Jaman dulu kalau kita refresh browser, dia loading ikonnya, kalau dia spinner-nya ke kiri itu berarti dia menuju server.
Kalau dia sudah ada response spinner-nya ke kanan, bukalah sesuatu yang berat.
Coba sesuatu yang belum, mungkin yahoo.com mungkin.
- Apple?
- Ya boleh lah, enggak tahu.
Oh udah langsung response, mungkin yahoo.com.
- Oh iya, ini kiri, sekarang counter clockwise, sekarang ini clockwise.
To the island.
- Jangan lupa, saya GDI di bidang performance kan.
Jadi Time to First Buy, kembali ke Time to First Buy.
Saat loading screen-nya ke kiri, itu kita dari sisi browser, nge-request ke server, lagi mendengar, menunggu response.
Dan saat dia sudah response, saat buy pertama nyampe itu adalah DTFB, buy pertama diterima.
- Clockwise tadi?
- Kalo dia berganti arah, pertama kali dia ganti arah.
Untuk lebih jelasnya bisa dilihat dari DevTool, coba masuk DevTool.
Itu di network, eh network, apa ya gue lupa.
Bukan, ini di timing API, kayaknya di timing itu dimana yah?
- Performance bukan?
- Bukan, sorry, di network, betul di network.
Terus ininya tab-nya di dock, D-O-C.
D-O-C, di tab masnya, kiri, kiri, kiri, terus ke kiri, ke kanan sorry, ke kanan.
Yang itu loh, filter-nya itu kan image, filter-nya image.
Nah dock, coba refresh, coba refresh.
Oke, klik yang DTFB-nya.
Itu ada timing, tab timing, oke.
Nah itu bisa dilihat, duration untuk resource-nya saat dia initial connection.
Ini ada connection-nya mulai, jadi begitu mas Riza click reload.
Cue-nya untuk si browser nge-cue, action itu 1,65 second.
Ke stall sebelum dia bisa mulai, 1,21.
Initial connection-nya dia buka, DNS lookup-nya 21 microsecond.
Itu berarti sudah ke cache, sudah ke cache yah.
Dan ada initial connection, SSL handshake, ya itu handshake.
Kadang kalau kayak situs bank, handshake-nya aja 100 millisecond.
- Karena dia pakai firewall khususnya.
- Multi-layer.
Terus request-sen, dia request-sen-nya 87 microsecond, waiting for server response 38 millisecond.
Jadi si situs ini cepet banget terhitungnya, karena dia cuma butuh 38 millisecond.
Jadi total-totalnya adalah 80 millisecond.
Karena dia sudah di CD, dan pasti mas Riza-nya request-nya ini cuma ke Jakarta doang.
- Caching nggak? Apa harus di empty cache and hardly load, biar lihat aslinya?
- Coba aja disabled cache, pencet disabled cache itu yang...
- Oh iya, terus refresh lagi ya?
- Iya, refresh. Coba lihat.
- Sama, kurang lebih sama.
- Beda.
- Beda, lebih besar.
- Waiting response-nya lebih gede ya.
- Tapi ini hampir-hampir sama. Queuing-nya sama.
- Ini kan static code.
- Iya.
- Ininya juga naik sedikit. Ini yang paling gede ya.
- Iya karena...
- Sama port download-nya juga lebih gede.
- Iya.
- Oke, ini TTFB.
- Itu hanya untuk nge-request HTML-nya ya.
Ini bisa berlaku hal yang sama dengan image, JS, CSS juga sama.
Bisa lihat timing API di sini.
- Ini hanya satu file ttfb/index.html kan?
- Yes, betul.
- Oke.
Kalau misalkan nanti image, teman-teman juga bisa klik aja di image-nya misalkan ini.
- Iya, bisa kelihatan tuh.
241.ttfb untuk si image.
Nah, web vital itu ttfb untuk HTML-nya ya, bukan untuk image ya.
- Oke.
- Nah, cuma ini menarik sih, metric ini menarik.
Karena kan time_to_first_by itu salah satu yang paling awal.
Apakah dia mengukur speed kecepatan?
Iya, betul.
Apakah dia mengukur, ya pokoknya itu kecepatan betul.
Cuma kan ini dulu belum fokus ke perspektif user experience ya.
Jadi fokusnya ke kecepatan dan itu tadi apa?
- Ini back-end.
Lebih ke arah back-end.
- Server response.
- Server performance.
Jadi kalau mau optimize ini supaya lebih cepat lagi, optimize-nya di back-end.
- Nah, ini dulu saya nggak ini nih.
Belum ada.
Jadi bingung.
Measure-nya berapa?
Yang cepat itu berapa?
Nggak ada angkanya kan.
Kalau ini kan ada ya.
Kira-kira 800 millisecond di atas 800.
Lebih cepat dari 800 millisecond artinya itu bagus, gitu kan.
- Iya.
- Cuma kan ini penting, tapi nggak dimasukin core web vitals.
Nah, kenapa kayak gitu?
Karena buat user kan nih juga nggak penting di byte pertama itu munculnya kapan, apa, diterima oleh browser kapan kan.
User nggak tahu.
Kalau selama belum diparsing, belum diproses lah, belum diolah.
Nah, itu kan nggak bisa dibilang tanda putih nggak penting buat user.
Bukan berarti nggak penting beneran.
Kalau misalnya diterima dari server lama banget, ya pasti ngaruh ke user juga.
- Kalau TTFP-nya kelamakan, LCP-nya jadi naik.
- Iya, pasti semua juga jadi lambat.
- Ada hubungannya, cuman...
- Semuanya ke delay, semua ke delay.
- Tapi nggak secara langsung.
- Tidak secara langsung.
- Walaupun ya itu sampai sekarang kan tetap bisa dihukur tuh untuk diintegrasi ke DevTools juga.
Tapi nggak dimasukin ke tiga item core web vitals itu.
- Hmm, oke.
Jadi yang masuk ke dalam kategori core web vitals adalah ini ya, tiga ini ya.
- LCP, CLS, dan soon FID menjadi INP.
- FID itu nanti bakal direplace oleh yang baru namanya INP dan ini masih ada hubungannya sama topik IO 2023 ya.
Kita bahas dua episode kemarin, ini di-announce-nya di IO.
Ini mungkin bisa dijelaskan secara singkat, LCP apa, FID apa, LCS apa.
- Bisa, nah kalau...
- Ini udah ada di sini.
- Iya.
- Iya, sambil baca, sambil di...
- Iya, sambil baca.
Nah, agak supaya, temen-temen supaya jangan salah persepsi, LCP itu bagian, kalau diartikan adalah bagian yang terbesar
yang above the fold.
Jadi saat page load, bagian elemen yang terbesar di layar, yang muncul di layar itu adalah largest contentful element.
Nah, tetapi itu bisa berganti ya, misalnya begini.
Bayangkan di halaman page, di desktop dulu deh supaya gampang.
Coba Mas Riza scroll paling atas dulu deh, saya mau jelasin paling atas.
Scroll paling atas biar ada nggak.
Oke, stop.
Nah, sebagai salah satu contoh, kalau kita lihat dari sini, largest contentful pane-nya tentu
mudah dibilang dikatakan adalah si background image.
- Image.
- Si image itu ya.
Tetapi bisa jadi begini.
- Prakteknya, prakteknya kan yang malah jagungnya itu.
- Iya, bisa jadi begini.
- Saat pertama kali di load, ternyata kita nggak membuat si image ini face priority-nya tinggi
atau loading eager, atau kita bikin dia loading lazy.
- Iya.
- Karena kita nggak tahu, kita bikin dia lazy load.
Dan yang muncul pertama kali adalah si title web vital.
Maka yang dianggap largest contentful pane pertama kali itu web vital tulisannya.
- Tetapi ternyata si image ini lazy load atau kegedean.
Dan dia selesai di download dan di render.
Maka next si LCP itu berganti menjadi si image.
Dan kalau itu terjadi, maka LCP score kalian akan menjadi sangat tinggi.
Bisa jadi di atas 3 second.
- Kalau tinggi berarti nggak bagus ya?
- Iya, karena bagi si user, waktu dia pertama kali load, dia lihat web vital-nya dulu baru muncul si image.
Yang harusnya, kalau bisa sih berbandingan.
Karena si image-nya dibuat face priority-nya tinggi atau pakai HTTP/2 sudah dipush.
Jadi sudah tahu image ini bakal ada, dipakai, sudah dipush.
Jadi saat di render sudah berbandingan.
- Atau bisa diakalin lazy loading pakai placeholder yang base 4 atau blur hash atau apapun.
Jadi si algoritmanya, dia kan mendeteksi kurang lebih bentuknya, proporsinya, ukurannya, tampilannya.
- Dia cuma mendetek elemennya sih sebenarnya.
Dia ngedetek elemennya, karena elemen itu termasuk size.
Jadi size elemennya itu kalau terbesar itu yang dianggap dan setelah selesai di load.
Jadi untuk memperbaiki LCP, lihat saat face loading mana elemen terbesar dan optimize itu.
Kalau dia image, cepetin download-nya.
Kalau dia title, cepetin font-nya selesai.
Kalau dia embed, itu yang susah.
- Pelajarannya adalah jangan sampai embed, jadi LCP.
Kan bisa di cek pakai DevTools juga ya.
Kita tak tahu, kita tepat-tepat wawangis dimana yang LCP gambarnya atau text-nya.
Nah, biar tahu, biar dilihat.
Bisa cek di DevTools atau di PageSpeed.
- DevTools, kemana nih?
- Lighthouse ya.
Eh, gimana ya?
Bukan, kalau mau itu di ini.
Bukan, ini lama.
Bisa pakai measure-nya itu, inside.
Eh, sorry, kok gua...
- PageSpeed, inside?
- Bukan, bukan, bukan.
Itu loh, apa?
Performance...
- Nah, ini respons-nya lama nih.
- Performance Monitor.
Bukan, salah.
Gua kadang...
Performance Insight.
- From extension.
- Bukan, Performance Insight.
- Performance Insight.
- Ya, itu ini si...
- Effective Insight.
Terus, apa lagi ini?
Actionable Insight on your web performance.
Ada banyak sebenarnya.
- Performance Insight Panel, ada di DevTools.
Iya, Performance Insight Panel.
- Ini bukan.
Atau ada more?
Ada, ada, more.
Gua pernah pakai, kok sekarang jadi lupa sih.
- More, more monitor.
Bukan, itu kalau yang untuk monitoring secara ini.
Ada yang sampai kayak dikotakkan gitu, tambahnya kayak dikotakkan.
Element yang dihitung sebagai LCP.
- Kok sudah mana sih?
- Iya kan, dulu ada kan.
Masalahnya dulu di PageSpeed tuh udah juga sebetulnya.
Cuma sekarang udah berapa?
- Kayaknya ini deh.
Gua maksudnya di Opera nggak ada, jadi gua harus ke ini.
Harus ke Chrome.
- Bisa gitu ya?
Iya, si si siapa tahu si Opera-nya nggak ini lagi nggak.
Nggak hapus bagian itu bisa juga.
Yep, Performance Insight.
Eh, sini gua share stream.
Paling enak sih menggunakannya ya.
Bisa ada banyak hal yang lain juga sih yang.
Performance Insight, ini ya.
Jadi dari Chrome, hapus dulu deh.
Nah, More Tools, Performance Insight.
Terus, Measure Page Load.
Nanti kelihatan beberapa metrics.
Bisa dilihat.
Bisa kita lihat.
Matiin dulu.
Ada kapan DOM Content Load selesai.
Kapan Largest Content Load ini.
Ketau kita ukur kesini, dia langsung kasih tau Largest Content Load ini yang mana.
Dan kalau terjadi Layout Shift, misalnya kelihatan di sini nih.
Terjadi Layout Shift.
Kita bisa gedein.
Terus kita lihat.
Bisa replay.
Bisa kita lihat apa sih yang berubah.
Ternyata nggak ada yang berubah sih sebenarnya.
Oh, ada tuh.
Lihat, ini. Si apa namanya? Si...
Si icon.
Iya, lihat tuh.
Apa istilahnya? FAB ya? Floating Action Button.
Nggak tau lah apa ya. Pokoknya terjadi Shift di situ.
Kelihatan tuh.
Nah, kita bisa perbaiki.
Itu kolong sampai mendetail.
Terus bisa kita lihat juga.
Si saat page load apa aja yang dikirim.
Jadi dia kirim HTML-nya dulu, dia kirim font, dia kirim CSS.
Terus kemudian JavaScript dikirim.
Ini kan ternyata dia kirim JavaScript itu setelah selesai Dom Content Loaded nih.
Which is bagus kan.
Jadi nggak ada yang render blocking.
Iyalah. Web.dev.
Contohnya terlalu bagus ini, terlalu ideal.
Gitu ya, terlalu ideal ya.
Gak apa-apa lah.
Terus yang kayak GTM-GTM dia di-for setelah, setelah ini nih.
Dom Content Loaded.
Setelah LCP.
Setelah LCP di-render.
Setelah selesai LCP di-render baru dia jalanin GTM dan segala macemnya.
Karena terlalu cepat jadi nggak kelihatan.
Biasanya ada load. Load itu ada-ada.
Terus ada TTI, Time To Interactive.
Dia di sini setelah selesai apa ini?
Kayaknya si set storage dia ini.
Atau analytics ya. Gak tahu deh apa yang mau dijebakan itu.
Oke.
Nah, kalau mau yang versi simple banget sih bisa cek di speed web dev juga.
Coba ya, share stream.
Oke. Yang ini atau?
Benar ya. Ini ya?
Iya. Nah, coba scroll ke bawah.
Ini, first content in vain.
Terus kan ada itu tuh ke bawah lagi, show audits related to click LCP.
Di bawahnya screenshot.
Di bawahnya screenshot.
Show audits related to LCP.
Oke.
Nah, terus.
LCP element.
Ini menarik banget sih kan kita nebak bahwa LCP-nya itu bakal apa?
Ini di mobile ya. Keadaan di apa? HP.
Kita nebak, entah itu double atau gather image.
Ternyata salah semua.
Ternyata cookie consent.
Cookie consent.
Ya betul.
Kalau di layar HP kan yang paling peminan, yang paling apa ya, bagi user itu secara visual itu bagian konten utama dari layar itu.
Memang si cookie consent kan.
Kalau di desktop, mungkin lain. Coba deh cek di desktop apa LCP.
Itu di tab paling atas kan ada mobile dan desktop.
Oh oke.
Performance 100 semua.
Pake party town kali dia.
LCP-nya apa? LCP-nya apa kalau di desktop coba?
Naik dikit naik dikit.
Pas audits, atas dikit.
Atas.
Oh ini ya.
Blog quote.
Jadi emang nggak bisa di prediksi.
Pertua manggis itu nggak bisa.
Karena yang menurut algoritmanya si Lighthouse ini dia paling peminan secara visual, ternyata itu.
Oke.
Perlu direlat sedikit itu bukan algoritma si Lighthouse tetapi algoritma si performance API.
Oh itu ada API-nya sendiri?
Iya. Si Lighthouse itu sendiri hanya mengambil data dari performance API.
Meskipun performance API itu inisiatifnya si Google dan temen-temennya juga sih.
Tapi konsorsi om.
Underlying teknologinya dari performance API.
Performance API.
Lighthouse.
Lighthouse cuma jadi reporting-nya saja sih sebenarnya.
Rapper lah ya.
Nah LCP ini menarik karena sebenarnya dia evolusi, semacam evolusi dari FCP kan.
Dulu sebelum ada LCP, sebelum ada Larges Contentful Pay, dulu ada ya sampe sekarang juga ada FCP.
First Contentful Pay.
Iya.
Jadi itu dulu dia mengukur.
Jadi kan paling pertama dulu ada time to first bite, dianggap itu nggak merepresentasikan penalaman user.
Karena first bite diterima, ya kan kalau layarnya kosong tetap aja bagi user itu terasa lambat.
Walaupun sebetulnya udah diterima.
Terus ada First Contentful Pay, itu kan pixel pertama ya?
Atau apa lah? Element, oh download element di render ya kalau misalnya.
Bukan, element pertama yang kelihatan.
Yang ada visualnya.
Bisa jadi header, bisa jadi logo.
Bisa jadi logo.
Loading spinner.
Loading spinner.
Dulu jamannya create-create app itu kayaknya cara ngakalin FCP yang paling populer yaitu
pokoknya langsung tampilin loading spinner di shell indexa TML-nya.
Nah, abis itu diganti.
Tapi kan itu juga nggak mewakili user experience.
Kalau misalnya cepet, terus langsung render logo atau loading spinner atau text loading.
Itu kan tetap aja buat user experience kurang bagus.
Jadi makanya apa?
Berevolusi, yang dimasukin kurang by vitals, akhirnya si largest study kan, si LCP tadi.
Oke, jadi LCP.
Berikutnya kita bahas CLS dulu ya.
Ya, CLS dulu.
CLS ini apa?
Stability, Layout Stability itu kestabilan dari si...
Pernah nggak melihat ada situs font-nya kegedean atau kebanyakan.
Sehingga waktu di-load, pertama kali font biasa, terus dia berubah.
Tapi berubahnya banyak.
Oh, mungkin satu font-nya terlalu pendek, terus tiba-tiba jadi memanjang atau semacamnya.
Atau bentuk font-nya aja yang...
Bentuk font.
Bukan font ada yang gepeng, ada yang...
Iya, bahasanya kerningnya.
Kerningnya beda tuh, space antar karakternya berbeda.
Nah, jadi font satu dengan yang lain ternyata yang default-nya nggak mirip dengan font yang kalian butuhkan.
Dan pakai biasanya jaman dulu itu, pakai Google Font semua size dipakai.
Terus ada 5 font, semua dari Google Font, semua-semua size dibawa.
Dan di-load cuma satu URL.
Dan font-nya pun di-import dari CSS.
Jadi tunggu CSS-nya kelar, diparsing, baru dia download lagi font.
Jadi kayak chaining.
Chaining URL gitu.
Sehingga font-nya download-nya kelamaan.
Akhirnya tadi font-nya kecil, terus akhirnya membesar, kerningnya berbeda, akhirnya mendorong semua.
Nah, itu pengalaman yang nggak enak banget buat si user untuk membaca.
Ada juga yang kayak gini nih.
Nah, ini yang paling ekstrim sih nih.
Dia nge-load.
Sering banget.
Ada iklan.
Jadi ada elemen entah itu iklan, image atau apapun itu yang di atas, tapi nggak dikasih ukuran.
Belum selesai loading kan, kalo belum di-load, belum ketahuan ukurannya, ya nggak occupy tiksel sama sekali.
Selesai langsung nular, otomatisnya dibawahnya kedorong semua.
Nah, iklan juga sama ya.
Ini contohnya banyak.
Tapi beneran ada loh kayak gini itu.
Oh beneran?
Ya beneran.
Selama ini kan gue pikir, ini cuma buat demo.
Yang kasus ekstrim kayak gini cuma buat demo.
Tapi beneran, jadi di sebuah situs, ya ini mah bukan sebuah monopoli.
Pas pesen tiket, kereta, bandara.
Itu beneran ada logo.
Jadi itu kasusnya logo-logo pembayaran bank.
Bisa lewat credit card, bank atau Bitmootown, blablabla.
Itu logonya kan pake image.
Nah, itu beneran nggak dikasih exact size gitu.
Dan beneran kepencet reset dong.
Kenapa juga form pemesanan ada resetnya, nggak ngerti.
Ke reset.
Jadi itu kisah nyata, dan bukan cuma di demo doang.
Bisa terjadi.
Nah, ada sedikit sesuatu yang ingin saya luruskan mengenai CLS.
Bisa naik sedikit, Mas Liza.
Jadi CLS itu bukan hanya saat page load aja di ukurnya.
Jadi teman-teman nanti naik terus, naik terus, terus.
Tadi ada grafiknya.
Terus, terus, terus, terus, terus, terus, terus, terus, terus.
Ini dia.
Comulative Layout Shift diukur sepanjang halaman itu hidup.
Jadi artinya supaya fair untuk yang pengguna SPA, dibuat last session.
Kalau nggak salah, X amount of seconds, saya nanti bisa baca di sini, kalau nggak salah sih 10 detik ya.
Itu ada session-sessionnya sebelum dia di reset.
Jadi kalau misalnya si user nge-scroll, kalau dia stop, terus scroll lagi, stop, scroll lagi.
Itu artinya saat dia stop, CLS-nya di reset.
Jadi nggak naik terus, nggak cumulative terus.
Kedua, kalau ada user interaction dan terjadi shift, itu tidak dihitung.
Contohnya ingat nggak kalau ada kita pagination, load more, puter, terus kan dia nge-scroll.
Itu tidak dihitung Layout Shift ya. Karena ada user interaction.
Tetapi dalam jangka waktu tertentu selama dalam session ini.
Jadi ada jedahnya.
Ada window, ada durasi toleransi setelah user melakukan satu action.
Betul.
Kayak gini ya? Yang ini ya?
Ini kan klik "me" itu, pen ke bawah itu kayak misalnya, itu tahu nggak sih drop-down atau tab content.
Kalau kita pencet ternyata tab yang kedua, kontennya lebih panjang.
Itu nggak dihitung Layout Shift.
Nice ya. Ini beneran bikin kriterianya dan parameternya beneran berdasarkan user experience ya.
Jadi kayak kalau user melakukan satu action, kayak mencet button gitu kan, itu ekspektasinya bakal terjadi sesuatu.
Oke, untuk saya itu hal yang normal.
Cuma kalau user nggak ngapain, belum ngapain, tiba-tiba geser sendiri, nah itu kan annoying.
Karena ya itu tadi bisa bikin, bisa mengganggu user lagi ngebaca atau nonton sesuatu.
Bisa mengganggu target user ingin akan melakukan suatu action, salah pencet.
Nice, jadi kayak itu udah bukan biur teknis, tapi dari perspektif mata atau interaksi user-nya.
Nah, bagi saya CLS ini adalah web vital yang paling susah diperbaiki.
Jadi kalau simplenya ya bagi temen-temen yang pakai untuk mencegah Layout Shift, semua elemen pastikan ada height-nya.
Kalau itu X, ya pasang height-nya.
Untuk X, jadi sudah tahu di situ ada X, ukurannya berapa, kasih height-nya berapa.
Kalau itu button atau image, tahu height-nya, dikasih height-nya berapa.
Itu sudah pertanyaannya, kenapa kadang kalau total page-nya sedikit itu gampang.
Tapi kalau anggap ini situs berita yang halaman artikelnya sudah ada jutaan,
itu CLS score ke seluruh domain itu kan adalah rata-rata dari seluruh page, bukan satu page.
Jadi bisa jadi CLS, home page-nya sudah bagus, tapi kenapa CLS kita kok begitu-gitu saja, susah perbaikinya.
Dan harus di teliti itu per page-nya, dan ternyata kita ke page itu juga ternyata nggak ada CLS, terus kemana kita harus cari.
Itu bisa jadi ads, terus ads targeting, geografik, bisa beda geo, beda ads.
Jadi user itu kan dari berbagai macam device juga dan berbagai macam negara.
Jadi harus cek per negara.
Nah, yang paling susah adalah embed.
Tiktok embed, Instagram embed, ya kalau kita embed, itu videonya sekian.
Content-nya, caption-nya bisa dynamic.
Dan cara kita nge-embed TikTok atau Twitter itu kan cuma kasih snippet, dan JavaScript-nya nge-load,
dan kita belum tahu, kita nggak tahu berapa total size embed-nya.
Nggak bisa tahu, itu tergantung hasil response dari hasil embed-nya itu.
Itu sampai sekarang belum ada obatnya, hanya bisa diakalin.
Square terus C-more ya? Kayak di ekspansi?
Nggak, nggak. Jadi itu dari ada satu, pernah saya baca, CLS salah satu situs di Medium.
Nanti saya ingat nanti saya kasih link-nya.
Jadi caranya mengumpulkan field data, nanti kita bahas mengumpulkan field data bagaimana.
Data-nya itu dia kirim ke via GTM, dia kirim ke BigQuery, via analytic.
Dia kirim CLS-nya, dia target embed tertentu, misalnya TikTok embed.
Terus kemudian dia target, dapat tuh CLS-nya, dia kirim CLS-nya.
Terus kemudian, sorry bukan CLS yang dikirim, element height-nya dia kirim.
Jadi dia bisa dapat rata-rata height TikTok yang dia pakai berapa.
Nah, dari data itu dikembalikan ke parameter-nya sistem mereka untuk nge-set.
Oke, rata-rata total element TikTok kita 300 pixel height-nya.
Ya udah, diset lah 300. Jadi kalau height-nya lebih kecil, ya udah nggak masalah jadi kosong.
Ya udah, nggak masalah kalau jadi kosong kan.
Tapi kalau yang lebih besar, at least, yang besar nggak terlalu jauh loncatnya.
Jadi bisa diminimalkan, hanya bisa begitu caranya sekarang.
Itu pakai mengumpulkan data, jadi field data.
Itu CLS, gampang-gampang susah.
Susah, susah, gampang.
Susah, susah, susah.
Lebih banyak susahnya apa lebih banyak gampangnya?
Kayaknya nggak ada gampangnya susah, susah, susah.
Ya tapi kan sebenarnya di luar, kalau embed itu kan kasus unik ya.
Maksudnya kasus khusus karena kontennya dinamik, kita nggak bisa expect.
Tapi kalau buat hal-hal lain kayak image atau apapun.
Even embed, kalau embed-nya kayak video gitu kan kita udah tahu rasio-nya ya.
Pernah nggak baca situs yang kayak board panda jaman dulu?
Atau jaman sekarang sih masih ada sih board panda.
Dia kumpulan, kumpulan lucu-lucuan.
Dia kumpulan lucu-lucuan dari Twitter, kumpulan lucu-lucuan dari embed-embed.
Dia kumpulin, kan dia kumpulin itu satu page.
Isi satu page isinya embed semua.
Ya itu shifting semua ya.
Kalau kebetulan atas dapet tugas nge-develop halaman yang kayak gitu ya sebetulnya gimana lagi.
Kalau itu sih ya kita kan minimal kita bisa ngomunikasiin ke stakeholder.
Kenapa CLS-nya nggak sebagus situs lain.
Ya karena monennya gitu.
Ada ini kan.
Nanti Google bikin inisiatif lagi apalah buat men-streamline format atau metadata juga.
Kalau nggak salah beberapa embed, terutama yang Twitter ya.
Beberapa embed Twitter itu ada orang yang bikinin semacam tools atau plugin
yang bisa melakukan screenshot.
Jadi nanti dia embed terus abis itu dia embednya dalam bentuk image yang ukurannya sudah tau, udah ketahuan.
Ya jadi si embednya itu bukan embed HTML tapi embed screenshot dari Twitter itu.
Tapi ada proses di servernya.
Iya ada kerja berat di servernya untuk melakukan screenshot tadi.
Cuma buat kasus di luar itu sebenarnya property CSS aspek rasio itu membantu banget sih.
Untungnya udah stabil di semua browser aspek rasio kalau nggak salah.
Jadi di luar kasus-kasus yang kayak gitu kalau hal-hal normal kayak image static asset gitu, static image,
static video, atau embed YouTube yang rasio-nya udah pasti fix, itu pakai aspek rasio juga aman.
Itu linknya Mas Rizah.
Itu yang saya dapat improving CLS dan Buzzfeed.
Nah itu saya praktekkan dan saya coba dari sampai tiga-tiga part itu.
Ya kalau Buzzfeed resource-nya cukup lah kayak mau saya apa buat mastiin CLS bagus aja beneran se-niat ini.
Iya, nah ini kayak kalau misalnya saya mau belajar banyak bacalah yang Buzzfeed ini untuk mengetahui
tekniknya karena mereka ada downfall, proses-nya itu bagus banget dengan nulisnya.
Oh nice, seru banget sih.
Wah seru ya.
Ada satu ini kok ada, gue cari dulu linknya di Buzzfeed ini juga kok untuk cara ngitung
layer-nya si embed itu gimana ya.
Sampai teriak banget.
Nah ini kan CLS ini kan kalau ada iklan yang baik itu iframe, atau image, ataupun apapun yang
nggak ada hit-nya kan tiba-tiba dia muncul kan kayak tadian.
Ini ya, awalnya kan gini ya, terus tiba-tiba ada iklan di atasnya.
Layoutnya jadi turun ke bawah, gimana kalau iklannya overlay di atasnya.
Kalau overlay malah nggak apa-apa kan.
Oh malah lebih bagus gitu, jadi lebih banyak iklannya menimpa aja si kontennya.
Eh iya kan, CLS gitu kalau elemennya geser kan, jadi pergeseran yang dihitung.
Tapi kalau Google Ads, Google Ads harus ada rapper-nya dan mengatakan itu Ads.
Kalau nggak melanggar tos.
Tapi kan itu dari user experience kan jelek, kita lagi mau baca tiba-tiba ada iklan di tengah gitu.
Kita jangan di atas ya, kan banyak banget itu yang footer, namanya footer ads kan.
Footer ads-nya float kan, sampai kita harus klik manual supaya dia tutup.
Itu ya everything yang saya lakukan sehari-hari.
Tapi kan nggak apa-apa ya, just room.
Tapi CTR-nya tinggi, CTR-nya tinggi itu yang Ads yang dibawa itu.
Di mana pun kebutuhan conversion rate ya?
Iya CTR, quick to write.
Ya kan kebutuhan business juga tetap harus diakomodasi.
Kalau misalnya kita sebagai developer kayak malah kayak bertentangan sama business ads yang bakal jalan juga.
Itu coba klik satu link-nya Mas Riza, sekaligus embed itu kenapa susah kita nggak tahu ukuran sebenarnya.
Karena setiap device atau width-nya berbeda, ukurannya berbeda.
Klik aja deh salah satu twitter ya.
Nanti dia akan misalnya ukuran device berapa, dia akan ngecek ukuran si embed itu berapa.
Jadi dia akan sampai ukuran device yang terkecil, nanti kita lihat hasil code snippet-nya ya.
Tapi kalau nggak salah ya, kalau kita mau embed youtube itu kita bisa tambahkan ukurannya, width dan height-nya.
Oh kalau youtube emang bisa iframe.
Kalau si embed twitter nggak bisa iframe kan, jadi CSS-nya jadi begitu tuh.
Jadi kasih minimum height.
Kalau twitter harus pure dynamic kan.
Nah Instagram juga.
Jadi untuk size berapa, minimum height-nya berapa.
Kalau video tiktok juga gitu ya beda ya.
Oh iya, ada yang portrait gitu ya.
Betul.
Portrait semua, yang beda itu caption-nya.
Di bawah ada caption-nya itu misalnya.
Video-nya tetap pasti sama ya.
Kalau di bawah ada orang nulis puisi, nah repot.
Oke oke oke, make sense.
Ini salah satu tools-nya ya.
Ya, CLS.
Oke, nah itu CLS.
Ada lagi yang mau dibahas?
Nah ada nih yang relatif lebih sepele, kalau misalnya tadi masalah yang dari phone.
Ada tuh tools-nya, phone style matcher.
Bukan di chat.
Nah kalau misalnya, ya sebenernya kita pernah bahas ini kan ya dulu di episode phone.
Soal apa, fallback phone, teknik-teknik web phone.
Silahkan klik link di bawah sini loh.
Di atas sini ya, di mana lah, cari sendiri lah.
Tapi salah satu teknik yang, teknik standarnya ini.
Kita pilih fallback phone yang bentuknya kurang lebih mirip sama web phone yang kita pakai.
Sudah ada, ada yang otomatis loh.
Tapi gue lupa namanya.
Sudah pernah kita bahas juga, ada yang otomatis.
Ya udah, cari aja.
Iya, cari aja.
Ada, bisa tau ininya.
Kemiripan phone-nya.
Ya kalau Google phone apa kita pakai, yang mirip sama apa kita.
Oh iya iya, similar ya.
Ya kamu yang, nah ini juga kan kita tinggal pilih, terus udah dibikinin loh.
Oh iya iya.
Tuh bisa matchernya gitu, tuh bisa kelihatan.
Cari yang pas.
Apa bawa-bawahnya nggak kedorong.
Oh bisa tambahin line height-nya gitu ya.
Kita customize bisa, tapi kalau kita nggak mau nge-customize, itu udah di programmetically dipilihin yang mirip.
Jadi tidak terlalu jauh perbedaan shifting in layout-nya ya.
Yang penting jangan sampai ngedorong sih.
Ini jelas banget, ngedorong antara satu dan yang lain.
Beda height, cari yang sama height-nya.
Sampai pas.
Oh iya.
Oh iya.
Ya intinya begitu.
Pake grid CSS dong, ini sudah ada paketnya.
Siap-siap, kita belum bahas tentang layout-leot ya.
Iya, flex sama grid belum?
Flex sama grid.
Float lah.
Table lah.
Table, table.
Position absolute.
Table lah, table.
Envas lah, kayak kemarin kita udah dapet semua.
Oke, untuk CLS cukup ya.
Nah, berikutnya, ini ada FID.
Tapi FID akan tergantikan.
Jadi kita mungkin singkatkan FID adalah measure to interactivity kan.
Jadi tujuannya adalah untuk menyediakan experience yang bagus ketika...
User berinteraksi dengan element.
User bisa berinteraksi, bisa scroll, bisa...
Bisa scroll, bisa ngetik di input.
Bisa ngetik di form, search misalkan, gitu ya.
Klik, buka misalnya hamburger menu atau accordion atau apa, diklik, ya pas habis diklik...
Mendingnya langsung muncul, ekspektasinya begitu.
Berapa detik sampai ke tahapan itu berarti ya?
Bedanya fast input delay ini...
Hanya mengukur input delay yang pertama kali terjadi.
Setelah page load.
Oh, oke.
Jadi user itu ngeklik setelah page load selesai...
Tak usah nunggu page selesai, jadi page-nya lagi render, kita pencet apapun...
Berapa lama delay sampai action kita itu bisa di eksekusi.
Jadi kalau misalnya main thread-nya sibuk terus...
Ya maka kita punya action-nya akan lama, gitu.
Oke.
Jadi diulang sedikit sekilas, kita kan browser ini cuma bisa single thread ya.
Jadi kalau misalnya lagi parsing, apalah membaca CSS atau bikin fast script...
Atau lagi render sesuatu, dia nggak bisa disambil ngapa-ngapain.
Maksudnya nggak bisa disambil melakukan hal lain, harus menyelesaikan yang sedang dilakukan.
Habis itu baru melakukan task selanjutnya.
Kita punya episode event work juga, click link-nya di sini ya, di manalah.
Jadi maksudnya itu yang menyebabkan delay.
Mau nggak mau sih, pasti ada sekian millisecond buat memproses...
Apalah JavaScript, render component, atau melakukan hal-hal lainnya.
Cuma dibatasi jangan sampai terlalu lama ya.
Jangan sampai nggak halangin task lainnya, kalau nggak salah 200 millisecond-nya.
100.
Eh 100, oh iya 100.
Dan tambahan juga pada saat browser parsing HTML, itu dia sequential, jadi baris per baris.
Baris ini, terus kesini, terus kesini, gitu kan.
Makanya kan ada beberapa tips yang menyatakan bahwa...
Kalau script loading itu dibawah aja sebelum gue ditutupkan.
Ada yang masuk dibawah, tapi habis itu ada teknologi asing, defer.
Ya, ya.
Nah disini ada beberapa script yang ada disini juga.
Jadi ini dieksekusi dulu sebelum kesini, sebelum ke CSS.
Jadi script ini dijalankan dulu.
Kalau script ini istilahnya ada bottleneck atau agak lambat,
Maka CSS ini akan menunggu giliran, jadi satu persatu.
Gak diasing atau defer, ya udah sampe dia selesai.
Ya, kecuali ditambahkan property asing dan defer ya.
Oke, itu FID, dan dari Google I/O beberapa waktu yang lalu,
FID ini akan digantikan oleh INP.
INP, tapi belum. Masih belum dapat stable-nya tahun depan.
Cuma di-announce dari sekarang, biar kita sebagai developer punya waktu
buat mempelajari dan coba improvement.
Tetapi akan datang, jadi ini bukan coba-coba lagi, ini sudah di-announce.
Tapi sudah pasti ya, sudah pasti akan digunakan.
Tapi sekarang belum.
Interaction to next page.
Nanti kita lihat di Almanak 2024 gimana ya hasilnya.
Hasilnya IRP.
Ini apa nih GNC ini?
Nah, ini evolusinya.
Kalau menurut gue sih ini evolusinya si apa tadi?
FID.
FID tadi, kan FID cuma ngukur yang pertama kali first interaction.
Wadah kan interaksi bisa lebih dari sekali ya.
Nah, apa? Mungkin ini first lebih advance-nya.
Jadi dia mengukur semua tab, click, dan keypress ya, gitu kalau gak salah.
Nah, itu event-event.
Keyboard dan tab.
Performance API-nya sudah ada loh.
Jadi tinggal dicoba aja kalau mau.
Kapan-kapan deh episode performance API sendiri kali ini?
Iya nih, performance API itu apa dan gimana cara kita eksplorasi kesana.
Jadi gue kasih dimana ya.
Disini aja deh.
Bisa gak ya?
Mana?
Oh, itu gue kasih di link-nya, bukan link-nya.
Maksudnya script-nya.
Bisa.
Copy aja, kasih kejalanan di konsol.
Oke, dibuat...
Bisa playing site ya.
Di samping aja.
Buat kesamping aja, Mas Riza, biar enak liatnya.
Iya, nah.
Jalanin, ketek.
Tenang-tenang, ini gak nyuri data kok.
Nah, ini Mas Riza, klik aja di mana-mana, klik aja terserah.
Tuh, kelihatan tuh.
Bisa juga klik, ya itu.
Itu kelihatan tuh ya, jadi processing start, processing end, cancel level.
Kalau salah satu objeknya diturunkan.
Objek?
Objek itu objek yang diturunkan.
Itu ada duration.
Duration.
Nah, nanti yang diambil itu duration-nya itu, 32.
32 apa nih, detik?
Millisecond.
Nah, yang bagus dibawah 200 millisecond, which is, ini bagus.
Yang gak bagus itu adalah yang di atas...
Ya, di atas 200 udah gak bagus sih.
So, yang, ini gak ada, gak ada ini ya, gak ada...
Gak ada form.
Gak ada form-nya, kalau ada form bisa lebih jelas.
Di atas coba, di atas ada search-nya gak sih?
Ada, coba type something.
Aku mau type something, mau type something.
Nah.
Tuh.
Klik.
Eh, ini gila.
Eh, ya.
Kepencet.
Pes lagi.
Ya.
Tadi ya.
Klik.
Something.
Something.
Jangan diklik.
Jangan diklik, oke.
Keydown, berapa lama tuh?
Keydown, keydown 1.
Duration-nya 24 millisecond.
Iya.
Keydown 0, 24 juga.
Ini bagus ya, berarti ya?
Bagus.
Bagus lah.
Kalau jelek...
Itu 0.24.
Belum.
Jadi sebenarnya datanya sudah ada di performance API.
API.
Tapi ini diadopsi sebagai core Web Vitals, kan.
Terus significance-nya itu.
Ya, berarti buat apa?
Yang belum tahu lah ya.
Yang belum tahu.
Perlumahan dari API itu berarti browser JavaScript API
yang berhubungan dengan menghitung atau mengukur performance-nya.
Metrik, metrik.
Metriknya.
Oke.
Nah.
Ini INP ini juga misalnya kayak drop-down, search, form, input.
Drop-down kayak gini.
Misalnya kalau kita klik kelamaan, itu kan user tuh bisa klik-klik-klik kan.
Ternyata kok nggak muncul-muncul dia, gitu.
Itu ada contohnya kan di INP itu kita buka menu.
Tapi karena lambat, kirain, oh, nggak pencet nih, kita pencet lagi.
Padahal dia benar-benar buka.
Ternyata dia...
Dia tutup lagi.
Itu annoying.
Iya, pencet dua kali, gitu ya.
Iya.
Dan malah jadi motu, bukan?
Iya, iya, iya.
Sama kayak itu ya klik tombol like ya.
Klik tombol like dua kali.
Oh iya, betul.
Jadi biasa aja, jadi netral.
Cukup namakan kerjaan sempen.
Iya, betul.
Oh ini dia ya, yang tadi?
Iya, betul.
Untuk ngukurnya itu sudah bisa pakai ini.
Sudah, kalau mau lebih simpel pakai yang Web Vitals JavaScript Library.
Sudah bisa kita ukur pakai on INP.
Ada banyak lagi on LCP, on TTFP, on CLS.
Kita bisa kirik.
Kan datanya bisa di-capture nih.
Ini sebenarnya wrapper dari performance API.
Data yang kita dapat sini bisa kita kirimkan ke Google Analytics sebagai custom event.
Oke, jadi bukan hanya kita ukur lewat DevTools atau PatchSpeed Insight atau apapun.
Tapi juga bisa diukur melalui kode ya.
Iya, kode kita sendiri.
Sebenernya kalau kita mau bikin custom dashboard deh, kalau cuma pengen lihat field data atau real data.
Itu tuh sebenarnya otomatis terintegrasi di Search Console.
Udah ada kok.
Nah, cuma kan maksudnya.
Field data kita memang ada di Search Console.
Namun nggak enaknya delay.
Jadi kita misalnya deploy sekarang nih.
Ternyata kita bisa tau itu setelah seminggu rata-rata tuh rata-rata seminggu.
Ternyata naik dari CLS-nya kita.
Kita perbaiki.
Nunggu seminggu lagi?
Nggak, nunggu 28 hari untuk nge-process-nya.
Iya, maka jadi supaya kita tetap bisa...
Tetanggui di PatchSpeed juga itu ya, delaynya.
Data PatchSpeed Insight.
Mungkin sama ya.
Gini, supaya lebih jelasnya.
Datanya Search Console sama PatchSpeed Insight itu datangnya dari Krooks.
CRUX.
CRUX User Experience.
Krooks Report.
Jadi data itu kan dari semua pengguna Chrome ya.
Dan dikirimkan secara anonimus.
Dan prosesnya kan banyak dan lama.
Jadi minimal rata-rata 28 hari baru bisa kita lihat datanya.
Jadi kalau nggak sabaran, kayak saya,
kalau perbaiki sesuatu, ya kumpulin aja datanya sendiri.
Dan kelebihannya bisa custom.
Misalnya kita edit testing kan,
kalau halamannya sama, route-nya sama,
apa URL-nya sama kan di Search Console atau PatchSpeed kan bakal sama.
Tapi kalau misalnya kita pingin detect ada custom tracking-nya ya
harus diintegrate ke analytics kan.
Analytics system.
Betul.
Atau berdasarkan template.
Maksudnya kita kan mungkin punya beberapa variasi halaman
berdasarkan satu template yang sama lah.
Template atau apa pun itu.
Layout, template atau grouping apapun
sesuai kebutuhan bisnis.
Nah kalau kayak gitu harus pakai butuh analytics ya.
Oke.
Itu dia INP.
Jadi ini coming soon.
Jadi kalau kita bisa belajar dari sekarang,
nanti begitu sudah launching, kita udah siap.
Website kita juga sudah siap.
Karena ini sebenarnya kelanjutannya si FID.
Jadi intinya kan kita meminimalisir long blocking task.
Jadi ini bukan hal yang beneran 100% baru banget sih.
Enggak.
Jadi effort kita untuk mengimprove FID selama ini
tetap bisa dipakai buat INP.
Mungkin ada yang lain yang lebih poeh dan lebih diperhatikan.
Sebenarnya ada juga sih akhir-akhir ini kenakalan para vendor-vendor.
Vendor-vendor ini sih.
Maksudnya pembuat plugin,
khususnya di WordPress ya.
Pembuat plugin optimize performance.
Itu mereka mengakalinya begini.
Supaya bisa jadi LCP-nya 100, FID-nya 100, CLS-nya 100, semuanya 100.
Itu mereka hanya melod JavaScript jika ada user interaction.
Jadi si Google kan datang gak ada user interaction.
Dia juga gak detek user header kan.
Dia gak detek user email.
Hanya ada mouse scroll atau klik.
Baru dia ngelod semua JavaScript yang berat-berat itu.
Sudah INP ini, kena gitu.
Sebenarnya kayaknya konungsi semua metric-metric on Web Vitals
itu kan kucing-kucingan antara akal-akalan developer
sama efforts selanjutnya biar gak diakalin.
Misalnya tadi time to first play, FCP.
FCP diakalin dengan loading spinner atau logo.
Sekarang udah gak bisa karena LCP ya udah.
Ini kan sebenarnya gitu juga.
Sama aja kayak CEO juga begitu kan.
Berepolusi terus kan.
Itu dari akal-akalan, akal-akalannya.
Pasti bakal ada merombong lagi.
Nanti bakal aja.
Makanya ini alasannya ini selalu berepolusi sih ya.
Ya, mereka selalu belajar lah ya.
Untuk back end, pada tau gak sih timing API?
User timing API.
Siap dong, siap dong.
Sebentar deh ya.
Kalau, lagi cari, lagi cari.
User timing API.
Ini, ini, ini.
Ini jaman dulu, masih, ini udah lama banget sih user timing API.
Itu bisa, kayak kita bisa mark sendiri.
Kita punya data untuk start and stop-nya.
Ntar, ntar, ntar.
Gue lagi cari, ayo kita coba.
Ada satu lagi bukan user timing API.
Bisa ngirim data dari server.
Sehingga muncul di timing API-nya kita.
Di timing window-nya tadi.
Ini server timing bukan ya?
Ya, server timing API bukannya.
Ini berupa header nih, kalau di MDN.
Iya, dia di kirim header.
Dan header-nya itu akan muncul.
Bisa di track nih, performance.
Muncul, iya.
Apa lagi, coba buka, buka, buka.
Jadi server timing, iya ini maksud saya.
Server timing API ini.
Kalau kita kirim kan tadi yang, ingat gak timingnya?
Oh, itu part of the performance API itu.
Ternyata bagian dari performance API juga.
Iya.
Dan, tadi ingat gak yang tadi saya katakan sama Sriza.
Buka timing, lihat dock-nya, lihat timing-nya.
Itu kita bisa kirimkan dari server.
Untuk via server timing API ini.
Misalnya kita mau optimize modul tertentu, block tertentu.
Yang banyak memakan data.
Banyak memakan database access.
Kita bisa kirimkan header tertentu.
Nanti muncul disini, jadi kita bisa lihat dari sisi user.
Kira-kira berapa, jadi kita gak usah harus punya yang mewah-mewah.
Kayak New Relic lah, atau apa.
Ini ya, pake ini ya, kirimin pake header gini ya.
Iya.
Jadi di sisi server, dihitung durasinya.
Terus abis itu dikirimin ke client.
Sebagai respon, bagian dari respon header ya.
Iya, nanti akan di-capture disitu.
Nice, ini juga TIL.
Iya.
Jadi kalau buat teman-teman yang punya website atau punya project kantor
yang butuh tweak performance, bisa kontak kita.
Kita jadi konsultan.
Konsultan controlling web.
Nanti Ivan yang akan kerjain.
Kita tidur ngomong.
Nanti Mas Rizal jadi ininya, account-nya.
TK jadi ininya, accounting.
Finance.
Kita jadi konsultan.
Tapi kerjanya ngobrol dulu, kenapa?
Karena kita diayani sebagai konsultan ngobrol.
Silahkan, website client-nya tulis di kolom komentar.
Nanti kita audit ya.
Tapi kita auditnya cuma ngomong doang.
Yang kerjanya pada saat itu kali ya?
Iya, kerjanya sendiri.
Kerjanya sendiri, kita cuma kasih petunjuk aja.
Oke.
Jadi ini nih.
Kalau misalkan tadi ada website client atau mungkin website pribadi
atau ada aplikasi web yang teman-teman nonton di rumah
terus pengen supaya performance-nya bagus, low hanging fruit-nya apa?
Hal pertama yang harus dilakukan apa?
Mending buka fake speed aja, ikutin saran-saran.
Ikutin tadi.
Saran-saran fake speed? Betul. Karena kan dia udah di contoh-contoh, ya entah fake speed
atau tools yang ada tadi, performance insights yang ditunjukin tadi.
Itu kan udah saran-saran yang dibawa, kita ikutin.
Kalau core web vital sendiri ada di mana? Di sini ada?
Di mana-mana.
Di lighthouse.
Iya, kalau gak salah, ini ya. Di sini ya.
Ini ada ya.
Di lighthouse ada.
Di lighthouse ada, di web vital ada.
Oke.
Which video sih ada?
Kalau dari saya, kalau misalnya kalian ketemu client
atau misalnya diminta menganalisis ya,
kalian selalu developer, diminta untuk menganalisis.
Ini situsnya cepet gak sih? Apa sih yang harus kalian lihat?
Pertama, start dari jangan lihat per page.
Karena terlalu dalam. Lihat dulu overview-nya.
Kalau dia sudah punya search console, terima kasih, alhamdulillah.
Kalian lihat aja di search console, sudah ada web vital.
Lihat bagaimana performance di search console.
Selanjutnya, coba cek juga di page speed insight.
Karena itu ada data crook di sana.
Jangan lihat lab data dulu.
Jangan langsung keren-kerenan buka browser,
klik lighthouse analysis.
Lihat hasilnya, bagus nih, 90.
Bukan, jadi itu user-nya.
Oke sih, karena field data ditaruh di atas.
Jadi, secara layout, secara six-nya, itu juga membantuan.
Ya, betul.
Lihat field data dulu. Lihat dari hasil pengunjung situsnya bagaimana.
Nah, kalau sudah kelihatan situasinya, tanya dulu ke klien-nya.
Ini tujuannya apa, mau dinaikkan sales-ka?
Atau sekedar ingin cepat aja?
Atau tanya juga, cepat itu bagaimana?
Apakah cepat secara diklik, loading, apa yang paling kritikal harus cepat.
Terus, bisa juga dibandingkan dengan kompetitor.
Siapa kompetitornya yang head-to-head?
Siapa yang kompetitor head-to-head? Tiga.
Terus, compare halaman yang paling kritikal yang kalian punya.
Apa yang kira-kira kompetitor kritikal page-nya apa?
Compare dari semua device, mulai dari mobile, tablet, sama desktop.
Nah, PageSpeed Insight kan punya cross data.
Jadi, bisa lihat juga data kompetitor seperti apa.
Berarti harus pakai BigQuery ya?
Nggak, kalau di PageSpeed Insight kita bisa masukin situs kompetitor.
Baca aja dong.
Iya, manual. Kumpulkan aja di spreadsheet.
Bandingkan, saya bagiin ini ya.
Gak apa-apalah, teman-teman juga.
Bandingkan tuh titik awal kalian, compare ke kompetitor.
Dan compare ke, dan kalian analisi selanjutnya.
Apa aja misalnya bisa diterapin.
Itu kalau nggak salah dari sisi yang paling simple ya.
Selanjutnya, kalian bisa buat static file dari situs itu.
Dan coba tweak tanpa harus mengutak-ngatik coding-nya.
Tahu nggak sih, POC dulu ke kliennya.
Kalau sudah dioptimize, bundlenya segala macam, itu dengan static HTML,
tentu TTFP di eliminate.
Hasil LCP dan segala macamnya jadi bagaimana dengan static file.
Dan bisa kalian buat perbandingan yang spreadsheet tadi.
Data awal, data kompetitor.
Dan kira-kira kalau proyek itu kalian ambil, bisa jadi seperti ini loh.
Misalnya, skornya dari 40 di mobile, jadi 90 di mobile.
Ya udah, kalau kalian bikin proposal-nya kayak gitu, menang deh kalian.
Nah, itu ada calculator skornya juga, siapa tahu ada yang belum tahu.
Oh iya, sekarang udah berubah ya bobotnya ya.
Setiap versi, bobotnya kan perhitungannya selalu berubah.
Versi skor sudah berubah.
Zoom in.
Nah kan Core Web Vitals itu tiga hal yang dibawah ya.
LCP dan TBC Total Doving Time itu mau pilih versi untuk pilih.
Karena FID itu kan cuma bisa dihitung di field.
Harus pakai input user beneran.
Nah, itu kan nggak bisa di prediksi, jadi di prediksinya pakai metric line Total Doving Time.
Terus paling bawah CLS tuh, kita lihat loh, bobotnya kan paling tinggi.
Tiga itu dua lima persen, tiga bulu, dua lima.
Nah, itu tadi misalnya kita, bedanya, biasa sama kompetitor kan kita bisa ngitung-ngitung,
kita bisa mengirang-irang di sini, di bagian mana aja yang harus dinaikin.
Oke, iya.
Yang harus di-prove, dinaikin atau di-prove.
Lima lima, kalau Core Web Vitals ini udah lapan puluh persen ya?
Iya.
Bobotnya, Core Web Vitals itu lapan puluh persen.
Lapan puluh persen, oke.
Siap, siap.
Iya, bisa bawa kita di kolom komentar.
Kita jadi konsolons gitu.
Iya, soalnya kan apa ya, yang ukur-ukur kayak gini kan, ya nggak tahu ya,
kalau konsultan untuk bikin software kayaknya udah banyak sekali kan.
Biasanya kalau konsultan besar, jadi satu lah.
Oh iya, sekaligus ya, sekaligus.
Tergantung, tergantung scope-nya.
Tapi kalau yang re-review dulu agensi, ya pasti apa,
pemperhitungan performansi juga lah, karena itu kan sejujurnya ngaruh ke target business.
Ke SEO juga, ujung-ujungnya kan ya?
Iya.
Dan udah banyak case tadinya juga kan.
Maksudnya misalnya, launching menurun, atau apalah,
reach rate-nya naik dengan Core Web Vitals yang lebih bagus.
Jadi ya, agensi pun pasti harusnya mempertimbangkan.
Semakin cepat aplikasi atau website kita,
ya semakin banyak mungkin orang yang suka,
atau semakin berpengaruh ke revenue juga, ujung-ujungnya, gitu kan.
Website kita bagus, search rate-nya bagus.
Kalau lambat, jangan di tinggalkan.
Iya, bounce rate-nya tinggi, ya kan.
Jadi itu secara tidak langsung berpengaruh kepada gaji kita.
Kalau dilihat secara ini ya, secara garis besar, gitu kan.
Kalau perusahaan misalnya dapat keuntungannya dari website.
Kalau website-nya cepat, user-nya senang, user-nya akan bayar.
Kita dapat gaji, gitu kan.
Atau user banyak melihat iklan, ya kan?
Ya, banyak melihat iklan juga sama.
Eh, salah juga loh.
Makin banyak iklan, bukan berarti makin banyak revenue loh.
Oh, masa?
Iya, banyak user.
Oh, banyak user, yes.
Karena ada ad impression juga ada.
Terus user yang datang, besok datang lagi, besok buka lagi.
Karena dia senang, experience-nya enak.
Meskipun dia, iya.
Gak terganggu.
Meskipun banyak iklan, tapi KLS-nya bagus, gitu kan.
Yang ga usah banyak lah, ada iklan.
Tapi, ada iklan, tapi gak terlalu ganggu.
Iya, tidak mengganggu.
Dia dapat visualnya, dapat informasi yang berguna.
Atau apalah, dia dapat pengetahuan dari website kita.
Ada iklannya tak dikit, gak terlalu ganggu.
Ya, besok dia buka lagi, besoknya dia buka lagi.
Ya, kan sebenarnya itu tipis-tipis.
Gak kayak main game di mobile ya.
Begitu kalah gitu muncul iklan.
Tunggu 15 detik, 20 detik, apa-apa sih.
Itu mau di premium kali?
Enggak, ya intinya experience kayak gitu banyak di mobile.
Nggak enak banget.
Jangan sampai kejadian kayak pengalaman Eka tadi ya.
Mau beli tiket, malah pencet reset.
Masih di tahun 2023 ini, masih ada tombol reset
di form pembelian, itu juga udah aneh sih.
Iya, coba bayangkan kalau ada...
Nggak jadi di tutupan, ya kan?
Iya, kalau ada aplikasi kompetitor,
pasti Eka akan berpindah ke kompetitor yang lain.
Iya, kan?
Jadi itu sangat berpengaruh.
Tergantung harga.
Tergantung ada diskon atau nggak.
Kalau harga sama mungkin mau pindah,
tapi kalau harganya lebih mahal.
Reset nggak apa-apa aja, ulang lagi.
Tiket Coldplay, usitusnya lambat aja,
ditungguin tuh, direfres-refres terus tuh.
Ya, itulah namanya tiket war.
Kalau nggak, nggak ada warnya, nggak seru.
Nah, itu udah di luar mana, web tip.
Oke, oke, oke.
Oke, kalau gitu, buat malam ini...
Eh betul, ini link terakhir dulu.
Oh, terakhir, penutup, penutup.
Yang mau belajar, ya?
Yang mau belajar, penasaran.
Yang mau belajar bisa ke...
Yang mau barengan sama saya di GDE Performance,
belajar banyak ini.
Semoga ada.
Karena web capability ada dua nih.
Ya, performance sama gue doang.
CSS belum ada juga ya?
Ada yang CSS lah, biar ramai.
Eh, masih ada nggak sih?
Pas gue...
Ada dia.
Jadi kalau mau belajar,
ke web.dev/learn -core -web -fighters.
Nanti kita taruh di...
Apa? Di deskripsi ya.
Show notes.
Oke, mungkin itu aja.
Pesan terakhir dari kita.
Silahkan belajar web fighters
kalau teman-teman yang tertarik.
Siapa tahu beberapa bulan lagi
kita jadi tidak trio web-web,
tapi jadi berempat, ya?
Trio kuat-kuat.
Trio kuat-kuat.
Jadi apa?
Bisnis konsultasi kita jadi lebih berkembang lagi,
karena...
Bisnis konsultasi kuat-kuat.
Oke, kalau gitu terima kasih banyak
buat teman-teman yang sudah nonton,
yang sudah meramaikan.
Kita ketemu lagi selasa depan.
Nah, selasa depan ada...
Ada bintang tamu.
Ada bintang tamu.
Kita udah sempat obrolin
beberapa episode yang lalu.
Nanti tungguin aja.
Minggu depan kehadirannya Beliau.
Kita akan ngobrol bareng-bareng.
Jadi kita berempat minggu depan.
Oke, terima kasih.
Selamat malam. Sampai jumpa.
Wow.
Eka nya ngefreeze ternyata.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb ----------------------------------------------------------------------------------- Bergabung menjadi anggota elit di kanal ini: https://www.youtube.com/channel/UCHhAlFGFCGgIusQkQIqJLYw/join Donasi dapat meningkatkan kualitas kanal ini: 💰 https://karyakarsa.com/rizafahmi/tip 💸 https://sawer Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
26 Agu 2026
Modern Web UI
Episode ini berangkat dari satu keluhan yang sangat spesifik: web UI jadi berantakan begitu fitur LLM ditempelkan ke apl...
17 Nov 2022
Ngobrolin Web Episode Perdana
Episode perdana Ngobrolin WEB, dibuka dengan perkenalan tiga pembawa acaranya: Riza, Eka, dan Ivan. Formatnya sengaja di...
15 Jul 2026
Optimasi JavaScript
Episode ini membedah teknik optimasi JavaScript, dimulai dari prinsip paling mendasar: avoid work. Cara paling efektif m...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .