Ngobrolin Performa CLS feat Jessica Cecilia
Ringkasan Episode
Bantu KoreksiEpisode ini kedatangan Jessica Cecilia, front-end engineer di Tokopedia, dan sebagian awalnya berisi cerita di balik layar: bahwa fitur sekecil membagikan tautan produk pun punya timnya sendiri, bahwa stack hariannya React dan TypeScript, dan bahwa legacy JavaScript beserta class component-nya masih menyisakan gaya penulisan yang sulit dimusnahkan. Motivasinya mulai berbagi juga menarik — sebagai alumni Bangkit dan Women Developer Academy ia merasakan sendiri jurang antara apa yang diajarkan di kuliah dan apa yang dibutuhkan di dunia kerja, lalu ingin menjadi orang yang menjembatani keduanya. Topik utamanya CLS atau Cumulative Layout Shift, salah satu dari tiga Core Web Vitals dan yang paling menjengkelkan: halaman yang isinya melompat justru saat kita hendak menekan sesuatu. Diawali penyegaran soal mengapa Google merumuskan metrik semacam ini — karena tanpa angka, penilaian cepat atau lambat cuma jadi perasaan — dan bagaimana setiap metrik lama selalu berakhir diakali sampai diganti: FCP dulu dicurangi dengan loading spinner di shell HTML lalu digantikan LCP, dan FID sebentar lagi digantikan INP. Bagian praktisnya membagi sumber masalahnya jadi dua. Untuk elemen yang punya kotak — gambar, video, iklan — kuncinya aspect-ratio CSS, sehingga tempatnya sudah dipesan sebelum isinya datang. Yang lebih rumit adalah teks yang panjangnya tidak bisa ditebak karena datang dari API: solusinya line-clamp atau text-overflow ellipsis, yang kini sudah jadi standar CSS dan tersedia sebagai kelas di Tailwind, sehingga tinggi tempatnya tetap sama entah teksnya pendek atau panjang. Font juga jadi biang CLS, dan diakali lewat pencocokan fallback di Fontaine, properti size-adjust, ascent-override, dan descent-override, atau font matcher di meowni.ca. Iklan pihak ketiga disebut kasus tersulit karena isinya tidak diketahui. Ditutup dengan Layout Instability API untuk mengukur pergeseran secara terprogram, dan pengakuan jujur bahwa perbaikan performa di Tokopedia dipisahkan dari pengembangan fitur lalu dipantau lewat Google Search Console dan performance budget Lighthouse CI.
Poin-poin Utama
- •Jessica Cecilia bercerita bahwa di Tokopedia fitur sekecil membagikan tautan produk pun punya timnya sendiri, dengan React dan TypeScript sebagai stack hariannya di atas legacy JavaScript yang masih banyak
- •Core Web Vitals dirumuskan Google karena tanpa angka penilaian cepat atau lambat cuma jadi perasaan, dan setiap metrik lama selalu berakhir diakali lalu diganti — FCP dicurangi dengan loading spinner sampai digantikan LCP, kini FID digantikan INP
- •Untuk elemen yang punya kotak seperti gambar, video, dan iklan, kuncinya aspect-ratio CSS sehingga tempatnya sudah dipesan sebelum isinya datang
- •Untuk teks dinamis dari API, line-clamp dan text-overflow ellipsis menjaga tinggi tempatnya tetap sama — sudah jadi standar CSS dan tersedia sebagai kelas Tailwind, jadi ikut responsif tanpa JavaScript
- •Font jadi biang CLS karena fallback dan web font punya lebar serta line height berbeda; diakali lewat Fontaine, properti size-adjust, ascent-override dan descent-override, atau font matcher di meowni.ca
- •Iklan pihak ketiga adalah kasus tersulit karena isinya tidak diketahui, tidak seperti gambar yang setidaknya bisa ditanyakan ukurannya
- •Layout Instability API mengukur pergeseran secara terprogram dan lebih granular daripada skor CLS-nya, sementara pemantauan rutin memakai Google Search Console dan performance budget Lighthouse CI di alur integrasi
Hai, hai, hai.
- Hello. - Selamat malam.
Halo, selamat hari Selasa.
Seperti biasa.
Hari Selasa adalah waktunya kita untuk ngobrolin.
Ngobrolin web.
Iya, dan malam hari ini, anggotanya sisa kita berdua.
Ada Eka, ada Riza, tapi tenang aja.
Temen-temen, nggak usah takut karena kita akan mendatangkan
narasumber yang khusus, special malam hari ini.
Yang baru habis pulang dari Makassar, ya.
Dito pasti tahu ya siapa ya.
Kalau halo di Makassar apa bahasa ininya, bahasa daerahnya?
- Sapaan. - Iya, bahasa sapaannya, boleh tahu dong.
Kalau Audi juga, dari Surabaya apa kalau halo?
Kita pengen tahu, soalnya selama ini opening kita itu selalu halo-halo,
kalau nggak hai, kemarin aja baru kita tambahin yang lain.
Pengen tahu juga sekalian.
Ya, malam hari ini langsung aja kita panggilkan narasumber kita
yang kemarin baru pulang dari Makassar.
Ada Jessica Cecilia, halo.
- Halo. - Halo.
Selamat datang di Ngobrol Inweb.
- Gimana kabarnya? - Debut.
- Masih di kantor sekarang. - Oh, masih di kantor ya?
- Iya, memanfaatkan. - Bapak memanfaatkan fasilitas kantor ya?
- Bagus, bagus, bagus. - Iya.
Boleh, mungkin buat temen-temen yang belum familiar,
mungkin boleh kenalan singkat lah siapa sosok Jessica ini.
Oke, ya mungkin ada yang belum pernah lihat, ada wajah baru, ya.
Lihat transkrip lengkap (711 segmen lagi)
Halo, namaku Jessica Cecilia Budianto, dan ini pertama kali memang aku debut di Ngobrol Inweb.
Cuman sebelumnya aku pernah, ya mungkin ada yang udah pernah lihat aku di GDG
waktu aku jadi speaker di Defok atau enggak di Bogor,
pernah di Bandung juga, dan yang kemarin terakhir baru di Makassar.
Dan biasanya memang aku bawa entopik web di sana.
Oh, kalau di Defok itu workshop ya, workshop paski ya kemarin ya?
- Benar, benar. - Wah, seru tuh.
- Ya, akhirnya kita ketemu langsung juga itu, Mas, kan? - Iya.
Pertama kali kita ketemu secara offline ya, sebelumnya kita ketemunya online ya.
Iya, sama Mbak Eka juga ini baru pertama kali beneran kenalan di sini.
Baru kenalan di online, mudah-mudahan nanti bisa ketemu langsung ya offline.
Wah, ini ada Adib nih, pasti kenal nih, satu kantor ya.
- Ya, jadinya sebelahan, Mas. - Oh, sebelahan.
- Seru datang aja, seru datang di sini, jadi bareng pat, gitu. - Iya, ya.
- Sayangnya juga. - Sayangnya juga.
Oke, oke, nah boleh cerita dong kantornya di mana, kerja di mana,
terus mungkin bisa apa, share-share sedikit pekerjaan sehari-harinya, apa, ngertiain apa?
- Oh iya, malah dari tadi belum di-mention ya. - Belum, belum.
Iya, jadi, iya parah, parah emang.
Jadi, aku front-end engineer di Tokopedia, dan ini udah tahun ke dua setengah aku di sini.
- Oke. - Ya, mulai merasa mulai jadi fossil saya di sini ya.
- Hah, dua setengah tahun jadi fossil? - Biasa, biasa, karena udah agak
fresh-grade lagi, jadi ngerasanya udah mulai jadi fossil nih aku nih, kayak gitu.
Terus, keseharian sih, sekarang aku di bagian share ya, jadi di bagian kalau kalian di Tokopedia,
ini mau dikirimin ke, ya dikirimin ke keluarga, temen, pacar atau sesuatu,
biasanya kan ada itu, ada link si produknya, terus kalau, ya nanti kebuka gitu, nah itu aku yang di bagian situ sih.
Jadi, masing-masing fitur, subfitur pun ada itunya sendiri ya, ada timnya sendiri.
Iya, menarik kan, karena kita pikirnya kadang-kadang Tokopedia ya, home, ya home, home, terus,
terus apalagi ya, kayaknya fiturnya bingung juga nih timnya, berbagainya gimana, padahal,
supaya kecil-kecil kayak gitu pun ada, ya bisa jadi tim-tim sendiri, gitu.
Banyak ya, ada search, ada mobile web, ada mobile app ya, ada yang tadi apa, link juga.
Shopping card, berarti shopping card sendiri, wishlist sendiri enggak?
Wishlist bareng card sih.
Oke, belum lagi aplikasi-aplikasi internal ya?
Ya betul banget, yang buat ads, buat ini, analytics, ya itu kan yang enggak kelihatan mata itu,
yang internal, ya internal kira-kira apa, ternyata, wah justru itu motor di belakangnya sih.
Oke, oke, terus mungkin boleh dibocorkan sedikit teknologi yang digunakan sehari-hari apa di Tokopedia?
Teknologi sehari-hari kita pakenya di front-end ya, kita pakenya react typescript sih.
Hmm, react typescript. Oh, berarti sehari-hari udah, itu ya, hatam ya, typescript ya?
Ya, gitu lah, dari asalnya masih JS-JS, sekarang jadi, ya sedikit lebih OOP.
Masih ada nggak sih legacy code JavaScript?
Oh jelas, masih banyak dong.
Oh masih banyak ya, oh kirain udah full migrasi belum ya?
Yang kelas komponen juga tetap ada-ada aja pasti.
Ya, dan yang kayak gitu kan yang susah dipusnahkan kan.
Terus itu diganti tiba-tiba di sana ada yang rontok.
Ya bener banget.
Kejadian gitu ya.
Wow, udah pasti sih, itu kan, apalagi ganti dari asalnya komponen didmound, ganti pakai side effect, wah duar aja udah itu.
Nah, terus cerita sedikit juga tentang perjalanan kok, sekarang jadi lebih sering suka sharing itu awalnya dari mana sih?
Dari kegiatan apa?
Hmm, jujur sih, ini awal-awalnya banget sebenarnya gara-gara, jadi kan aku lulusan bangkit juga, jadi aku lulusan bangkit angkatan pertama.
Dan ceritanya kan, ya aku yang masuk Tokopedia nih, jadi testimoni aku itu sempat diliput juga sama Google masuk, ya masuk artikel juga.
Di situ bisa dibilang mungkin pertama kali aku istilahnya speaker secara ga langsung ya.
Go public.
Ya, langkah pertama gue jadi influencer.
Iya, dan kebetulan di internal juga mungkin karena aku yang kebanyakan ngomong kayak gini, jadi sering dijadikan MC juga sebenarnya di internal kayak gitu.
Nah, dari situ tuh mulai jadi kayak, mungkin kayaknya karena wah ini cewek, apalagi di dunia teknologi, terus kebanyakan ngomong, ceria kayak gini, jadi kayaknya mungkin eye catching.
Nah, itulah mungkin di situ itu yang bisa bikin aku masuk dalam dunia per-speakeran sih.
Cuman dari aku sendiri sih, motivasi aku pengen jadi speaker itu as simple as, karena waktu aku dulu kuliah itu ga ada kan kayak, dulu mungkin jaman aku dulu kuliah ga ada ya.
Kayak komunitas yang JDG gitu di kampus aku itu ga aktif, JDN-nya, jadi.
Kampus apa?
Eee, ITHB.
ITHB, itu apa?
Bandung.
Oh, Bandung.
Harapan bangsa di Bandung.
Bukan ITB.
Kita ada harapan.
Ada harapan ke ITB gitu.
Iya, itu bedanya kita.
Oke.
Nah, karena di kampus itu ga ada kan kayak GDE, GDE-nya ga aktif, terus kayak.
GDSC maksudnya mungkin.
Iya, GDSC, GDSC-nya ga aktif.
Dulu tuh kayak, ya kuliah istilahnya belajar tech itu dari kuliah, dan disitu tuh kayak, hmm, ini kayak, ya setahunya ya teori doang, prakteknya gimana, terus kayak, jadi kayak ada gap kan antara dunia kerja dan dunia kuliah gitu.
Dan disitu tuh kayak mikir, seandainya ada gitu, orang yang mau dari dunia kuliah, eh, dari dunia kerja, yang mau nge-bridging ke dunia kuliah, kayak gitu.
Biar ga terlalu ketinggian bahasanya, tapi bisa relatable sama anak kuliah.
Nah, aku kayak, aku mau jadi orang itu sih.
Itu keinginan aku dari awal dan mungkin sampai sekarang juga.
Wah, menarik sekali ya ini-nya.
Misinya ya, misinya. Karena ngalamin, ngalamin sendiri ya.
Bener banget.
Tapi dulu lulus kuliah, udah bisa ngoading kan?
Udah sih, udah-udah.
Kalau ga bisa ngoading kayaknya langsung disempil sama dosen, sama kadep langsung disempil.
Terus ikutan ini juga kan, kalo ga salah apa, Women Tech Academy, WTA?
Women Developer Academy.
Oh iya, Women Developer Academy.
Ya ternyata aku angkatan terakhir, guys. Aku baru tau kemarin.
Oh, udah ada lagi ya?
Nggak ada lagi sekarang.
Angkatan terakhir.
Jadi kalau saya ada 4 angkatan, dan aku angkatan terakhir, gitu.
Jadi kayak, wow, ga nyangka. Hoki banget, gitu.
Ya, dan bergara WTA ini sih yang bikin aku kenal sama Mas Danang.
Itu pertama kali akhirnya jadi debut di Depok.
Tahun berapa tuh, debut di Depok?
Tahun lalu. Belum, belum.
Masih baru ya?
Nggak, masih baru kok. Masih baby.
Masih baru, masih baby.
Iya, iya, iya. Terus sekarang udah mulai jalan-jalan.
Keling-keling sedikit-sedikit ya.
Iya, puji Tuhan ya.
Ada alumni Bangkit 2022.
Wow.
Audi.
Ini Audi yang Bangkit 2022 atau Jessica yang 2022?
Ya, pasti dari Audi-nya sih.
Kalau aku, berarti alumni Bangkit 2020.
2020.
Nah, buat yang nanyain Irvan kemana, Irvan lagi dalam perjalanan menuju ke Kampung Halaman.
Dari Kampung Halaman ke Sibolga.
Iya, pokoknya itu lagi ada urusan keluarga.
Ini kedua kalinya harusnya ketemu sama kak Irvan, tapi gagal.
Jessica pengen banget ketemu sama Irvan ya.
Iya, waktu itu udah satu event bareng, eh tiba-tiba dia, ya, kena Covid.
Covid? Iya, yang di Bandung tahun lalu.
Iya, benar.
Batal.
Iya, masih misteri ya.
Sosok Irvan ini masih misteri ya buat Jessica ya.
Oke, nah, berhubung malam ini, Irvan kan senang tuh dia ngomongin tentang performance ya.
Kita juga akan bahas tentang performancenya sama Jessica juga.
Kita malam ini akan ngomongin khususnya tentang CLS atau Cumulative Layout Shift.
Yang biasanya kalau ada website, misalkan ada apa, layoutnya tiba-tiba bergeser sedikit.
Nah, itu lah dia layout shiftnya yang berarti kurang bagus gitu ya.
Iya.
Kita akan bahas itu sedikit demi sedikit, jadi si apa, si CLS ini bagian dari Core Web Vitals sebenarnya.
Nah, buat refreshing aja temen-temen, mungkin ada yang belum tahu, Core Web Vitals ini adalah inisiatif dari Google.
Yang tujuannya adalah untuk delivering a great user experience.
Nah, user experience itu kan abstrak ya, sulit di, patokannya apa sih? Cepet.
Nah, yang cepet tuh apa? Respondary servernya atau apa? Walaupun respondary server cepet misalnya,
tapi kalau layarnya putih doang nunggu di parsing semua kan bagi user dari perspektif user, itu nggak kerasa cepet.
Jadi, Google merumuskan matrik-matrik khusus yang bisa dianggap bisa mewakili atau bisa dijadiin patokan user experience yang baik.
Iya, dan ini menarik juga sih, karena kan kalau kita sandainya kita ditanya nih, apa ini website bagus atau nggak, kita bilangnya ya pokoknya loadnya lama nih, atau nggak ya sinyalnya jelek, atau ya pokoknya itu selalu tentang internet ya kalau di Indonesia kan.
Nah, ya tapi Google tuh bisa kerennya sih bisa spesifik sih apa yang kayak faktor apa gitu dari istilahnya slow network ini dirumuskan jadi gimana cara mengukurnya kayak gitu itu yang keren sih kalau nggak salah.
Jadi kan biasanya sesuatu yang ingin kita improve, ingin kita perbaiki itu harus diukur dulu kan apa nilai sebelumnya, nilai saat ini, terus setelah di improve, setelah diperbaiki apakah menjadi lebih baik atau malah jadi lebih buruk gitu.
Kalau nggak ada pengukurnya, measure-nya, ya jadi apa ya tadi, jadi objektif, ya jadi subjektif apa objektif ya? / Subjektif. / Subjektif.
- Ini kayaknya cepat. / Kayaknya cepat atau kayaknya lambat kan sulit dijadiin patokan. Menurut kita mengkuantifikasikan ya, jadiin kuantitatif dijadiin harus berapa detik atau CLS ini kalau konteksnya CLS ada yang geser, gesernya harus berapa persen, 0,5, berapa gesernya.
Jadi ini upaya merunguskan metric sebagai patokan secara kuantitatif ya, berarti. / Ya. Kita udah sempat bahas juga di episode beberapa episode lapan. / Kita punya episode Core Web Vitals.
Iya, dan ini cuma refreshing aja, yes. Salah satu yang menarik dari Core Web Vitals adalah ukurannya itu merefleksikan experience di user experience ya, jadi user centrik yang kita lihat, yang kita rasakan gitu.
Bukan semata-mata kayak misalkan analytics, misalkan kayak Google Analytics itu ukurannya adalah jumlah user gitu kan, yang nggak kita rasa sebagai user, tapi kalau ini sesuatu yang bisa kita lihat, bisa kita rasakan, oh ini kok kurang bagus ya.
Tapi kurang bagus itu berapa, seberapa kurang bagusnya, seberapa bagusnya gitu. Ada nilainya lah gitu, yang bisa kita jadikan patokan.
Nah, sedangkan. / Ini bisa berubah ya, itu. / Bisa berubah. / Betul. / Kayak dulu, sekian tahun lalu kan bukan LCP tuh, dulu ada first content full pay. / Ya, first content full pay.
Diakalin kan developer, LCP bagus, atau pakai logo di index ATML, di static shell-nya itu dikasih loader atau dikasih logo atau apalah, biar dapet FCP cepat. Tapi kan lama-lama itu kan nggak merefleksikan yang dialamin sama user.
Jadi apa, itu bisa di-adjust sebelum. / Akhirnya tetap rasanya itu website-nya loading-nya lama, sama aja. / Sama-sama, karena diakalin. Terus angka-angkanya juga misalnya kayak 100 millisecond,
atau berapa second lah, berapa detik, itu ke depannya ya bisa aja berubah. Karena misalnya 3 tahun lalu itu kayak di Indonesia kan masih banyak ya orang pakai 3G.
Nah, terus tahun ini kayaknya 3G udah dihapuskan ya, dimatiin ya. / Oh iya, wow. / Kurang tahu sih.
Konon, iya, jadi sama provider seluler itu kayaknya 3G udah di-remove, kan pelan-pelan speed-nya nambah. / Sudah ada 5G.
Jadi ke depannya bisa aja itu angkanya berubah atau metrics-nya yang berubah. / Wah 3G aja dimusnahin, apalagi Edge ya. / Edge itu 2,5G ya? / Iya.
Yang terbaru BTW sekarang FID mau di ganti nih, mulai tahun depan ganti jadi INP ya. / INP, iya betul. Kita juga udah bahas sebenarnya di beberapa episode yang lalu.
Iya gak apa-apa, buat refreshing aja soalnya ini butuh ya. Nah, ada 3 ya, yang saat ini ya ada 3 yaitu Largest Contentful Pane.
Ini menghitung loading performance, seberapa cepat loading dari web kita sampai, apa ya, Largest Contentful berarti sesuatu yang terlihat di... / Paling dominan. / Paling dominan.
Apakah itu header atau image gitu ya? / Lighthouse punya algoritma sendiri buat nentukan apa yang dianggap sebagai LCP ya.
Biasanya entah gambar apa main header atau judul atau semacamnya lah, pokoknya yang dianggap paling dominan di above the fold.
Di layar yang tampil. / Iya itu, catchnya itu di bagian viewportnya sih. Jadi sebenarnya kalau sana gak ditampilin ya udah, gak dihitung.
Iya kalau di bawah banget ya itu gak pengaruh kan, karena kita lihat ini dari perspektif user. User belum nge-scroll ke bawah, belum muncul ya gak apa-apa. / Benar.
Oke kemudian yang kedua ada FID, First Input Delay, itu adalah mengukur interaktivitas. Jadi misalkan seberapa cepat website kita bisa di-scroll.
User bisa nge-click, bisa scroll, bisa ngapa-ngapain lah gitu. Kalau ada form bisa diisi gitu ya, itu interaktivitas.
Jadi kita bisa tahu bahwa, iya betul. / Iya, maksensi karena kan ini first-first doang ya. Kalau misalkan sudah first-nya jadi lama, akhirnya kan tutup aja user experience-nya memburuk ya kalau gitu.
Iya memburuk, betul. / Ini lagi-lagi beda nilainya juga.
Mungkin first-input delay-nya mungkin cepat, cuma maksudnya tetap aja banyak long-task-nya, ya mungkin tetap jelek. Jadi kalau interaction to next-pin kelihatannya terus-menerus ya.
Iya, oh iya soalnya bisa diakalin ya kayak FCP tadi ya. / Betul. Lama-lama juga orang bisa ngakalin sih, makanya dia ini evolusi terus kan, ber evolusi terus.
Sama aja kayak kita main SEO kan, ada teknik ini, terus dia abuse, terus abis itu ganti lagi algoritma-nya. / Iya, kalau yang jaman dulu banget, kita ingat gak sih yang pas keywords misalnya sepatu, shoes, sneakers,
jadi itu terus pakai phone ukurannya 1 pixel atau pakai misalnya background-nya putih nih. / Iya jadi putih juga.
Jadi pakai warna putih juga. Itu pertama kali buat belajar moding itu lagi nge-print tuh kayak gitu. / Oh iya, SEO gitu ya. Kalau sekarang udah gak bisa ditipu ya.
Sekarang makin canggih ya alat si crawler-nya ya. Dan terakhir yang akan kita bahas malam ini ya itu tentang kumulatif layout shift.
Ini mengukur stabilitas visual, jadi tampilannya tidak banyak berubah di awal, jadi dijanjikan sekian, dapatnya sekian, gak dijanjikan segini tiba-tiba jadi panjang gitu ya.
Ada banyak faktor, kita akan bahas mungkin malam ini agak lebih dalam sedikit dibandingkan sebelum-sebelumnya.
Jadi CLS ini, apa yang membuat CLS ini nilainya bagus? Kira-kira apa aja ini faktornya? Yang pasti ini ya page load ya? / Iya page load sih pasti.
Terus konsistensi sih sebenarnya, konsistensi posisinya gitu. / Iya yang paling low hanging fruit-nya, kalau ada image yang cukup besar,
kita tahu ukuran image-nya langsung dipatokin aja, height sama width, jadi udah ada kotaknya, udah ada placeholder-nya,
jadi image-nya itu gak mulai dari yang kecil terus membesar, jadi kita udah tahu tinggi dan panjangnya image itu seberapa.
Jadi gak shifting lah ini-nya ya, si layout-nya kira-kira itu. Itu untuk, itu baru image ya, ada font, ada macem-macem gitu ya, ada banyak.
Iya dan itu pikir-pikir jadi agak-agak drawbacks kayaknya kalau seandainya, tadi kan image, kalau misalkan kayak div gitu di width height,
ya jadinya dia agak kebatas juga ya, kayak gitu, nah itu mungkin mulai agak susah sih kalau udah kayak div gitu kan.
Nah kan berarti solusinya itu tuh aspek rasio kan, kayaknya di link-nya Jessica tadi udah ada.
Jadi kalau kelihatannya sebetulnya sumber CLS itu, sumber issue CLS kan sebenarnya bisa direcap sebagai pertama mungkin itu tadi punya block element, block element itu kan bisa image lah,
bisa apalah container video atau ads atau apapun yang punya ada kotak lah intinya.
Nah itu kuncinya kan asal kita bisa dapetin, kita tahu dan itu gak berubah-berubah rasio-nya, itu container-nya bisa dipatok pakai CSS aspek rasio.
Jadi walaupun belum loading kan kita bisa pakai skeleton ya, nanti tinggal di-replace aja entah itu image atau apapun, itu sih sebenarnya kunciannya aspek rasio.
Nah ada masalah lagi nih tapi kedua element inline kan misalnya text, terutama kalau text-nya gak static,
maksudnya mungkin dari user submitted atau bisa berubah-ubah, nah itu pusing kan tuh.
Jadi misalnya contohnya kadang hari ini feature post-nya 3 baris text, besok bisa 2 baris, nah kita bikin.
Tapi itu mungkin harus manggil API line dulu, jadi harus loading spinner atau skeleton dulu.
Nah kita kan gak tahu, gak bisa bikin skeleton-nya, nah mungkin itu bisa diakalin dengan CSS juga.
Jadi kalau visual kita larinya kan banyak ke CSS ya, itu bisa pakai line clamp, bisa pakai text truncate, ellipsis, ada tuh link-nya yang di CSS.
Kalau agak-agak illegal, tidak menolong masalah, itu ya, text-nya jangan direp-text, dia hajarin aja tak berakhir.
Intinya kan biar kita punya, kita bisa skeleton yang ukurannya sama, setelah dialogin dia gak ngedorong sisanya ke bawah.
Nah kalau text itu bisa diakalin pakai line clamp itu kalau lebih dari 1 baris, misalnya kita punya entah text-nya pendek atau panjang, kita sediain tempat buat 2 baris text, misalnya itu yang bawah.
Kalau yang atas itu yang text ellipsis itu truncate cuma 1 baris doang, jadi kita punya sediain tempat buat 1 baris.
Jadi ngurung ke bawah ya, dipotong gitu ya, ditambahin titik-titik.
Biar enggak, ini kan terutama buat data dynamics sih yang kita belum tahu, kalau kita udah tahu misalnya server render udah waktu ada sih gak masalah ya, kan karena dia gak bergerak lagi.
Tapi kalau kita belum tahu, misalnya datanya dipanggil di render client-side, kan kita kedu pasang placeholder, nah terutama ini berguna buat kayak gitu sih.
Setelah datanya muncul, nggak bakal ngedorong bawahnya, yang bikin channel S itu kan pas kalau text-nya udah ke loading ternyata panjang dan gak dibatasiin kontainernya kotaknya kayak gitu.
Setelah datanya muncul dia ngedorong sisanya ke bawah kan, nah itu sih kalau di pengalaman pribadi yang katal kayak gitu.
Yang cukup sering kejadian juga biasanya di situs-situs berita ya, atau agregator dan lain-lain yang biasanya ada iklan, dan iklannya juga belum tahu nih ukurannya seberapa.
Karena terparti kan dari orang luar kan, udah gitu mungkin bentuknya iframe lagi, kita gak tahu isinya apa, ukuran berapa, itu pasti pusing sekali ya gimana tuh cara mengakalinya ya.
Kalau image mungkin kita masih bisa tanya ukurannya berapa, atau aspek rasio-nya berapa.
Kalau ini text juga sekarang udah bisa pakai ellipsis seperti ini ya.
Ellipsis atau line-clamp.
Line-clamp, iya.
Disini siapa yang belum tahu ini apa, text overflow ellipsis, jadi harus bikin sendiri pakai di string ya.
Detailin aja jangan sendiri.
Iya pakai di string.
Tapi aku agak penasaran sih, itu kalau line-clamp itu kepengarungan responsif ya, tapi kalau kayak gitu ya.
Sofif, aman. Jadi CSS tanpa javascript, jadi kalau zaman dulu nih primitifnya kan kita ambil dulu viewport height-nya, terus kita hitung aja, mesti motong berapa karakter gitu, font-nya itu berapa pixel, terus kita hitung karakternya, muat apa, terus kita potong padding-nya gitu, muatnya berapa, ya pokoknya gitu lah pusing.
Sekarang sakti udah.
Sakti ya, luar biasa.
Canggih sih, cangih-canggih.
Karena ini udah standard CSS, udah masuk tailwind, jadi kalau yang pakai tailwind itu cuma kayak kelas namanya line-clamp 1, line-clamp 2, ya udah potong 2 baris.
Nah 2 barisnya itu ngikut, jadi kalau misalnya di apa, mobile, kecil, ya 2 barisnya mobile.
Kalau di desktop besar, ya 2 barisnya desktop.
Jadi dia udah.
Penarik-penarik.
Jadi intinya kita bisa pasang skeletone, playsoldernya tingginya kita udah tau, itu 2.
Tinggal dihitung aja kan, kalau 2 baris itu seberapa, udah intinya sih buat memudahkan playsolder.
Nah, kalau skeletone pada biasanya pakai laboratika atau bikin sendirika atau gimana?
Skeletone.
Kalau buat proyek sendiri sih biasanya bikin sendiri sih, memang pakai div aja.
Ya, tapi memang width sama height, ya kan harus tau ya.
Terus pakai warna abu-abu kayak gitu.
Sama sih bikin sendiri sekarang cepet, lagi-lagi tailwind itu udah ada animasi yang buat apa, gitu loh.
Yang kayak text mucil gitu ya?
Iya, iya sih.
Ya udah sih, saya pakai div aja, jangan lupa accessibility dipakai area hidden ya.
Biar yang pakai screen reader nggak bingung banyak.
Oh itu kebaca, oh kebaca di screen reader ya?
Kalau kosong, nah kalau kosong nggak tau sih.
Cuma ya kebiasaan aja sih kalau yang nggak make sense semantically ya di area hidden aja.
Kosong atau NBSP?
NBSP.
Itu nyeblin sih.
No breaking space.
Di screen reader NBSP bacanya apa ya?
Nggak tau ya?
Iya ya bener juga, pertanyaan bagus.
Kita nggak tau jawabannya, kapan-kapan kita bahas.
Kapan-kapan kita bikin edition screen reader.
Iya benar benar.
Nah kalau di Tokopedia sendiri ya, pernah ada kasus-kasus yang berhubungan dengan CLS nggak?
CLS mungkin sampai sekarang juga ini masih sesuatu ya.
Ini ya kayak kita berusaha improve over time sih.
Karena kan ya konten dinamiknya kan ya banyak ya.
Dan terus kayak walaupun kayak beberapa banner misalkan udah pasti ukuran-ukurannya.
Tapi kan kayak ya fiturnya Tokopedia luar biasa kompleks ya.
Jadi akhirnya tetap suka ada shifting-shiftingnya kayak gitu sih memang.
Ya memang secara umum untuk performance ya memang improving over the time ya.
Nggak mungkin bisa sekali kita tweak, habis itu udah lepas tangan udah selesai gitu nggak.
Jadi ini terus menerus ya dan di monitor terus ya.
Ya apalagi dengan si core titlesnya juga kan direvisi terus ya.
Akhirnya kita juga harus revisi lagi.
Ya harus itu ya harus tetap update-update dengan yang gini-gini ya.
Jadi biar tahu dan biar aware gitu ya.
Tapi ada sistemnya nggak sih?
Maksudnya di CI/CD lah atau pas lagi bikin pull request apa di cek?
Cek regression gitu ada nggak sistemnya kalau di update?
Kita biasanya misahin sih jadi kayak ya antara fitur development sama ini kan performance ya.
Performance kayak gini ya ini dibisain.
Soalnya kayaknya kalau tiap kali fitur development dipikirin kan overwhelming juga ya.
Jadi ya ada kayak terpisahnya sendiri sih yang kayak di monitor over time kayak gitu paling.
Tapi itu pakai apa? Mungkin bisa share?
Mungkin ini ya.
Kayak pakai hati atau apa?
Ya apa? Belosan detail sih makanya kisi-kisinya.
Jadi ini juga ada di link yang tadi ditunjukin sama Mas Riza deh.
Kayaknya soal pakai Google Search Console kayak gitu.
Itu kita pakai deh.
Yang ini ya? Bukan.
Iya ya Lighthouse ya.
Paling cepat buatnya itu kan Lighthouse ya tetap ya.
Ya Lighthouse juga ada CI-nya kan.
Udah pada tahu kan.
Ada CI-nya jadi bisa ditambahkan ke continuous integration.
Jadi ketika kita develop sesuatu, kita post sesuatu, nanti dia ngitung si Lighthouse-nya, nilainya bertambah berkurang.
Kita nge-set di JSON gitu apa semacam betasnya result-nya.
Ya biasanya development sih ya jalan dulu aja nanti efeknya baru ditikirkan kemudian.
Sama aja ya dimana-mana gitu ya.
Akhirnya sama kira-kira impact-nya kayaknya nggak terlalu parah ya jalan dulu aja.
Yang mana ini?
Layout Instability API, visual feedback.
Nah itu API yang menarik tuh si Layout Instability API.
Udah pernah pakai belum ya?
Layout Instability API, wah ini juga baru tahu nih ini.
Ini kita bisa pakai API-nya untuk mengukur CLS kan.
Jadi ini juga sediak tools-nya kan.
Untuk programatikali mengukur.
Jadi kan sebenarnya kalau di dev tools, di performance tab, ada tuh bisa nge-highlight pas dia geser.
Tapi kan itu harus visual kan, kita harus manuali perhatikan manteng itu.
Nah kalau ini, itu untuk ya itu automation atau programatikali cek lah.
Jadi intinya dia nge-cek elemennya, gesernya seberapa.
Yaitu ada value-value-nya.
Oh dia lebih specific ya dibandingin yang Corel Vitals API-nya sendiri malahan ya.
Kalau Corel Vitals kan ya as simple as score-score aja.
Kalau ini beneran lebih granular kayak gitu ya, menarik sih.
Betul.
Nah kan karena dia dapet score geser sekian persen, misalnya berapa kan, under the hood kan sebenarnya pakai ini.
Ini kayaknya Siobhan pernah jelasin juga deh sebelumnya, cuma lupa karena belum pernah pakai sebenarnya personally.
Nah ini ada yang minta ini nih, bocoran.
Lighthouse budget-nya berapa?
Tunggu, Lighthouse, Lighthouse bukannya free aja ya?
Bukan, budget untuk minimum berapa gitu.
Oh budget, oh maksudnya budget itu.
Nilainya, bukan duit.
Otomatis budget, mikirnya oh cost.
Kita disamain sih, kita ngikutin sama standarnya Corel Vitals yang disarankan Google ya.
Itu kan ada merah-merah kuning hijunya, kita konsisten sih sama kayak gitu.
Jadi kalau yang, kalau hijau itu dibiarin atau diimprove lagi atau tunggu sampai kuning baru diimprove?
Biasanya sih kita awasin juga sih kayak hijaunya hijau berapa, kalau misalkan ya udah cukup ya udah biarin dulu aja, karena kan ya itu sih.
Mungkin pengennya kan ya yang hijau pun diimprove, tapi ya balik lagi kita fitur banyak.
Yang kuningnya banyak juga, ya jadi prioritas lagi akhirnya, yang kuning duluan.
Oh, nah ini ngomongin budget ya, jadi Lighthouse itu juga ada performance budget-nya.
Kalau mau diset, misalkan di sini kita bisa pakai konfigurasinya dalam bentuk JSON seperti ini, timingsnya berapa budget-nya?
Nah, budget itu maksudnya milisecond.
Eh, milisecond loh, maksudnya 3000 second.
Ya, 3 second deh terus.
3 detik, ya ini 1 detik.
Ini budgetnya berarti 125 itu size-nya ya, ukuran berapa nih, 125 bytes?
Kilobytes.
Oh, ini bandel size-nya deh kayaknya ya.
Bandel size-nya ya?
Iya, bandel size.
Oh, oke.
Ada keterangannya itu di bawah.
Ini script, berarti java script kan?
Iya, iya.
Kenapa yang kita nebak-nebak ya?
Iya.
Oh, tapi keren banget ini sampai bandel size-nya maksudnya diukur juga ya di sini.
Karena ini buat disambungin ke ICD sih sebetulnya, ke session kita sendiri.
Inder kita pakai tool kayak husky, pas lagi mau...
Jadi nggak bisa nge-push ya?
Oh, iya.
Kalau di bawah standar.
Kalau mau boros, itu bisa di GitHub actions juga atau semacamnya.
Cuma itu nggak recommended kali ya.
Boros nggak sih?
Kan itu makan waktu di server-nya mereka.
Yes.
Kalau pakai Netlify, ada plugin-nya.
Ya itu juga sebenarnya boros sih, maksudnya kalau terlalu sering.
Jadi kita push, tapi kalau misalnya bisa aja dibikin fail kalau nggak menungguin budget itu.
Ingat banget tuh.
Jadi dulu pernah sama anak-anak React ID yang dulu pernah featuring di sini juga
kan bikin website yang buat...
Akan dulu warga bantu warga tuh jaman Covid.
Oh iya.
Nah, terus ada itunya pasang plugin itu, ya bagus.
Niatnya buat performance.
Cuma kan ya itu kan lagi derut ya, maksudnya ada info yang ada hal-hal update
yang sifatnya kayak harus banget sekarang, apa, secepat mungkin di-up.
Terus ya akhirnya kita bypass gitu maklum-maklum budget chasennya di modifikasi sendiri lah.
Budgetnya di naik-naikin terus ya biar pas.
Di naik-naikin.
Karena butuh apa harus deploy.
Jadi cuma kan sebetulnya itu sistem yang bagus sih.
Prevent regression dari awal.
Iya, iya.
Tapi ya itu sih mungkin, itu semacam standar-standar gitu juga di sini biasanya kayak ada.
Tapi biasanya kayak itu bukan yang jadi standar, jadi gak bisa, apa, gak bisa commit gitu.
Gak bisa commit gitu ya, gak bisa push gitu ya.
Iya, kita biasanya gak kebatasin gitu sih.
Karena kan ya itu ada kebutuhan dari produk.
Kalau produknya memang butuhnya gede, apadah iya tanya.
Akhirnya jadi memang harus naik-naikin budget juga kayak gitu.
Jadi biasanya sih ya naikin.
Kalau misalnya naikin budget, naikin dulu aja.
Tinggal nanti di review lagi apakah ini harus di minify gitu gimana.
Nah mungkin kayak gitu sih biasanya.
Nah ini Mas Didik ini kayaknya sudah menerapkan ini ya performance budget ya.
Kayaknya menarik nih buat topik kita bahas ya.
Performance budget ya.
Iya sih.
Kapan-kapan?
Iya, dicatat dulu ya.
Terima kasih.
Terima kasih.
Jadi saran topik baru nih.
Oke.
Kita bahas apa lagi nih?
Tentang CLS, lanjut lagi.
Phone, kita mau bahas phone.
Tadi kan tersukanya ada apa, container image dan sebagainya.
Ada text, ada budget.
Nah coba dijelasin kenapa phone bisa fatal buat CLS.
Bisa mengaktifkan masalah CLS.
Siapa yang coba?
Tolong dibantu.
Kenapa phone?
Oh iya ada di sini kan, ada di catatan kita kan.
Ada dong.
Jadi kan apa, web phone kan pas loading, nggak bisa langsung kan, harus dipanggil dulu.
Nah, dari phone back phone, phone default yang udah ada di device-nya user, terus pas apa, web phone-nya file, phone file-nya udah selesai loading kan diganti tuh.
Nah, itu bisa berpotensi mengakibatkan CLS.
Karena kan masing-masing phone ada lebarnya sendiri, terus apa sih, walaupun misalnya sama-sama line height-nya 1,5 kan tingginya juga bisa lain ya.
Nah, kalau misalnya kebetulan kita bedanya banyak, itu kan elemennya yang ke bawah bisa kedorong semua.
Jadi bisa bikin layout shift.
Ini kentonya ya.
Ada solving yang lebih gampang sih, makanya jangan pakai phone custom, pakai phone default.
Emang Tokopedia pakai phone default?
Kita pake phone default nggak ya? Kayaknya nggak juga deh, kita pakai phone custom. Eh, apa kita pake phone default?
Mari kita lihat.
Kita lihat.
Ayo kita cek. Coba DevTools.
Ayo.
Phone family.
Phone size?
Kanan-kanan, atas, di filter aja tuh, filter.
Phone family.
Open source? Oh, bukan dong.
Oh iya.
Bukan dong, nih.
Custom sih.
Berubah kan.
Custom.
Aslinya apa nih ya?
Tergantung ya, tergantung masing-masing OS-nya.
Ya, dan browser-nya.
Sayangnya custom ya, biar menjaga konsistensi, ada berbagai browser lagi-lagi.
Oh iya, bener.
Tadi itu solusi paling enak sih, udah font-nya sanserif lah, terserah.
Nah, cuma itu kan perspektif kita ya sebagai developer yang bikin estetika visual ya, budu amat lah, udah yang sanserif kan.
Yang penting kebaca, kan.
Nah, cuman realistically, orang product dan mungkin orang UI ya, atau orang visual, orang branding kan nggak bisa se...
Tidak bisa.
Terima lah.
Kan, soalnya itu bagian dari branding ya, apa?
Benar.
Oh iya, apalagi kalau ada, udah ada design system kan, pasti...
Iya, design system juga.
Yang semua ya.
Iya, terus kita buka di mobile, pakai Roboto.
Di sini pakai apa, beda lagi gitu ya.
Jadi bisa berubah desainnya dan tampilan dan apa ya, brandingnya juga bisa berubah jadinya, gara-gara font aja ya.
Iya, bener banget sih.
Terus jaga konsisten readability juga kali ya.
Iya, iya, iya.
Alasannya.
Cuman kan ada tricknya kan, kita udah sempat bahas juga.
Jadi ada satu tools yang bisa memberikan alternatif kalau misalkan kita pakai tadi misalkan apa, open source.
Itu font yang paling dekat secara bentuk dan ukuran itu apa gitu.
Jadi, kalau pun berbasifnya tidak terlalu besar gitu.
Ada kan, ada toolsnya ya.
Ada dong.
Ini mana dia?
Coba buka.
Di...
Meoni.ka, cari aja coba di...
Oh iya iya, Meoni.ka.
Terasa tadi udah dibuka.
Buka lagi deh.
Nah ini.
Oh, baru tahu ini ada website kayak gini.
Sebetulnya sih kalau ini tools untuk mempermudah aja sih.
Kalau kita pengen untuk mengkustom kayak line height sama kayak apa sih kerning dan lain-lain tuh ada.
Cuma ini buat common web font yang pakai Google Fonts misalnya.
Ya udah biar cepet.
Jadi bisa pakai settingan yang dari sini.
Oke, ini bisa ditulis ya?
Dropdown, kan?
Dropdown, gitu. Nah ini kan beda ya.
Ini bisa satu baris, ini dua baris ya.
Oh iya.
Jadi dia nanti carinya gimana tuh?
Oh, ini cuma melihat perbedaannya aja ya.
Nggak dikasih saran font yang mana ya.
Atau bisa dikecilin di sini supaya bisa sebaris.
Kayaknya itu deh di-compare di bawahnya.
Di sini ya, nah ini ya.
Oh wow.
Jadi kita bisa tahu kayaknya font line height-nya harusnya dikurangin gitu ya.
Atau ditambah supaya...
Ini harusnya dibikin satu view ini biar jadi kita nggak usah scroll.
Iya, kiri-kanan gitu ya.
Iya, kiri-kanan.
Jadi bagus tuh.
Nah, kurang lebih gitu lah.
Jadi kita bisa cari kayaknya font yang udah pasti ada di desktop.
Yang susah juga sih ya.
Kalau dibukanya di mobile, Georgia kayaknya nggak ada ya.
Nggak ada opsinya lagi ya?
Iya.
Iya, ini malah jadi ngomongin UX-nya ini kita.
Udah di-scroll-scroll.
Nah, kalau pengen customize sendiri ada ini CSS Size Adjust.
Coba buka.
CSS Size Adjust.
Oh, di-comment, oke.
Dari web dev ya.
Oh, web dev.
Nah, scroll aja ke bawah sampai ada bagian mitigating, CLS, blablabla.
Ya intinya kebayang, tapi kan mau saya biar apa?
Perbedaannya terlalu jauh.
Kita cuma butuh tinggi, kurang lebih lebarnya harus mirip.
Dan tingginya, spasinya juga harus mirip.
Nah, jadi kita kayak nyesuainya pakai itu.
Yang dimainin berarti line height gitu-gitu ya, bukan jenis font-nya ya?
Kalau jenis font kan belum tentu kita bisa ngontrol ya?
Belum tentu, iya.
Nah, terus ini nih ada package.
Ini sebenarnya dulu diposting sama event kalau nggak salah, Fontaine.
Ini juga tools untuk menyesuaikan fallback font dengan font yang kita loading.
Iya, jadi ini font placeholder ya.
Jadi font-nya muncul ini dulu, begitu font yang mau kita pakai sudah berhasil di-download,
baru keganti kan secara otomatis.
Oh, berarti ini font-nya font custom juga ya?
Enggak, dia pakai system font.
Oh, dia punya list of system font, nah itu yang bisa di...
Tapi ini secara programatik ya, jadi di-coding ya, pakai di-codingan kita, kita tambahin tools ini atau library ini.
Itu outputnya adalah font face dengan custom kayak settingan itu tadi apa, sizing atau line height atau semacamnya lah pokoknya.
Tapi udah otomatis ya, dicariin sama dia ya?
Iya, biar sesuai, nah itu contohnya tuh outputnya.
Nah, jadi asen override, asen sama desain itu kayak dia nyesuaikan kayak spasi lah sebenarnya, spasi horizontal atau vertical sih,
yang dari atas ke bawah, ya gitu pokoknya.
Kayak spasi atasnya disesuaikan di fine-tune lah, di tweaking berapa persen,
terus spasinya yang di bawah berapa persen, biar secara dimensi tuh makan tempatnya sama kayak font yang mau kita pakai.
Oke.
Oh, menarik sih.
Oh, berarti tapi dari CSS sendiri memang ada ya, asen override, desain override.
Ini semua nggak ada, kalau kita iseng banget pengen itu sendiri juga boleh.
Iya, bener banget, sebenarnya pengen milih sendiri.
Iya, sebenarnya bisa sih kalau gitu.
Ini property ini juga baru lihat nih.
Iya, kemarin waktu dilihatin event juga udah sih, cuman baru nyadar ada ya ternyata ini ya.
Iya, kayaknya banyak sih itu property CSS yang lusukan dan nggak apa-apa.
Iya, bener, ada berapa banyak itu, yang kita tahu mungkin sebagian kecilnya saja.
Iya, udah kayak lari kan.
Kalau aku tuh dulu nemu ini gara-gara dulu kan next.js, kalau sekarang kan udah ada yang font otomatis di fine-tune lah, mirip-mirip kayak gitu.
Dulu belum ada, terus sebel aja sih gemes di personal project, cuman gemes, sebenarnya performance-nya udah oke semua,
karena sebenarnya nggak ada isinya, cuma ngetes doang, cuma ngetes layout, cuma ngetes UI simple, cuman satu itu doang,
CLS, jelek, cuma gara-gara itu doang, jadi gemes nyari dan emang nemu property-property CSS itu.
Cuman in real life kan nggak seselow itu ya kalau dikerjaan di production app, task lain yang feature-related masih banyak,
jadi nggak pernah sempet memakai itu.
Nah, terus dulu Ivan ngasih tahu ada tools buat meng-automate itu dan ngitung sampai ke exact persen-persennya.
Iya, itu persenannya sampai angkanya panjang banget gitu lagi.
Karena dia kan masuk ke build tool ya, dia masuk ke webpack atau feed, ya dia ngerender beneran sih.
Dia ngerender dengan font yang lama, dia ngerender dengan font yang baru.
Ya udah, bandingin aja kan, tinggal dibandingin selisih ukurannya, dia calculate, ngitung, nyesuaikan itu.
Wah, banyak sekarang ya.
Ya, berarti kalau gitu ada pre-rendernya gitu dulu ya, semacam yang membaca CSS-nya.
Harus disambungin ke system pooling kita.
Ya, nanti kalau kayak gitu ada bahasan kena performance lagi nggak tuh pas build-nya?
Nah kan pas build ya.
Iya, beneran sih.
Aman sih, aman sih.
Kan musim di kita, nah kan dia outputnya CSS, CSS biasa.
Ya, pentingnya pas di run-nya aman sentosa ya, pas build-nya.
Atau sebetulnya kalau kita nggak banyak gunta ganti font, ya kita running aja sekali di lokal, terus copy output-nya.
Udah deh, nggak usah.
Maksudnya besok-besok kan kita nggak harus ngeubah itu lagi sampai kita ganti font kan.
Bener sih, iya.
Ini lah pentingnya, jangan apa yang berbagai font gitu ya, satu itu berbagai jenis font beda, font-font lainnya.
Iya, satu website biasanya ada berapa banyak font family?
Satu lah.
Tiga, dua, dua ya.
Maksimal dua.
Maksimal dua, cuman di kita juga satu deh perasaan satu.
Kayak umumnya satu deh.
Kalau misalnya buat apa lah, kayak logo atau apa kan bisa diakaliin pakai SVG aja ya.
Iya, iya.
Kalau website berita atau artikel mungkin butuhnya dua kali ya, untuk title sama untuk body, atau ada subtitle juga.
Iya.
Tergantung jenis webnya ya.
Iya, iya benar sih.
Biasanya kalau fontnya udah lebih dari dua, jangan-jangan itu ciri khas website waktu belajar CSS.
Oh iya, lagi seneng-senengnya ini ya.
Ada comic sans.
Ada comic sans, masih ada ya comic sans.
Wah, ada yang curhat nih, web Tokopedia suka crash kalau kita input search pas masih loading skeleton.
Crash itu gimana, kalau di web crash itu gimana ya?
Oh muncul itu ya, muncul dinosaurus ya.
Not responding.
Bukan dinosaurus, biasanya kita angkat beban sih sebutannya.
Oh itu ya gambarnya itu ya.
Iya, oh menarik nih.
Bisa jadi input sih, itu kayak gitu.
Beda departemen.
Beda departemen, cuman disini biasanya kita kalau ada isu-isu, emang saling kasih tau gitu sih.
Oh jadi ini masalahnya pada saat lagi loading, skeletonnya belum selesai, isinya belum muncul.
Terus ini si user sudah langsung search input, inputnya udah ngetik lah gitu.
Oh iya, berarti kalau gitu si inputnya juga udah bisa langsung diakses ya deh.
Iya, mau ngejar itu kan first input display kan, FED kan.
Iya, iya, wah ini contoh pengorbanan hasil demi FID mungkin.
Demi FID, demi mengajar code for web vital.
Iya, wah tapi ya itu gak tau sih memang banyak faktor ya.
Banyak faktor.
Iya, kadang-kadang kita kan sebagai developer juga kalau lagi bikin, lagi develop gitu kan,
ya kita pakai dengan kondisi yang ideal kan, internetnya apa, bandwidthnya gede, layarnya gede gitu kan.
Jadi harus diperhatikan juga ya mungkin harus di throttle gimana.
Kalau ternyata loading datanya lambat sekali, tiba-tiba ada user yang langsung search gitu kan.
Nah itu juga harus.
Atau ngetiknya cepet atau apa? Nah kan kalau input element itu memang kudu di debounce ya.
Di debounce.
Oh, biar dia ngirimnya event, kan sebenarnya tiap kita ngetik tuh ngirim event.
Nah kalau event itu nge-trigger request misalnya ke REST atau GraphQL server,
kalau bolak-balik kirim-kirim-kirim-kirim kan mungkin ya dibowl.
Jadi harus di debounce biar harus misalnya setengah detik sekali atau apa kirim eventnya.
Iya, tapi kalau kayak gitu kalau misalnya ngetiknya kelamaan, dibowlnya juga...
Kalau lama kan gak apa-apa.
Iya sih.
Kalau lama ya udah ngikut dia aja kan.
Maksudnya jadi ngirimnya tetap misalnya setiap setengah detik atau seperempat detik sekali.
Udah kalau dia detiknya satu hurus satu detik kan gak apa-apa gak ngaruh.
Iya sih benar-benar.
Tapi belakangan denger-denger ada tuh dari Google nyaranin selain pakai debounce,
ada yang baru pakai kayak scheduler kayak gitu tuh.
Wow, menarik.
Hah, scheduler?
Iya namanya scheduler itu kayak API baru gitu sih masih experimental.
Oh, oke.
Nah, lanjut lagi nih.
Waduh, waduh.
Nah, ini buat orang product ini.
Tapi ini pertanyaannya, seberapa banyak orang yang mau taro barang di shopping cart lebih dari berapa nih?
Sembilan, sembilan, sembilan, sembilan.
Ya, nah itu sebetulnya...
Satu juta.
Balik lagi ke pertanyaan kenapa taro sebanyak gitu.
Iya, buat apa? Taro aja di wishlist gitu kan.
Di wishlist juga bisa dijebolin kayak gitu juga sih.
Oh, bisa juga ya.
Logik aja kan.
Iya, benar, benar.
Nanti ada pertanyaan lagi ya.
Iya, kenapa? Kenapa?
Ya, tapi kan sebetulnya apa pun gak ada yang namanya unlimited kan.
Jadi, misalnya kita pakai data unlimited kan sebenarnya gak unlimited.
Iya, betul.
Invisibel atau apa pun ada betusnya kan.
Kan, unlimited.
Iya, mungkin keliatannya di...
Ya, itu keliatannya unlimited sebenarnya padahal ya, limited digedein aja.
Jadi, ilusinya unlimited.
Iya, itu kan paling.
Tapi kalau jawaban teknisnya adalah membatasi storage dan database.
Jangan banyak-banyak.
Benar banget.
Nanti costly.
Coba bayangin, satu orang bisa satu juta shopping cart, item, dikali berapa pengguna Tokopedia.
Mungkin setengah atau nggak sampai setengah, mungkin berapa persen pengguna Tokopedia.
Bayangkan berapa uang yang harus dikeluarkan oleh Tokopedia.
Iya, terus pasti itu kalau jawaban orang produknya pasti ada risetnya.
Kalau nyimpan wishlist atau itu lebih dari sekian, akhirnya gak kebeli juga.
Pasti ada riset-risetnya kayak gitu kan.
Iya, nah ini risetnya nih.
Risetnya dari keluarga sendiri kayaknya ya.
Observasinya luar biasa hari ya, sampai orang tua dan pacar juga jadi.
Nah, tapi kan kalau dari sudut pandang infra, yaudah pertimbangannya.
Yaitu kos sama mungkin bidangnya mana kali ya?
Rata-rata produk yang kebeli dari wishlist atau dari shopping cart kan pasti ada presentasinya kan.
Misalnya kita masukin 20 item di shopping cart, nggak semua orang punya duit unlimited.
Ya, kita semua nggak ada yang punya duit unlimited, check out semua juga kan.
Duit nggak unlimited, berarti misalnya dari 20 itu ternyata yang kebeli cuma 5.
Yaudah kan berarti ada gambaran bahwa yaudah sekitar, pokoknya item allowance-nya harus di atas 5.
Atau di atas berapa persen lah, persentase kali ya.
Terus kalau kebanyakan yang di dasar itu pasti nggak pernah kebeli gitu di capi.
Ya, pertimbangannya banyak sih ya.
Kalau misalkan nih, anggap lah ada needs tertentu gitu ya, untuk tipe orang-orang yang mau taro barang di shopping cart-nya sebanyak 1 juta.
Kita bikin aja coba, e-commerce unlimited shopping cart ada yang pakai nggak?
Bukan itu faktornya ya, banyak diskon, UI/US dan lain-lain gitu.
Itu hanya kecil banget gitu faktornya.
Bisa istilahnya ada, ini pengganti kan bisa ditaro di wishlist, bisa di-copy link-nya, ditaro di catatan, atau di to-dolist gitu.
Itu kan sebenarnya, ini kan keuntungannya teknologi web kan bisa di-bookmark pakai sistem apapun kita di browser bisa.
Pakai tools kayak raindrop atau bookmark manager apapun ya bisa.
Iya, ditaro di to-dolist juga bisa, tinggal di-copy link-nya kan.
Buat beli sepatu.
Oh, cuma, apa sih, aku kalau mau compare, misalnya compare sepatu atau HP atau apapun,
ya emang literally pakai bookmark manager sih, pakai raindrop kan enak tuh.
Ya, nggak harus raindrop sih, apapun yang bisa pakai folder kan lebih jelas ya.
Compare sepatu lah, compare HP atau compare apa, earphone atau gadget atau apapun.
Gak, campur-campur.
Wah, ini bisa jadi masuk kan buat other product deh, bikin Twitter buat compare nanti.
Kalau di shopping cart kan ketumpuk semua kan, dari mau beli smartwatch, dari mau beli sepatu lah, pusingan.
Iya, mencet satu-satu ya.
Iya.
Oke, nah.
Sebelum kita kemana-mana, sebelum ngomongin diskon dan lain-lain, nanti ngelantor kemana-mana,
mungkin kita simpulan dulu ya, kita simpulkan, apa, kumulatif Leoship itu bisa kejadian di banyak item,
di banyak element, salah satunya ada image, ya.
Kalau image itu bisa diakalin dengan cara memastikan ukuran width dan height-nya, panjang dan lebarnya,
atau menggunakan aspek rasio tadi, kemudian masalah kedua ada di, dimana tadi, di font.
Ya, cari font yang mirip-mirip atau font line height dan width-nya disesuaikan.
Terus, apa lagi?
Text, panjang text-nya.
Kalau text-nya dynamic atau lazy loaded, kita nggak tahu panjangnya, kita bisa masukin di apa, container,
terus dibantasin jumlah barisnya, pakai trangkit atau line clamp.
Di trangkit atau, ya, bisa menggunakan tadi apa, line clamp.
Ya, line clamp.
Nah, terus kalau buat ngecek, bisa pakai Lighthouse, bisa pakai DevTools performance tab.
Kalau buat programatiknya ngecek, bisa tadi pakai apa, Lighthouse API?
Lightout Instability API.
Bisa pakai API Lightout Instability, bisa nge-set performance budget juga.
Dari Corel Files sendiri juga menyediakan API, ya.
Sudah ada API-nya, jadi bisa dicek juga di sana.
Oke, mungkin untuk materi malam hari ini, itu dulu aja.
Terima kasih banyak buat teman-teman semua.
Terima kasih banyak juga buat Jessica yang udah nemenin kita ngobrol-ngobrol malam hari ini.
Dan kasih bocoran-bocoran juga dari Tokopedia.
Mudah-mudahan ke depannya nanti bisa diundang-undang lagi
buat ngobrol-ngobrol lagi dengan topik yang sama atau topik yang berbeda.
Kita ketemu lagi di line kesempatan.
Kalau kita akan ketemu lagi minggu depan.
Jadi selamat malam, sampai jumpa.
Mudah-mudahan Ivan bole-bole, jangan lupa.
-Ole-ole online, amun ya. -Ole-ole.
-Ole-ole aja, ya. -Ole-ole.
Oke, terima kasih semuanya.
Sampai jumpa minggu depan. Bye-bye.
Sampai jumpa semua.
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 Topik: - 00:00 intro - 11:00 pengenalan cls - 13:00 pengenalan lcp,fid,dan cls - 24:00 fungsi lineclamp - 30:00 ci/cd di tokopedia - 34:00 buat performance budget - 38:00 pentingnya font - 42:00 tools untuk font - 50:00 jawab pertanyaan - 58:00 summary cls Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
12 Feb 2025
Optimasi Performa JS
Episode ini membahas tentang tips dan trik optimasi performa JavaScript, khususnya penggunaan atribut async, defer, dan ...
15 Mar 2023
Ngobrolin TypeScript
TypeScript dibahas sebagai superset JavaScript — bahasanya tetap JavaScript, hanya ditambah anotasi tipe, interface, gen...
17 Apr 2024
Ngobrolin OOP di JS
Episode ini membahas Object-Oriented Programming (OOP) di JavaScript secara mendalam, dimulai dari konsep dasar prototyp...
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 .