Update Performa Web
Ringkasan Episode
Bantu KoreksiEpisode ini membahas update terbaru seputar web performance, dengan fokus utama pada rilisnya Web Vitals versi 5 yang menghapus FID (First Input Delay) dan menggantinya dengan INP (Interaction to Next Paint) sebagai metrik resmi. Diskusi mendalam mengenai perbedaan antara lab data (data pengujian dengan tools seperti Lighthouse, PageSpeed Insights) dan field data (data real dari pengguna menggunakan Web Vitals JS). Episode juga menyinggung tentang Chrome UX Report (CrUX) yang menyediakan data performance publik dari pengguna Chrome, serta pengenalan tools RAM Vision untuk monitoring capability browser dan fitur web secara lebih detail. Topik tambahan meliputi Speculation Rules API dan View Transitions API yang dapat membuat Multi-Page Application terasa seperti Single-Page Application, serta pentingnya accessibility dan standar web yang berlaku di berbagai negara.
Poin-poin Utama
- •Web Vitals versi 5 telah dirilis dengan perubahan utama menghapus FID dan menggantinya dengan INP secara permanen
- •Perbedaan mendasar antara lab data (data pengujian dengan Lighthouse/PageSpeed Insights di device sendiri) dan field data (data real dari pengguna dengan Web Vitals JS)
- •Chrome UX Report (CrUX) menyediakan data performance publik dari pengguna Chrome yang dapat diakses melalui CrUX Dashboard dan CrUX Visualize dengan Looker Studio
- •RAM Vision adalah tools monitoring berbayar (€157/bulan) yang dapat melacak capability browser dan fitur web per user, membantu decision making untuk mengadopsi fitur baru
- •Speculation Rules API dan View Transitions API dapat dikombinasikan untuk membuat Multi-Page Application terasa seperti Single-Page Application dengan instant loading dan smooth transitions
- •Lighthouse CI dapat digunakan untuk monitoring performance dalam pipeline CI/CD, namun alternatif lain seperti Calibre, DebugBear, dan New Relic juga tersedia
- •Accessibility dan performance web adalah standar yang diwajibkan oleh hukum di beberapa negara seperti US, UK, dan negara-negara Eropa untuk layanan publik
[music]
Halo, selamat malam semuanya.
Telolet om.
Telolet om.
[musik]
Gimana kabarnya?
Mudah-mudahan sehat.
Ujan ya di Jakarta.
Ujan.
Jogja juga ujan nih.
Jogja juga ujan ya.
Jadi panas udara ya kalau antara mau ujan sama setelah hujan ya.
Iya.
Jadi hujannya lebat kali gerah.
Kayaknya dulu kan musim kemarau ada itunya ya bulan April sampe September itu musim kemarau.
Oktober sampe Maret.
Ujan dulu pas SD.
Disuruh ngapal kayak gitu. Sekarang kayaknya udah gak berlaku deh karena climate change.
Apakah masih ada pelajaran musim panas, musim dingin, musim hujan, musim kemarau?
Kemarau dan hujan.
Iya. Sekarang musim pancaroba.
Kayaknya selalu musim pancaroba deh.
Iya kayaknya sekarang kita 3 bulan sekali musim pancaroba deh.
Ya harusnya kan coba setahun 2 kali.
Iya. Kadang panas sorenya ujan.
Terus kadang paginya ujan sore siangnya panas.
Ya gitu lah ya.
Udah lebih sulit di prediksi ya.
Gak seperti zaman dulu ya.
Ya jadi malam hari ini kita akan ngobrolin tentang web performance.
Lihat transkrip lengkap (2520 segmen lagi)
Ada beberapa update terutama dari tools-tools yang mungkin temen-temen tahu.
Atau mungkin belum tahu.
Jadi malam ini kita akan diskusikan bareng-bareng sambil menunggu narasumbernya.
Satu lagi nih narasumbernya.
Yang punya topic, yang punya materi nih.
Belum join. Belum join dia.
Nah kan baru diomongin sudah bisa join.
Nah udah muncul.
Dari ini lagi dari sungai. Pinggir sungai dia.
Habis berenang ya.
Bagus gak suaranya?
Kayaknya kepala musiar lagi nih.
Wey kepala musiar.
Ini pakai laptop yang satu lagi.
Oh ganti laptop.
Tadi gak bisa ya?
Laptop kerja soalnya laptop yang biasa dipakai buat nge-live.
Kalau dipakai live kelamaan dia panas.
Throttle.
Oh.
Somehow.
M berapa? M3?
Yang mana? Yang nama?
Yang kantor.
Yang kantor M4.
M4? M4 aja throttle ya?
Bukan. Kantor bagus. Luar biasa bagus.
Oh yang kantor bagus.
Yang nama? Yang punya sendiri?
Intel.
Intel. Intel i9.
Oh Intel ya.
Terkenal panas dan throttling.
Kalau Intel ya wajar.
Jadi salah satu saat kita nge-live itu.
Eka kenapa? Barusan suara robot.
Kalau M4.
Iya sama.
Suara robot juga.
Koneksi ya? Koneksi ya?
Koneksi.
Suaranya kayak robot.
Koneksi ya?
Oh.
Ya. Jadi.
Yang seperti yang kita omongin sebelumnya.
Kita akan bahas tentang performance.
Beberapa update yang berhubungan dengan
tools untuk mengukur performa website.
Atau web. Aplikasi web ya.
Kita.
Kalau teman-teman yang di link in.
Kita live di dua lagi di itu sama link in.
Jadi kalau teman-teman yang ada di link in.
Kita live.
Utamanya. Channel utamanya memang di YouTube ya.
Kalau baru tahu di link in.
Kalau bisa pindah ke YouTube juga boleh.
Kalau mau di link in juga gak apa-apa.
Cuman kita gak bisa.
Gak bisa ngetik.
Gak bisa komen di link in.
Teman-teman bisa komen.
Kita nya gak bisa posting komen ke link in.
Jadi cuman bisa read only.
Doh ilang lagi.
Kena throttle nih.
Performanya kurang bagus berarti.
Redtop nya.
Kenapa barusan?
Login dulu.
Login?
Oh. Refresh.
Iya. Terus di refresh.
Oke.
Kita langsung mulai aja.
Malam hari ini kita bahas web performance.
Kita mau bahas dari
Web Vitality The Jazz.
Yap.
Jadi topik itu dari saya.
Ya.
Semuanya sih kayaknya.
Oh ini dari link in. Halo.
Kita mulai melembarkan sayap.
Nah.
Teman-teman
yang
mungkin yang
sudah tahu pakai Web Vitality The Jazz
atau yang belum tahu
ada loh
tools dalamannya
Web Vitality The Jazz
yang sebenarnya dia ini aja ya.
Rapper dari
performance API.
Jadi dari web
performance API diwrappling
untuk mempermudah kita
kayak
mengambil data.
Ya.
Ya. Kayak kalau di load.
Terus dia bisa mengambil data
onLCP, onFID,
salah. onFID udah nggak ada.
onLCP, onCLS
sama on
TTFB segala macam.
Kita bisa harvest datanya di JavaScript.
Melalui JavaScript.
Yang kita bisa proses tentunya
menuju
yang saya lakukan di kantor
saya kirim datanya
ke
sebagai custom
metric ke
Google Analytics.
Jadi bisa saya tracking manual.
Atau teman-teman
punya tools lain yang
beacon,
kind of beacon gitu. Kayak kirim data
ke mana bisa pakai Web Vitality The Jazz.
Ada kok tutorialnya dari
banyak yang bisa
bikin
dari GTM.
Terus dibikin
segmentation-segmentationnya.
Terus kemudian dia sudah
nge-load Web Vitality dari GTM.
Lalu kirimkan data
nanti langsung di-export
datanya ke Looker Studio.
Jadi kalian bisa lihat grafiknya.
Oh dashboard.
Jadi grafiknya langsung
data yang kalian kumpulin
sendiri dari user kalian.
Jadi ini adalah
bukan lab data, tapi
field data. Jadi dari user.
Nah, yang terjadi di sini adalah Web Vitality
nyah.
Release sebelum Google I/O biasa.
Oh, sudah
mendekati Google I/O ya.
Sekarang, release. Jadi kalian
tahu dari saya Web Vitality 5
itu release sekarang sebelum
nonton Google I/O announcementnya nanti.
Data ini sudah bukan
NDL lagi, masih di Jakarta sudah dipublish.
Oke.
Jadi ini
jadi ini, kalau biasanya
kan kita pakai Inspek Element
gitu kan, terus ke
Performance.
Atau kita menggunakan
tools kayak
Xspeed, atau yang
ini kan, misalnya.
Tadi Mas Riza pakai ini namanya
lab data. Jadi
kita sebagai
performance researcher
mencoba mendibug
performance di device
kita. Sedangkan
Web Vital.
Web Vital JS ini
adalah script
monitoring yang kita
panamkan.
Ya, di client side.
Kayaknya si Eka harus
reload dulu.
Cari sinyal, cari sinyal.
Coba di-reload kali ya.
Coba restart. Coba refresh.
Refresh browser.
Nah, sudah
ngefreeze ya.
Jadi kalau kita pakai
Web Vital JS ini,
begitu website kita
di-load oleh user, itu akan direkam ya.
Performance-nya berdasarkan
dari sudut pandang user ya.
Gimana Eka? Coba cek.
Ih, ilang lagi.
Ibu Eka suaranya pecah.
Pecah, berarti lucu ya.
Kalau pecah.
Kalau gak salah, waktu 10 stack
minggu lalu, ada kan
Web Vital, bisa nge-load Web Vital JS kan?
Iya, ada, ada.
Iya, bawaan dari
framework-nya ya.
Termasuk juga waktu create track
app juga ada.
Bagaimana suara
Eka masih pecah nggak?
Coba tes Eka.
Ya, lebih kan kan?
Menurut saya.
Saya nggak ketahuan pecah atau nggak.
Iya, makanya.
Ya, jadi
berarti ini lebih
apa ya, lebih real ya
dibandingkan kita tes
kalau pakai page speed atau
extension ya, atau pakai
aspect.
Sebenarnya,
real-nya itu
maksudnya begini, device
jadi
kondisi device di lapangan,
kondisi internet
di lapangan user kita.
Ya, network masing-masing user.
Ya, kan berbeda-beda.
Jadi kita nggak bisa
nggak bisa menggunakan
standar kita yang menggunakan
MacBook M4 untuk
ngetes performansitas kita.
Dan kita bilang sama
klientek, dengan
Wi-Fi yang super cepat, saya bilang
ini bisa USB cepat-cepat aja gitu.
Tapi ternyata bisa dengan
koneksinya
jelek, sama juga bohong.
Benggak taunya kliennya
pakai internet explorer
versi 6 gitu kan.
Bisa jadi.
Ya, berbeda ya.
Ternyata testing-nya
ngaco berarti ya.
Betul.
Jadi pakai web,
jadi tools ini banyak sih
yang pakai framework-framework
sudah banyak pakai, terus kemudian
kayak kalau kita
kayak pernah kan di 10 stack yang lalu
udah pakai, udah ngebundle ini
kalau nggak salah, next juga pakai.
Udah ada, iya, udah ngebundle.
Udah memasukkan
web fighters-nya tinggal dipakai.
Kecil kok, nggak sampai kurang lebih 2K ya.
2Kbyte.
Dikompresi.
Dikompresi, 2Kbyte
oke lah.
Jadi tinggal pakai
tinggal pakai
wrapper-wrapper-nya, onlcp,
onimp, oncls, itu nanti
angkanya
langsung kelihatan, iya.
Nah ini kan callback-nya itu
console-lock.
Callback-nya itu bisa ke
function kalian sendiri, bisa pakai
more sent to analytics-ka,
more sent to
pages-ka, whatever lah gitu ya.
Kalian kirim data kemana, iya.
Biasanya kirim begin ke
analytics atau ke
atau simpan ke database.
Iya, simpan database.
Berat sih, cuman ya.
Sebenernya simpan database
ujung-ujungnya ya, cuman simpan database
jangan database sendiri.
Iya, pakai service terpisah ya
external service, jadi dia cuman lempar aja.
Terus nggak perlu nunggu,
nggak perlu apa namanya
waiting gitu ya, sampai datanya kesimpan ya.
Ya kan bisa misalnya kita
udah punya API sendiri kan
buat masukin database,
terus saya postgres, terus ada
aplikasi lain misalnya yang pakai
database atau apalah
analytics apapun.
Biasanya, kalau mau
di open source-kan semua, bisa pakai
yang namanya, kalau dari apace
apa itu namanya?
Yang buat data gede,
datadoc.
Datadoc.
Iya kayaknya ya, kalau nggak salah, ada ya.
Bukan apace apa gitu.
Ini berbayar ya?
Bukan, bukan datadoc, intinya
dari apace, terus kemudian datanya
bisa di visualisasikan ke
atau elastic search deh,
gampang ya, itu kan free ya,
open source ya.
Neuralic?
Neuralic bayar.
Ya simpannya misalnya ke
elastic search, terus kemudian
di visualisasikannya
di Grafana, bisa.
Kalau mau
bikin sendiri,
tapi kalau nggak mau bikin
sendiri, ada yang namanya
Lighthouse CI.
Coba tuh buka Lighthouse CI.
Cuma ini kayaknya
project sudah diabandon.
Abandon ya?
Iya.
Kenapa?
Masuk, apa kuburan?
Maksudnya,
kapan terakhir kali di, ini coba
kapan terakhir kali?
7 bulan.
Ya sih, kurang begitu dimaksudkan.
Masih lah, masih jalan.
Dan fail lagi.
Itu docks lagi.
Docksnya aja gagal.
Coba turun, ada,
dia bisa visualisasikan data
Lighthouse ini.
Ya, bisa
bandingin halaman ke halaman.
Cuma ya per branch.
Berdasarkan pull request ya?
Berdasarkan pull request atau branch ya?
Ini untuk CI/CD kan,
musti pipeline gitu.
CI, CI.
Untuk CI. Nggak pakai CD.
Kalau semisalnya
temen-temen nggak mau
pakai begini-beginian,
ada yang namanya
2.
Crux Dashboard sama
Crux Visualize. Masih bisa ada di
dock.
Oh, pakai Looker Studio.
Ya, coba masukin.
Siapa mau masukin?
Activate kek atau apa kek?
Lagi dimatiin.
Lagi dimatiin.
Lagi dimatiin.
Lagi dimatiin.
Ini, ya,
ini crux data ya.
Chrome UX Report
dari
sebenarnya pakai WebFighter juga
di belakangnya.
WebFighter JS juga di belakangnya.
Kurang banyak datanya.
Kurang banyak.
Coba LCP.
Coba lo pakai yang
itu.
Kekiri.
Ada bintang di kiri, bintang di kiri.
Kiri, kiri, kiri.
Sidebar.
Ah, coba.
Ada nggak datanya?
Mudah-mudahan banyak.
Nggak banyak-banyak amat batas data yang
mengunjungi situsnya Mas Riza.
Iya, kurang banyak.
Kalau mau lihat
yang banyak ya tes salah satu
situs yang banyak isinya.
Web.dev lah.
Yang pasti
banyak.
Dan bagus.
Oh, iya, benar.
Nah, ini data
yang sudah dikumpulkan
dari si Google
Anonymous Data.
Oh, yang dari, apa namanya?
Chrome, ya, Chrome UX.
Chrome UX.
Jadi, datanya ini
berasal dari semua
pengguna Google Chrome.
Chrome, ya,
Chrome only. Bukan Chromium ya, Chrome.
Ya, Chrome, Google Chrome saja ya.
Google Chrome.
Yang
tersebar di semua
device, mulai dari
Android,
Android,
dan desktop.
Desktop, tablet iOS ya.
Ini kan
part dari, ini kan bukan rendering,
ini part dari product.
Tepat lah.
Apa, layer atasnya
browser engine.
Bukan, nggak ada hubungan sama browser engine ya.
Iya, nggak ada hubungan. Ini part
dari product. Jadi,
saat kita menginstal ini, kita sudah setuju
kalau datanya dikirimkan.
Meskipun, data yang dikirimkan
Anonymous. Kalian bisa lihat bunker
sendiri nanti datanya di Google Data Studio.
Ya,
itu Google BigQuery.
Kalian bisa lihatannya, kok data,
raw datanya ada, kok.
Jadi, jangan takut, wah Google,
blablabla. Tapi,
cukup transparan
data ini. Ini ya.
Namanya table field-nya
ini. Jadi, nggak ada
nama, nggak ada
IDF,
PII, nggak ada PII.
Iya.
Jadi, cuman
mengirimkan
data aktivitas,
web yang kita
akses,
terus performanya gimana,
device-nya apa, device-nya apa ada ya?
Ada.
Kan harus tahu tablet,
tablet,
ada, ada, ada.
Ada ya.
Sama archive.org,
kok nggak salah, tapi kayaknya nggak disebut
di sini.
Terus, dari,
biasanya ke LCP deh,
ke Sidebar DLCP.
Bisa kelihatan, perjalanan
di bulan April misalnya,
8,17%
masih ada yang kurang bagus.
Kurang bagus.
Itu tuh desember ke januari,
kayaknya mereka ganti
apa, meng-improve sesuatu
jadi naik, naik banget ya.
Drastis ya.
Berarti sukses, sukses, berarti
betul-betul improvement-nya kan.
Kalau dari Juli ke Agustus,
malah jelek ya jadinya ya.
Regression.
September dibalikin lagi.
Nah, di sini artinya apa,
tapi
bedanya sama, apa bedanya sama
WebVital.js yang tadi misalnya
dengan yang ini.
Kalau data ini kan data public
yang dikumpulkan oleh Google
dan direpresentasikan
dengan tools-tools tersebut.
Jadi, delay datanya ada.
Hanya bisa kita lihat data
sebulan atau 28 hari terakhir.
Sedangkan,
kalau kita kumpulin sendiri,
kita bisa lihat real-time
yang terjadi.
Tinggal sekuat apa server kita
untuk memproses data sebanyak itu.
Dan user yang tidak pakai Chrome juga bisa
ke rekam kan.
Mungkin ada yang pakai, mana tadi?
Ada yang usernya pakai
Opera Mini.
Oh, pusing itu.
Dia punya server sendiri,
Opera Mini.
Itu browser favoritnya Ivan.
Opera Mini.
Dia punya rendering,
bahkan mereka punya markup
language sendiri dong namanya OBML.
Opera Browser Markup Language.
Masih bisa itu?
Masih, masih. Ya mungkin masih.
Terakhir lihat orang pakai
Opera Mini, sekitar
4 tahun lalu sih, terakhir harus
mengakomodasi user yang pakai
Opera Mini.
Mereka masih ada Opera Mini nggak ya?
Iya, masih. Cuma masih
banyak dipakai atau enggak.
Sama, maksudnya,
cukup banyak user kita yang pakai atau enggak,
nggak tahu. Terakhir harus
mengakomodasi user
Opera Mini 4 tahun yang lalu.
Abis itu, gue sengaja tunjukkan browser stats.
"Nih, makin lama, makin turun, user-nya
udah nggak ada yang pakai. Udah ya, kita nggak
lanjut akomodasi
mereka."
Ada Opera Mini, ada
Opera Mobile, beda ya?
Ada, beda.
Beda ya?
Opera Mobile itu seperti
modern browser-nya.
Modern browser
sebenarnya.
Nggak tahu kalau Opera Mobile itu normal
sih. Kalau Opera Mini, yang dulu
gimmick-nya adalah data saving. Data
saving-nya karena mereka tuh kayak
punya satu server sendiri.
Jadi kayak dibuka dulu
dari situ. Mereka bikin
SSG sendiri, based on
proxy server-nya mereka.
Cuma itu, Wacoh, itu busing sih.
Ya, gitu lah.
Oke.
Itu kan tadi
browser stats untuk
apa namanya?
Dari kitanya
sendiri untuk
membatasi
seed
salah.
Browser stats kan kita bisa lihat
berapa banyak user yang menggunakan
browser tertentu. Jadi
berapa persentase browser yang menggunakan, berapa versi.
Kalau nggak salah tools yang kita pakai, kalau dibuild
Java Seed, lu pakai apa namanya ya?
Browser stats, eh bukan browser stats.
Browser apa namanya? Tau nggak?
Yang buat polyfill.
Enggak.
Polyfill.
No, no, no, kalau kita mau
bundle
dibuild tools-nya kita,
kita pakai browser. Kita bisa
pakai browser list atau apa gitu yang namanya.
Bukan.
Nah, ntar gue buka
project ini.
Pasti penasaran.
Tools atau library?
Preset ENV,
bukan?
Bukan.
Kita bisa set
preset-nya. Kita hanya support
misalnya
browser list.
Browser list.
Browser list kan tapi dari
bubble. Maksudnya itu adalah
opsi dari bubble kan?
Yang bikin dia
apa namanya?
Polyfill-nya kan si bubble. Cuman
browser list itu
option-nya. Benar nggak?
Kayaknya iya.
Bukan.
Kita kan
browser list, terus kemudian
kita decide
tools kita
hanya support
2 maja terakhir
plus EA11
misalnya. Jadi waktu dibundle
Ini kan?
Iya, browser list.
Oh, integration.
Iya, dia ada integrationnya.
Eh, belum nisir.
Oh, sorry. Ini ini.
Integration.
Ini. Nah.
Integration.
Iya, browser list. Nah.
Ini dia.
Ini maksud saya.
Tau pakai tapi nggak tau namanya. Gila ya
sekarang ya. Jaman sekarang karena udah semuanya
sudah dibikinin.
Nah, ini aslinya ya.
Browser l.ist.
Wah, susah ya
kalau dibaca. Tapi ini
shortcut kali ya. Browser
l.ist.
Nah, kenapa saya singgung ini? Ini kan
kita sendiri yang mendesain. Oke, saya
mau support browser
yang
yang terbaru
saja. Yang terbaru saja.
Yang versi sekian sampai sekian, gitu ya.
Nah.
Bagaimana dengan fitur-fitur
yang selanjutnya.
Kapan kita decide
kalau
fitur tertentu
sudah bisa kita pakai?
Kebayang nggak?
Maksudnya. Misalnya
ada fitur yang belum baseline.
Contohnya.
Tetapi kita mau pakai itu.
Cuma pertanyaannya,
bisa nggak sih kita pakai user kita
sudah pada mampu nggak sih?
User kita ya. Bukan user
umum. Bukan semua user
pada umumnya. Ya. Sedangkan kita
nggak tahu. Datanya
nggak ada yang ngasih tahu kita.
Kalau di Google Analytics,
nggak
komprehensif. Nggak se-komprehensif itu
melihat versi browser yang
dia hanya bisa lihat
versi browser. Nggak bisa lihat
percapability.
Apakah
flag-nya dinyalain, atau enggak?
Gitu ya. Tapi tepatnya
misalnya kayak
jaman dulu kayak apa ya?
Performance Observer atau
misalnya Intersection Observer
atau apalagi
Capability yang lain. View Transition.
View Transition misalnya.
Capability View Transition nggak ada
di Google Analytics nggak ada kan.
Kita nggak tahu. Sedangkan
View Transition itu
belum baseline. Contohnya.
Dan View Transition sudah ada yang
level 1, ada yang level 2 nih.
Dan Dokumen Transition.
Ada tools yang namanya
RAM Vision. Itu
yang bikin GDI jadi itu.
RAM Vision namanya. Ada di...
Apa? Namanya RAM Vision?
Oh, yang ini ya.
Ide... Ide...
Ide Startup. Bukan. Ide Startup bagi kalian.
Jika ini bikin
beginian, bisa loh.
Ini apa nih? Boleh
dijelaskan?
Jadi, sama
kayak... kayak
saya tahu tadi, ini Real User Monitoring.
Oh, oke.
Real User Monitoring.
Ini kayaknya pernah kita bahas ya.
Iya. Kapan gitu.
Ini berbayar ya tools-nya ya.
Jadi saya cuma mau ngasih,
kalau tools ini ada, dan saya nggak
menemukan yang sepadan
yang bisa seperti ini. Sehingga
kalau kalian mau bikin Ide Startup,
tiru aja begini, kayaknya
bisa jadi sebuah
ide, dan bisa ditiru, gitu ya.
Apa yang dilakukan
tools ini?
Ya, standarnya
Core Web Vital.
Dan itu banyak tools yang bisa
menemukan. Cuma dia bisa ngasih sebuah
Extend.
Kita bisa ngamonitoring
web capability tertentu yang
kita ingin tambahkan.
Misalnya, suatu saat
ada decision,
"Oke, saya mau menggunakan View Transition."
Ya udah, tambahkan
View Transition atau
Documentation misalnya kayak
Capability yang mana.
Lalu, biarkan aja
dulu datanya jalan. Nanti dia akan
akan ngambil data tersebut,
baru kita bisa lihat, "Oh, ternyata
90% user kita
sudah support."
Oh, jadi kita bisa default.
Yang nggak pakai itu mungkin
Firefox, Safari,
misalnya ya, atau
Chrome yang 5 versi sebelumnya.
Contohnya, 4 versi sebelumnya
ternyata user kita itu
banyak pengguna Chrome yang 2 versi sebelumnya
dan 90%. Ya kita bisa
decide sebagai business,
"Ya udah, kita pakai View Transition."
Tuh, 90% user kita
sudah support.
Seperti itu.
Eh, perasaan dulu kita sempat
ngomongin mau bikin ya?
Tahunya udah ada ya?
Indul banget
waktu awal-awal. Awal-awal
nge-brand web kayaknya 2 tahun yang lalu.
Turun lagi, ada nggak sih
ambition yang lain?
Jadi sebetulnya selling pointnya dia adalah
kayak ngejabarin, nge-breakdown
by feature ya.
Tapi sebenarnya sebetulnya
library yang dipakai adalah
Web Vitals sebetulnya.
Dia bisa nge-tracking
baseline ini.
Misalnya, user kita
kan ada baseline,
user kita ternyata
bisa lihat nge-tracking per
per capability
dan juga nge-tracking
by baseline. Jadi bisa lihat,
oh ternyata user kita itu sebenarnya
80% sudah support
baseline 2025.
Sudah saatnya nih kita upgrade
codebase kita ke baseline 2025,
contohnya itu.
Oh, atau gini,
atau gini,
misalkan kita punya fitur baru
yang membutuhkan
capabilities tertentu.
Ya kita, itu aja
kayak A/B testing. Jadi user yang udah
support, ya kita kirimin.
Tapi nggak bisa per user ya.
Nggak, bukan. Maksudnya gimana ya?
Bisa kan
device usernya kan?
Iya, misalkan kita
ada fitur
kita ada fitur
view transition.
Jadi kita mau rolling
A/B testing lah,
mau rolling nggak semua user,
per user tertentu aja.
Untuk melihat apa-apa efektif
atau bedanya.
Bukan dari tools ini.
Itu A/B testing kita,
tapi tools ini meneteksi user-nya
device-nya support atau nggak.
Kalau A/B testing kan kayak
buta ya, nggak tahu ya.
Jadi
dari data ini bisa kita lihat
aplikasi, yang pengguna
aplikasi kita, customer
kita, ternyata
majority atau 80%
sudah support baseline 2025
sebenarnya.
Tapi kita nggak yakin
kita harus ada datanya dulu ya.
Iya, tetapi code base
kita sebenarnya masih stuck di
baseline 2023
atau 2024 contohnya ya.
Bisa kita bilang tuh
ke si
stakeholder misalnya,
atau stakeholder, kayaknya kita bisa deh
upgrade ke baseline 2025.
Datanya ada.
80% sudah support gitu.
Berarti sih...
Gimana-gimana?
Dia beneran
JavaScript learning,
ngedeteksi
capability itu, kirimkan data ya.
Pakai ini kan, pakai
Web Vitals ini kan. Eh, mana dia tadi?
Web Vitals, iya.
Itu ada dua fitur
terpisah kan, misalnya yang
berurusan sama Web Vitals, data-data
terkait Web Vitals, sama satu
lagi, terkait baseline
database.
Custom code-nya mereka untuk
ngedetek per capability.
Sebenarnya ngeceknya nggak
terlalu rumit kan, tinggal
jalanin script aja, navigator dot
something. Oh, ada apa nggak gitu kan?
Satu-satu, iya.
Iya, harus didefine satu-satu. Oh, ini
untuk ngecek kamera, ini untuk ngecek
apa namanya,
view transition, ini untuk ngecek apa
gitu ya, GPS, lain-lain ya.
Betul.
Dan itu, sudah
sudah ada data set-nya.
Udah ada data set-nya
yang terkait
baseline ya, ini di luar.
Kalau Web Vitals kan sudah ada
itu-nya, metrik-metriknya.
Kalau yang berkara fitur tadi,
itu github.com/
webplatformdx/
webfeatures.
Oh, ini.
Kayaknya plate-nya pakai itu deh.
Jadi ini udah data set
lengkap banget, apapun itu.
Bisa jadi
seperti ini.
Iya, mungkin juga.
Jadi nanti dia kayak ada table-nya, yang ini
true/false, true/false, gitu ya.
Jadi tinggal di... Iya, plate-nya sih.
Coba aja buka folder features ke atas.
Nah.
Update-nya yesterday.
Oh, ini update terus.
Itu segala fitur
accelerometer atau misalnya kayak HP
yang bisa di-fill
kiri-kanan.
Atau apalah.
Iya. Ada berapa ini?
Oh, yang di-check ini.
Oh.
Mungkin ya, berarti itu tadi kan
nge-check satu-persatu kan.
Ada aja udah banyak banget.
If, blah, if
accelerometer in navigator.
If, blah, blah, in navigator.
Iya, dan seterusnya.
Robot nggak bisa dong. Iya, buat apa?
Kan bukan real user kalau robot.
Nggak butuh juga robot
nyalain kamera, kan?
Atau capabilities yang lain.
Dia nggak masuk. Nggak masuk
ininya. Nggak masuk
ke dalam user.
Oke.
Wah, menarik ya.
RAM Vision.
Ini
harganya berapa?
Itu tadi mahal.
157 euro.
Per bulan.
Wow.
Ada training-nya.
Rupiah nggak.
Coba rupiah. Nggak.
Oh, ada.
Ada.
Nggak ada.
Tiga juta per bulan.
Tapi ini
gede di data sini.
Sakit nyimpen data orang banyak.
Iya, nyimpen datanya, ya.
Iya.
Kita bisa nge-track data
kompetitor. Anjir, banyak banget.
Ternyata emang datanya, kan. Bukan data set dari
user kita sendiri.
Tapi dari kompetitor.
Tapi krukstone, ya.
Dia nggak bilang nge-track.
Ya kan nggak bisa masukin, nggak bisa
inject ke client-site JavaScript
di website kompetitor.
Ya juga ya.
Cuma, ya cuma gambaran besar-nya
aja buat, apa kira-kira?
Kalau dia bisa inject ke orang lain,
keren kali ya.
Nggak bakal diiklani.
Oke. Bahas seru ya.
Nah, balik ke Web Vitals tadi.
Kan yang versi 5
release nih. Berarti itu kan
versi-versi yang baru ya?
Perubahannya yang paling major apa sih tadi?
Belum sempat lihat banget.
Itu ada change log-nya kan sebelumnya.
FID dihapuskan
for good from the face
of the world.
FID ilang.
Kan sudah diganti INP.
INP. Gantinya INP, ya.
Nah, breaking-nya 3 itu ya.
Browser support policy
to baseline widely
available.
Nggak ngerti dah itu apa.
Apa ya itu?
Kalau widely available kan, itu kan
yang blah-blah. Buat versi
terakhir, blah-blah-blah.
Oh.
Baseline widely available.
Oh, dari baseline.
Terus?
Ya, maksudnya Web Vitals
library-nya sendiri
apa?
Support bisa jalan
kalau di browser yang
udah baseline widely available.
Oh, ini ada hubungannya
sama RAM-nya tadi ya?
Real user monitor.
Itu RAM Vision Company.
RAM Archive ini
real user monitoring archive.
Data sama sama RAM.
Oh, kirain si RAM
ini bikin
archive-nya nggak ya?
Itu namanya penjualan data ya.
Nggak bisa lah.
Itu kan tadi dia
layanan komersil.
Masih ada Philip Walton loh
yang nge-menting.
Itu question Philip Walton.
Tahun lalu.
Ini siapa, Philip Walton?
Google.
Member of Google Chrome.
Iya.
Dia pernah ngasih talks banyak
dulu, jaman dulu.
Bukan yang
pernah datang Indonesia ya.
Mereka berdua makan
di SGBID-nya dulu?
Alex Russell.
Oh, Alex Russell.
Slightly late.
Slightly late.
Iya, semua ini.
Iya,
berarti emang beliau yang
nge-menting.
LGTM.
Itu udah di-approved.
Udah di-approved.
Udah di-approved.
Ya.
Nah, sekalian nanya sih
buat semua. Apa? Kan kayak ada perubahan.
Ya, update-update kayak gini lah.
Apa?
Library Wi-Fi Plus-nya, ganti versi major.
Terus apa?
FID berubah jadi
INP. Nah, kalian
di tempat kerja kalian masing-masing,
ada itu nggak sih? Workflow
apa?
Workflow secara berkala,
kayak itulah yang
terkaitnya,
terkait performance.
Tapi di luar, bukan sesuatu yang bug ya.
Ini kan nggak breaking sebetulnya.
Tracking-tracking performance
gini, ya ini di luar kasus
misalnya saking lambatnya user pada
komplain nggak bisa buka halaman
atau mungkin dapat warning dari
apa? Google
Search Panel, misalnya Google
Analytics, atas semacamnya.
Di luar yang kasus kayak gitu, sebenarnya
kalian membiasakan, itu nggak sih? Kayak ada
improve performance tracking workflow.
Cucur gue belum sih.
Nggak pernah diapapain.
Ya cuma ada datanya,
cuma ya selama nggak ada
regression yang parah, kayak nggak pernah dilihat
dan nggak pernah diapapain.
Alternatif dari Lighthouse CI apa
sekarang kalau Lighthouse
CI-nya mau di-depakated?
Ya itu tadi debugber.
Cuma mahal. Banyak sih.
Ada banyak.
Kayak gitu-gitu.
Banyak ya? Banyak.
Contohnya
apa itu namanya?
Calibre. Calibre juga ada.
Dulu toko yang
injo bikin sendiri setau saya.
Mereka banyak
membuat study case mengenai itu.
Tinggal cari di GitHub atau cari yang
service-service-nya banyak kok yang
monitoring Core Web Vitals.
New Relic juga bikin.
Kata kuncinya
monitoring.
Core Web Vitals.
Buat CI.
Buat CI.
Maunya yang CI, jadi setiap
request, otomatis
gitu nggak ya? Nggak bisa ya?
Nggak ada ya?
Tapi bukannya masukin
jalanin Web Vitals
library gitu, bisa nggak sih?
Bisa.
Itu kan Lighthouse CI tadi kan
untuk dashboard-nya.
Tapi kalau
Lighthouse CI
bisa jalan.
Ada GitHub Action-nya.
Bukan depakated ya, berarti ya.
Bisa jalan.
Di Lighthouse
GitHub Action
ada?
Iya, di GitHub Action. Maksudnya kan setiap
ada penambahan
fitur atau pull request
atau apa kan, dia akan
menjalankan CI ini.
Dan dia bisa kasih tahu kan.
Berarti ini nggak
nggak
depakated kan?
Cuma dashboard-nya
tadi kan.
Jadi kalau teman-teman misalkan
mau nge-track
pada saat mengembangkan fitur
tertentu, tiba-tiba performance
dari Core Web Vitals-nya menurun.
Nah, itu berarti kan kesalahannya di situ.
Jadi bisa kita rollback, atau bisa kita
investigasi lebih lanjut.
Jadi nggak, apa yang nggak sembarang.
"Oh, ini error apa? Ini
salahnya dimana?"
Betul. Yes.
Tujuan-nya begitu. Tapi
kenyataannya saat saya pakai berbeda, Mas.
Jadi malah ganggu dan kelama.
Ganggu?
Oh, jalan-nya lambat gitu?
Ini dipakai ubuntu ya?
Ya, semuanya
ubuntu.
Kan ada yang lebih kecil.
Kan ada yang lebih kecil.
Ya, jadi boros.
Jadi lama nggak sih?
Kan di-charge by time ya?
Oh, tahu!
Rewrite keras, biar cepat.
Ini kan pakai NPM kan?
Tuh, pakai Jopacit kan?
Nggak tahu.
Yang penting rerite
aja dulu keras.
Nggak, pakai husky aja.
Itunya jalan di lokal, biar
nge-check-nya di lokal.
Nggak bisa gitu push.
Nggak bisa gitu push kalau belum mas.
Benar, jadi memberatkan laptop sendiri ya?
Ini Mas, saya nggak punya
kedudukan.
Kan LHCI Autorun itu kan
ada konfignya.
Dan page yang mau kita
monitoring kan ada banyak.
Dan device yang mau di-monitoring juga ada
bisa bermacam-macam.
Jadi semakin banyak
konfigurasinya untuk
jumlah device dan jumlah
page, semakin lama
scanning-nya.
Scanning-nya ya.
Ya kan semua halaman harus dicek
satu persatu? Atau kita yang
decide? Dan hanya bisa
untuk aplikasi yang
static, page itu.
Kalau misalnya ada database,
berarti database harus kita up juga.
Dan harus di-import database-nya.
Panjang jadinya ceritanya.
Jadi kalau hanya
sekedar hanya
static page, static application,
static page ya monggo,
gampang cepat up-nya. Kalau nggak ya
bootstrapping
aplikasi kita lama kan juga.
Install semua dependensi,
sampai dia up,
lokal host, baru lokal host-nya
di dalam tetap action di-scan.
Jadi
berarti idealnya itu bisa
dijalankan,
idealnya bisa dijalankan di testing
server kali ya?
Atau staging ya?
Saya lebih setuju
pakai yang daripada
di CI. Bukan CI, ini kita nggak omongin
CI, kita omongin performa secara umum.
Ya lebih baik di-testing
saat sudah
jalan di server, di staging,
baru di-test, sebelum
kita bisa. Atau pakai
yang tadi Core Web Fighter
Monitoring,
di Bugbear, atau Calibre,
ada New Relic,
jadi bisa di-setting
buat di staging, jadi bisa kita capture
sebelum go live juga bisa kan?
Iya, di Bugbear.
Oh, oke, oke, oke.
Cuma ini kelihatannya
bisa ke, apa?
Soalnya kadang kita pakai staging
kan, kapabilitas
server-nya sengaja yang
low cost kan, jadi mungkin
lebih lambat, terus kita pusing,
karena hasilnya jelek, lambat,
padahal kalau di production,
kenceng.
Enggak, biasanya
biasanya environment
staging itu
menyerupai yang di server,
yang di production nggak? Eh, tergantung
sih, kalau yang di production kan udah
distributed ya.
Iya, udah distributed ya.
Iya, iya, iya, iya, iya.
Yang, ideanya kan
begitu ya. Yang dilihat kan
bukan, bukan ini
ya kak, yang dilihat kan bukan
ini lambat, yang produsen
cepat, yang dilihat adalah
kalau setelah push
PR terakhir tiba-tiba dia nge-regress
banyak. Oh iya, regressionnya.
Itu yang di-
nge-compress dari performance sebelumnya.
Jadi kalau misalnya
semua rata, ya sudah.
Berarti ya aman-aman saja sebenarnya.
Ya berarti kayak sebelumnya nggak ada regression.
Nah ini tadi
pertanyaan berbeda-beda.
Bisa beda-beda
gini?
Jadi kayak ada leaderboard gitu ya?
Compare kan?
Itu kayak buat compare competitor
gitu kan yang tadi di
kayak di ram
apa itu tadi kan? Kalo ini kan
sistemnya kan ada board
yang dia visit untuk nge-check
itu kan? Jadi bukan
ada script yang ditanamkan di sana.
Oh jadi ini sebenarnya
webnya milik kita
gitu ya, yang bisa kita tanamkan script
itu ya? Bukan. Ini
bukan. Sistemnya ini
cuma kayak ping, kayak monitoring
kayak ping dom gitu. Ya kayak
speed-speed test kan? Cuma ini
tampilannya
enak ada label-label kolom-kolomnya
gitu. Terus kita bisa ngompar banyak
kan? Jadi kasusnya misalnya kita punya
tokos patu, kita masukin
tokos-tokos patu lain
kan? Competitor. Jadi kita
harus lebih cepet jadi mereka
biar user
lebih suka ke kita.
Setuju-setuju.
Yang kepikirannya adalah gini, ini kan
bisa dibikin kayak leaderboard ya
leaderboard. Kan
seperti yang kita tau bersama
kalo di Indonesia itu biasanya kenapa
banyak perusahaan-perusahaan
lebih memilih
bikin aplikasi
Android ataupun IOS
salah satu alasannya supaya bisa
jadi top global gitu kan.
Ada bintangnya
5, bintang 5
gitu kan. Jadi yang
webnya itu agak kurang
dimaintain. Jadi mereka
salah satunya ya. Menurut saya
pribadi itu salah satunya itu. Karena ada
ada kompetisi
wah ini website kita apa
aplikasi kita harus bagus, harus komennya banyak
itu ada matrik
jadi sebenarnya
sebenarnya matrik
gak penting sih, tapi banyak yang
menganggapnya penting dan menjadi
kurang ukur gitu.
Buat marketing itu penting, buat kita
mungkin gak penting.
Betul. Nah kalo misalkan
ada website, misalkan website seluruh
Indonesia ada leaderboardnya kayak gini kan
FCP-nya bagus. Itu kan
jadi kan orang-orang berlomba-lomba untuk
membaguskan website-nya gitu.
Tapi kalo gitu caranya
bukan dari performance sih
dari jumlah visitor lah
maksudnya kayak apa
App Store, Play Store juga kan
rankingnya selain
misteri algoritm
lebih ke jumlah download sama rating.
Jadi ya maksudnya
kalau kita mau memasarkan ini
sebagai itu tadi
matrik yang valid, gimana caranya
mungkin orang marketing mikir bahwa
matrik performance adalah
matrik yang lebih superior dibanding
jumlah penunjuk, rating dan lain-lain.
Ya bisa dibikin kategori kan
ada berdasarkan penunjuk, berdasarkan
kategori misalkan yang tercepat
Gantung data segregasi
yang kita mau. Tapi ide-nya
menarik tuh. Sebenarnya kalo ada temen-temen
sini startup yang mau
monitoring website government
seluruh di Indonesia
page speed-nya bagaimana
Benar, benar.
Jadi mereka berlomba-lomba untuk bagus ya
Jelek semua
Kalau jelek semua ga dikompetisinya gitu
malah pada tunjuk-tunjukkan lah
itu juga jelek lah, itu dari departemennya
juga jelek
Setidaknya yang tidak paling bawah lah gitu
jadi menghindari bottom gitu
pilih yang terbaik dari yang terjelek gitu
Kok ngomong jelek
padahal siapa tau ada yang
website kemerdekan
Selain page speed
juga harus di deteksi
aksesibilitinya misalnya
Betul.
Semuanya, semua aspek gitu
maksudnya ideal web
standart lah ideal web standart
Ya maksudnya berarti
kualitas kan itu dari kualitas
sejangan kalo apa
App Store dan lalala itu dari
kualitas. Kualitas juga ya
Kumpulkan bahan-bahan
situs department X
Department X
Biasanya business case aja
Jumlah
misalnya
score
speednya sekian
scoring asesibilitasnya
sekian, masih bagus apa engga
jumlah trendernya
misalnya berapa dulu bikin
website-nya, harganya berapa
Boleh
Itu bukan data public
Itu data public, boleh itu
Kalau menurutnya data public
harusnya data publicnya
untuk kita, duit pajak
Berapa harga
berapa uang
yang diterima oleh
yang ngerjain projeknya
itu yang gak boleh
Tapi cost
buat bikin si website itu kan
itu data public
bikinnya sepuluh uang
tapi
itu patah simpira semua
Cukup, itu udah rasanya umum ya
Ya itulah sebenernya intinya
kan
banyak
perusahaan terutama di Indonesia yang mengejar
metric semu tadi gitu
leaderboard, komennya banyak
ratingnya tinggi
gitu kan
yang di lombakan adalah performance kan
siapa tau
ada yang terpantik, wah kayaknya kita harus performance-nya bagus
lihat di atas nih
di atas, apa, leaderboard-nya
ngobrolin web gitu ya
Leaderboard ngobrolin web
power
Itu harus
berarti yang in charge harus
yang kayak kita, yang idealis
Ini kan idealis mode
bahkan kealitas kayak performance
aksesibility
di luar sana, kelihatannya
ya, tapi kayak coba komen
di bawah, munculin deh
bikin aja dulu
Kalau menurut
saya
situs yang
bagus itu adalah situs
yang cepat, yang bisa di akses
oleh kalayak ramai
karena sistem kita
kan keadilan sosial bagi seluruh
rakyat Indonesia
kalau misalnya
situsnya hanya bisa di akses
oleh yang internet, yang cepat kan
nggak adil namanya
tapi sebetulnya
kalau di luar
maksudnya di beberapa negara
ada hukum, beneran ada hukum
tentang, ya bukan performance sih
kalau itu lebih ke aksesibility
tapi bisa hukumnya
performance juga
jadi
selain performance, kualitas
konten, update-nya
dan
kontennya
juga dinilai
nggak boleh masukin
konten yang kacau-kacau
abal-abal, dan
kualitas security apalagi
dan kualitas
aksesibility, jadi banyak
yang luar negeri maksud
saya di sini adalah US Government
dan UK
dan Euro
banyak sih semua negara
negeri, kelihatannya udah
kayak gitu, dan emang
itu udah hukum, udah masuk hukum
jadi kayak, misalnya
kalau kita bikin
kita bikin fasilitas fisik
kayak misalnya gedung, harus ada
apalah, ramp untuk
wheelchair, kursi roda
atau, harus ada pintu
ada label
kayak lift, elevator, atau apa
ada label braille-nya, biar gedung
gedung pemerintah, layanan
publik, harus bisa diakses
sama semua warga negara kan
termasuk yang difabilitas
nah, apa, web
aplikasi web atau aplikasi apapun
nanti punya semua perasarana
digital, juga kayak gitu
harus bisa diakses semua, jadi emang
kalau mau disambung-sambungin ke tadi
keadilan sosial bagi seluruh rakyat
Indonesia, beneran bisa sih itu
in theory bisa
oke
sebelum kita terlalu jauh
mengkritik, kita lanjut
satu buah studi
ini ngasih inspirasi
kritik yang objektif
kritik objektif tidak salah
jadi, cuma saya mau ada
satu yang keren, yang saya mau kasih
ke temen-temen, itu yang soal Nux
commerce, Mas Riza
nah, jadi ya
nah, ini
saya nggak pakai Nux, dan nggak
pakai Shopify, tapi ini adalah
salah satu situs ya
salah satu open source project
yang membuat integrasi
integrasi
Nux dengan
Shopify
jadi headless ya, ini headless
headless, Shopify, terus
di front-end-nya pakai Nux, gitu ya
cepat banget
klik aja dah
luar biasa
udah di preload keliatannya ya
makanya dipencet langsung
instant ke loading
coba-coba pakai
pakai itu harus dilambatkan
iya, sudah saya coba
ke performance ini Mas
ke
ke performance tab
kalau mau cek
performance tab, turun
dibagi sama yang
next step yang
kok gede banget ya
bawa-bawa, itu trottling
trottling
4x slow down
ke bawah
record and reload
wah, seru nih
kok udah 2 detik
iya
ini digerakkan nggak apa-apa kan
digerakkan nggak apa-apa kan
nggak apa-apa, lihat
1,67 sec
dia punya
trottling ya
yang punya content full page
iya
saya mau bongkar
ini kode
mau belajar, saya nggak mau bikin
ada github-nya
udah nggak apa lagi coba
orang GDI
ini GDI yang bikin
iya GDI
GDI web performance yang lain
yang lebih
dewa dari saya
saya nggak dewa
ini dari Nux-nya
dari Nux-nya
yang emang udah banyak fitur-fitur yang memudahkan
improvement performance
atau dia bikin kayak
orang developer-nya
itu saya nggak tahu
yang bikin banyak
custom
mantra-mantra khusus
high performance server
render e-commerce app
built with Nux and Shopify
jadi inget ini
website yang
di review sama Westboss
di Syntax FM
yang website jadul tapi kencang banget
ada yang tahu nggak?
klik BCA
bukan
klik BCA website jadul dan
kencang banget lho
iya tapi Westboss nggak tahu ada klik BCA
tahu-nya
bank central kanada dia
BCC dia
bank central kanada dia
AXS
BCA juga
tapi bank central Amerika
utara
serius tuh
itu masih pakai table lho
tapi cepet
masih pakai table dan cepet kan
ini pertanyaannya apakah
performanya di Shopify-nya
apakah di Nux-nya
kalau nggak harus bilang Nux-nya ya
Shopify di sini kan cuma
Shopify kan API
atau SDK
semacamnya buat nge-fetch
nggak maksudnya
ok, gue ubah ini
pertanyaannya apakah
by default Nux ini udah seperti ini atau harus di-tweak
lagi?
sama pertanyaan gue tadi itu
apakah Nux
menyediakan banyak fitur-fitur yang
kayak udah tinggal apalah misalnya
lazy load di config-nya
lazy load titik 2 true, jadi kita tinggal
2 true aja di config-nya
atau emang si developer-nya
ini emang punya
trik-trik khusus, misalnya banyak custom
code, nulis banyak custom code
buat nge-optimize
yang bisa di pelajari
buka github-nya
bentar
masih penasaran sama website-nya
Westbos
mana ya?
ya nantilah, kalau ketemu
ok, lanjut
dengan central kanada
lanjut, lanjut
apa yang
coba kita bahas lagi
oh github-nya
yang bikin jepet tuh
apa?
emang bisa kelihatan disini?
ada artikalnya nggak?
ada artikalnya nggak?
cek
pakai graph key
pakai graph key
image optimization
itu kan apa?
bisa bantu scripts juga
itu hybrid rendering
coba di
diklik aja
hybrid rendering, image optimization
ini yang kayak versal punya ya?
next ya
apa ini hybrid rendering?
oh ada pre-rendering ya
nah itu kan fitur
dari next ya?
eh bukan
nah iya
fitur dari next
itu kan memudahkan kan
berarti dia bisa
semua yang static bisa di-cache
sampai lama banget
berarti caching ya
maksudnya ada
kompleks caching layer
itu kan ngebantu
terus tadi optimize image
kelihatannya apa? fitur dari next juga ya?
iya
masih penasaran
soal itu yang si wasteboss
iya, masih penasaran bang
central
kanada, nih nih nih nih
ada nih, dapat dapat dapat
namanya make mastercard
itu kan mungkin dari infranya nggak sih
kalau yang kayak gitu
itu website jadul
logiknya berarti nggak banyak
client-side framework, semua server-side
render kan
eh ada suaranya lagi
wey wey wey udah wey
skip
website-nya website jadul
dia nggak pakai client-side framework kan
semua server-lander
ini mah di gedein di infranya kan
berarti
website-nya apa namanya
make mastercard
apa aneh banget namanya
make mastercard
nih, wey
instant loh, instant
ya langsung muncul
HTML simple nggak pakai client-side framework
nggak pakai
apa yang kita cari
mur
apa itu
cepet loh
search-nya mah cepet
iya
makanya ini super
cepat, makanya penasaran
kayak dia, ini nggak pakai
nggak pakai modern front-end
framework loh
iya, jadi asal server-nya kenceng
infranya, makanya mungkin
dia pakai apa itu yang
tapi banyak error ya
apa namanya lupa
yang bisa di deploy
ke macem-macem region
maksudnya gimana
macem-macem region
cdn
edge
deploy-nya di edge kali
jadi front-end-nya
mungkin nggak tau
front-end-nya jadul, tapi
server-nya kapasitas-nya besar
sama infranya
apa, sedekat mungkin
geographically
secara geografis dengan user
ya mungkin ini tebak-tebak buah manggis
aja
nggak ada ya, nggak ada ketahuan ini
pakai framework apa ya
jQuery, jangan-jangan
kayaknya sih
kayak jQuery
pakai ISPX
ISPX
ISPX itu apa?
ISPX
ISP
tuh
ada tuh, dollar
nggak tau nih
jQuery bukan
kalau ada dollar ya harusnya
ya kan semua bisa
dijadikan dollar
jQuery ada tuh
nah tuh ada
sama, iya bener, jQuery
betul sekali
jQuery
jQuery juga bisa, iya-iya emang bisa
siapa bilang nggak bisa, justru itu
cuman apakah kita bisa membuat
website secepat ini dengan jQuery
pasti bisa, cuman
nggak banyak yang melakukan itu kan
kalau sekarang kan kayak, begitu kita
mau bikin aplikasi web, nggak usah bilang
bikin aplikasi web, mau bikin website
mau bikin landing page, udah langsung Next.js
gitu
jadi, gimana ya
ini kan istilahnya tradisional ya
tapi bisa
jauh lebih cepat daripada yang modern
gitu, jadi
ya
harus ditiru, coba throttle
oke
network
slow
disable cache, udah ini udah di throttle
udah di throttle
nggak, harus buka dev tool baru
di reload, baru ke
performance lagi kayak tadi ya
iya boleh
kecilin aja
ini gede banget
oke
terus nggak responsif gitu
iya nggak responsif ya
berarti kita turunin ke bawah
kan tradisional
record in reload
pindah ke kanan
oh ke kanan
dev tools-nya responsif, halamannya
kagak
kan modern versus
tradisional, nah ini
berasa agak lambat ya
iya, ke throttle
tapi begitu
ya karena semua dari server
begitu karena satu
langsung muncul semua kan
paling kiri ada tanda
sebelah button record
sebelah button record
ada tanda pintu
lcp-nya 12,3
lcp-nya turun karena kan server render
ya, cls-nya 0
oh iya ini full server render ya berarti ya
cls-nya 0
jadi dia nungguin servernya ya
kalau kita reload
kedua kali, ngeru nggak sih?
oh caching ya, ini
ini disable caching ya
iya
iya begitulah, oke
kembali ke topik
apa? ada lagi yang mau dibahas? udah kan?
ini yang kita bahas next-nya ya
kira-kira
apa yang membuat website ini cepat
si Nux Commerce
dia kasih tau
ya mungkin hybrid renderingnya itu
pre-fetch sama pre-render itu kali ya
nah
karena ngomong-ngomong soal
pre-fetch dan pre-render, kita liat ini
sedikit sebelum kita tutup, yuk
speculative loading mpi
udah pernah tau kan?
sudah
coba diulang lagi mungkin buat temen-temen yang
belum tau
saya share
screen aja deh
loh eka mana? eka-nya ilang
oh dia belum bayar
billing
kaya
warnet belum bayar billing
gimana sih caranya?
pindah ke tempat saya
remove dulu
present or invite
ada present kan?
yang kalian bawa
present or invite, terus share
saya udah sharing screen, tinggal bawa ke depan
stop screen, udah
nah ini speculative loading mpi
gedein-gedein, zoom-zoom
zoom-zoom
nah
ini adalah
kalau tadi kan Nux
hybrid
rendering ya, nanti kita bisa
bahas yang
kaya tadi ada saya baca
hybrid rendering
yang mana
ini, saya baca tadi pre-render
terus
SWR kalau nggak salah
server
SWR
server web rendering
ini ini ini
add cache to header
server response, disk cache
di
ya bacalah nanti
server side rendering dan segala macam
SWR itu kalau nggak salah
dia kirimkan header supaya di-cache
di CDN
nah
speculative loading
ini kaya hint
type hinting
bentuknya json
json ke
ke browser
untuk kita menyatakan
si
bukan yang ini, speculation rule
ah speculative loading, speculation rule
mpi, kita ngasih tau
browser, page
ini, kita mau
di pre-render
dan page yang ini kita mau di pre-fetch
jadi, dan
kita kasih
kaya hinting seperti ini, hanya
cukup menambahkan ini ke heading
ke head, HTML
nanti si browser yang
yang ini, si browser yang
decide, ya
kita bisa kasih dia
apa namanya
kita bisa ngasih
rule-nya ini
bukan, kita mau bikin dia
sangat
agresif atau
konservatif, itu juga bisa, jadi
karena ada masalahnya begini, kalau kita
terlalu agresif, kita seperti
ngedi-dose server sendiri
kalau misalnya kita bilang
pre-render semua hal amat itu
begitu misalnya page deload
page load, nanti
masa semua link
yang ada di page itu
di pre-render, kan nggak cocok juga
kita bisa ngasih
men-define rule-nya kita sendiri
misalnya untuk button-button yang
CTA, misalnya click to action
button yang click to action
kita bisa ngasih, oke
page-page yang
ada CTA-nya, kita
bisa pre-fetch, atau bisa kita
pre-render, perbedaan antara
pre-fetch dengan pre-render adalah
pre-fetch itu hanya ngambil HTML
disimpan ke cache
sedangkan pre-render
adalah ngambil HTML
disimpan di cache dan di-render
di-jalanin, ya
di-jalanin, sampai java-java itu
di-render tuh
lebih cepat pre-render sebenarnya
tapi lebih resource consuming
lebih intensif, lebih berat
lebih intensif
jadi kita bisa
kita yang nge-define ini
teman-teman bisa coba
menggunakan speculation
rule-API untuk membantu
mempercepat
serasa
instant loading
ya, serasa instant loading
cuma nyolong start aja
bedanya, kenapa
kita menggunakan ini, tidak dengan
framework-framework yang ada, bedanya
ini disupport oleh natif di browser
sedangkan di Next,
di Nuxt, di
yang lain, memang sudah
ada seperti hal ini, yang tadi kita
lihat di rendering mode ini, sebenarnya
mirip seperti ini
routing-nya, mirip
ya, kita sudah dibantu
sama Nuxt, bisa dibantu sama Next
misalnya
cuma yang hal di sini
disupport oleh
browser
ini Chrome only cuman
ini masih Chrome only ya
maksudnya terserah user-agent-nya
sebenarnya, dan sejauh ini
baru Chrome yang ngejalanin dan
itu juga user-agent-nya
nggak mutlak
pasti ngikutin
rules yang kita define kan
dia kan punya logic sendiri, misalnya apa
kalau terlalu banyak halaman yang
kita minta di render, dia bisa
ambil 2 atau 3 halaman pertama
dulu, atau apalah, kan browser
user-agent-nya punya pertimbangan sendiri
dan network speed-lah
atau mungkin CPU-nya kentang
jadi, misalnya processing single-thread aja
sudah kumpulkan, masa
mau buat re-render lagi, nah itu
si find site-nya
si browser-nya yang nentuin
ngikutin rules dari kita atau nggak
betul
saya
ada 1 hal lagi
misalnya
ini bisa digabung juga dengan
document view transition
jadi bisa
bisa membuat situs kita
serasa SPA
kedepannya
nah itu saya mau coba
gali lebih dalam lagi bagaimana
bisa menggabungkan
speculation rule API dengan
document view transition
kayaknya menarik
document view transition
re-render berarti pakai resource dari
client ya, client set
resources ya
pre-render, iya kan
pre-render
sudah device dan dirunning di itu
kalau lagi hemat
quota sebenarnya menghindari hal-hal
seperti ini, user bisa disable nggak ya?
bisa, ini kan
dia cuma kayak
speculation rule, bukan hal
yang mutlu, dia akan menghormati
apa yang sudah ada sebenarnya
yang sudah misalnya kayak
save mode
ada save mode
irit data mode
ada nggak ya?
kalau reduce motion
kan ada
semua hape, semua device
energy saver on
energy saver is on
itu ngaruh ya?
bukan quota saver
Mas Rizal kemarin ada pakai
save mode
atau apa gitu, ada nggak sih yang kayak
reduce motion
reduce motion
itu kan buat animasi
kalau buat irit quota
ada nggak ya? mode irit
quota
perlu digali lagi lebih dalam, misalkan
kita pakai mobile, apakah berpengaruh
dia pakai mobile
dengan desktop, tentunya
kalau mobile pasti asumsinya
adalah kita menggunakan paket data
sedangkan kalau di laptop
kan bisa kita pakai
bisa, tapi
asumsinya
terus apakah ada perbedaan antara
pada saat diakses
di mobile sama diakses di desktop
terus juga kalau misalkan ada
yang tadi settingan kayak
energy saver
atau kenapa?
ya kalau battery saving
biasanya ada
kalau network
setitinya, misalnya networknya lambat
slow network atau nggak, browser juga udah
punya cara untuk tau kan
kalau user lagi
mau irit quota
is the spec full of
user configuration, for example
privacy doesn't happen when the user device
is in battery saver
battery saver or data saver
berarti aman ya
bisa di disable ya, maksudnya di disable
dengan cara
nge-set battery saver ya
atau data saver ya
maksudnya tergantung device
OS dan device
user
ada informasi data saver atau nggak
kalau emang ada, si browsernya bisa
mengakses itu ya
nah kalau Google Pixel
ada nih
iseng banget nyari, ada
data saver
ada, ada data saver kayaknya ada
di setting ya, apa gimana?
tergantung device ya
iya tergantung device, cuma kalau ini
ada contohnya, di Google Pixel
ada emang ada tombolnya
data saver mode, nah kalau itu aktif
si browser bisa
menghormati
Mas Denang
Mas Denang lihat, udah hanyu, udah hanyu
udah hanyu guys
tenang Mas Denang, ini masuk adfoku
khusus request Ivan buat
dimasukin ke adfoku
topik malam ini
itu kan jadi awkward kan
tapi
saya mau coba
explore itu tadi
spekulasi API
dan document view transition
bagaimana sih jadi supaya
SPA, seperti SPA ya
SPA, MPA rasa SPA
multi-page application
rasa single-page application
semoga hal ini
masuk ke topik
IOX, jadi saya bisa bawain
topik ini
wah udah nicil duluan ya
tapi kalau di framework
di meta framework, sebetulnya
udah diimplement sih itu, kayak kalau
yang di Next.js
terus di Swellkit
itu kan punya
tempat-tempat yang punya link
apa, link komponen sendiri, itu
kita hover, mouse over
itu di prefetch
nah maksud saya, indikasinya kalau user mouse over
atau kalau di mobile
user, apa, on click
gini, itu kan sebetulnya
belum jalan, sampai di
user click lagi
begitu itu, apa
on mouse down ya
eh, on, ya itulah, on touch
atau apa, itu di prefetch, pokoknya
sebenernya kalau di meta framework sih
udah draft-in itu, kalau di gabung
view transition emang udah
terasa SPA banget
di astro juga, itu udah
ada yang bikin juga, jadi kalau di ranah
meta framework, emang itu
udah kayak domoe standar malah
cuma kalau vanilla jarang sih
bisa dicoba, bisa dicoba, dengan
bantuan speculation rules
mungkin bisa
kesana
seperti, kayak instant loading
kan, sebenernya bukan SPA
kan, jadi instant loading aja
seolah-olah
jadi kayak SPA, kalau di gabung sama
view transition tadi yang Ivan bilang
dari user perspektifnya itu
rasa, rasanya
feel-nya, feel SPA
iya, kan salah satu
keunggulannya SPA kan
developer user experience-nya kan
bagus ya, jadi kayak nggak perlu loading
page
smooth ya
jadi
apa namanya
kita bisa berada di tengah-tengah, kita
bisa punya aplikasi yang multi-page application
tapi rasanya seperti punya
aplikasi SPA
oke, cukup untuk
malam ini
topik selanjutnya apa? Terima kasih banyak
untuk komen-komen topik selanjutnya
beneran google gitu, begitu masa enak-enak
iya dong, itu adalah
pertanda
tidak, tidak, tidak
kita mau bahas topik
pembahasan buat minggu depan
loh, kok nggak ada? Oh iya, belum di share lagi ya
ulang share ya
sebentar
react server komponen apa?
react server komponen mau?
RCS mau? Boleh?
voting aja
RSC sama apa itu
apa lagi?
oke
pembahasan buat minggu depan
topik
untuk minggu depan
react
server komponen
terus apa lagi?
kita berdasarkan apa nih?
berdasarkan all
database scaling nanti
udah ngontek mas
Donny, dia mau ngisi
nanti sekitar bulan Juni katanya
terus
apa ya, bahas apa?
semantik versioning
licensing
CICD
udah ya? kita udah pernah bahas CICD
belum?
links
oh
tapi kalau links kita belum
pernah ada yang ngulik sih
mungkin itu masuk
ke bedah framework ya
mungkin Bayu bisa masukin
ke discussion
siapa tahu
banyak yang
tertarik untuk bahas
kompetitornya react native ya
kompetitornya react native
itu dong testing
dengan playwright kayaknya seru tuh
playwright ya
playwright
salah tulisannya
playwright
oke, ada lagi?
papa petir
papa petir
papa petir
atau end-to-end testing
bahas end-to-end testing
end-to-end testing
bukannya itu playwright ya?
ya sekalian ya
ya maksud saya, playwright itu kan
salah satu contoh end-to-end testing
ya udah, kita intro aja
end-to-end testing
dua aja nih
dua aja ya pilihannya ya
ada lagi nggak?
original
ah itu aja pengalaman horror
itu mau dibahas ini ya
tapi harus dikumpulkan dulu
oh iya
iya nanti dibikinin
pdf css
itu apa pdf css?
css dpds
CLI mau CLI design?
boleh boleh
CLI design ya
udah tiga itu aja
kaisa pdf css itu
stress
silahkan di vote
temen-temen di youtube
yang ada di link-in boleh ke youtube dulu
untuk vote
oh link-in nggak bisa nge-vote ya
nggak bisa, nggak bisa comment
nggak bisa comment, nggak bisa vote
eh cuma jadi dapet ide tuh?
bisa, penonton yang comment
kita nggak bisa lempar comment gitu
nggak, dan nggak bisa
nge-click voting
yang kayak gitu
nggak ada fitur vote
jadi dapet ide itu tadi pdf
pdf itu kan sebenernya bisa
pake css dan ternyata
ke accessibility tadi
WCAG itu ada standarnya juga
buat pdf
itu kalau yang misalnya apa
instansi pemerintah
atau apa di negara-negara yang
punya aturan tentang accessibility
bukan cuma
aplikasi web atau natif doang
yang harus ikut WCAG
tapi semua pdf-nya juga
oh iya iya iya
kan ada ini juga loh
di pdf itu
bisa ada link juga loh
kayak.. dia
eh kalau misalkan nih
kita punya
kenapa?
kalau misalkan
misalkan kita punya
halaman yang
kita mau print atau mau
jadikan pdf itu bisa minta
bantuan LLM nggak sih?
jadi ini adalah halaman HTML
tolong jadikan pdf
bisa nggak ya? nggak ada yang bisa
generate dan empat
generate image mau bisa
generate video bisa pake film
oh mungkin dia akan jadi image ya
kan ada tuh
apa? yang bisa
apa? memanipulasi
struk belanja kan ada kan?
jadi mungkin jadi image ya
dari apa?
dari halaman HTML dia jadi image aja
png terus ditaro pdf gitu kan bisa juga
kan? cuma nggak aksesibel kan?
nggak aksesibel
cuma bisa kalau buat di print tadi
use case nya buat di chat juga bisa-bisa aja
pdf hanya support di CSS2?
iya ya
iya
admin
langsung di kick kalau gitu
iya pdf itu hanya support CSS2.0
jadi LLWM mau
apa pun
jadi pake CSS2.0
kayak ini ya jadinya ya?
CSS2.0 gue lupa nih la CSS
pake email ya
wah ini imbang nih
RSC sama end to end
testing 44%
ekstra time kasih ekstra time
ayo satu orang lagi
ayo please
HTML bisa print lewat browser
jadi pdf oh iya bisa-bisa
saya mau tunjukin
ini saya boleh nggak?
boleh
mau ini apa namanya?
mau show off
show off
mau menunjukin itu sleep gaji
showcase
oh nggak show off kok gitu ya
itu kan NDA sih
oh NDA
buat bikin foto hiburan lah kalau gitu
asik
coba-coba test
saya udah share screen
ah? jadi udah?
remove dulu udah
terus tambahnya gimana?
ini cool screennya Yvan
ini udah
jadi saya bikin ini
contohnya
oh ini project client
iya
jadi pake WordPress
block editor
dan ini kan
kontennya
jadi si user buat
konten pake block editor
jadinya HTML
terus pdfnya jadi di create juga
wow
wow
ini pake apa?
iya beda
pake tcpd
oh
yang keren tuh yang ini
jadi kalau ke global market
outlook
jadi ada banyak template
jangan salahkan saya kenapa begini
mereka yang pd gambar
jadi
image yang mereka
pakai disini akan
dipakai sebagai cover ini
terus yang
konten yang ada disini
dirubah jadi konten yang ada
disini
terus ada table of content
keren banget
bisa diklik ya
iya
iya iya
di tengah-tengah
contohnya
ini kaya gini
ya kan itu aja cuman
upload satu image begini
itu
eh salah
wow
sebenernya datanya sama kiri kanan
iya tapi layoutnya
berbeda
layoutnya berbeda
sesuai layout pdf
WordPress
jadi
keberhasilan saya
membuat mereka
save a lot of money
karena dulunya mereka harus
tulis pdfnya dulu
eh sorry dokumennya dulu
kirimkan ke agensi
untuk dicantikin
terus bolak-balik
ya bolak-balik untuk
vc segala macem
setelah dokumen jadi
jadi pdf baru pdf dirubah
lagi jadi html
jadi banyak langkahnya
jadi mereka telat sedangkan
kalau kaya daily navigator begini
ya kalau market keburu
keburu angelok dulu
nilai sahamnya
kalau daily navigator kan tiap hari nih
masa harus bolak-balik begitu
keburu berubah semua
kita bikin terus begini mereka
save banyak money
ini project saya 2 tahun lalu
yang kerennya lagi
saya mau show off luar biasa
support
yang paling susah
dari project ini adalah
image uploader
yang paling susah
dari image uploader
adalah
multilingual
simple fight Chinese sama traditional Chinese
support
ini berarti
programmable ya
bukan
di edit pakai
akrobat gitu bukan ya
ini langsung di generate
jadi mereka kalau misalnya update
update konten di
ka update juga pdfnya ya
pdf nya akan di upload
ulang otomatis
ada ini lagi ada
ada slugnya
bahasanya
dan ini font dari
fontnya mereka
dan ini susah
plus mereka
memotong-motong karena disimplify
Chinese dan traditional Chinese tuh gak ada spasi
formatting nya lain ya
ya formattingnya susah
ya suatu saat kita bahas inilah
jadi kalau temen-temen
di kantor nya butuh
pencetakan laporan seperti yang
keren tadi bisa kontak ngobrolin web ya
kita menerima
kita menerima jasa konsultasi
konsultasi dan
pembuatan laporan berbasis
save a lot of money
oke ini
sudah ada pemenang
pemenang nya adalah react server komponen
jadi minggu depan
kita akan bahas tentang RSK
atau react server komponen dan bagaimana dampaknya
terhadap framework-framework yang lain
oke untuk malam ini sekian
dulu terima kasih banyak buat semuanya
jangan lupa kalau ada yang
mau diskusi atau mau
sudah ada itu pakai apa itu buat
yang pakai ini ya
markie
bisa
sana.in/ngobrolinweb
di luar
live streaming kita bisa diskusi
bisa saran
topic juga
udah cukup untuk malam ini
boleh undang dan abramov
boleh
dipanggil
mas undang dan mas
abramov ya
boleh undang
dan abramov
sedih
dan nya tuh end maksudnya tapi
gak masuk belum besok ke gue lagi
boleh
undang dan abramov
boleh sih
tapi
dia nya gak mau
kita nya boleh
dia nya mau atau gak ya
coba di
bisa bisa
di colek lah di social media
dateng dong ke
ngobrolinweb gitu
mas dan
sekian dulu untuk malam ini
terima kasih banyak buat semuanya
kita ketemu lagi minggu depan
topiknya react server component ditunggu
di selasa malam
selamat malam
selamat istirahat bye bye
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://ksana.in/ngobrolinweb 🎙️ New to streaming or looking to level up? Check out StreamYard and get $10 discount! 😍 https://streamyard.com/pal/d/5512398643920896 Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
2 Agu 2023
Ngobrolin Privacy Sandbox
Privacy Sandbox dibahas bukan sebagai wacana melainkan sesuatu yang harus disiapkan dari sekarang, karena dampaknya bisa...
19 Apr 2023
Ngobrolin CMS
Content management system dibahas sebagai kelanjutan alami dari episode-episode sebelumnya soal cara halaman dirender. C...
22 Apr 2026
Scam dan Penipuan
Episode ini membahas scam dan penipuan digital yang makin marak, dengan penekanan bahwa celah utamanya hampir selalu soc...
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 .