Sayudha

57 Performance Dasar, Metrik, dan Cara Ngukur

Properties2
descriptionKenapa performa penting, lima metrik (TTFB, FCP, LCP, CLS, INP) dan Core Web Vitals, apa yang platform Shopify udah urus (CDN, minifikasi, SFR, speculation rules, polyfill, batas paginasi), field vs lab data dan alatnya, benchmark Theme Store dengan Lighthouse, debugging lewat gap metrik, praktik performa berkelanjutan, dan peta delapan bab performa
tagsshopify, theme, performa

19 menit baca

Prinsip pertama theme dari 54 Best Practices Umum itu performa. Shopify nulis 67 halaman soal ini, yang kita bagi jadi delapan bab. Bab ini fondasinya: apa yang diukur, siapa yang ngukur, dan gimana bacanya, sebelum kita optimasi apa-apa.

Performa itu kunci sukses merchant dan pengalaman pembelinya. Toko yang lambat kehilangan penjualan (tiap detik LCP nambah bounce), dan sejak Core Web Vitals jadi sinyal ranking Google, toko yang lambat juga lebih susah ditemukan. Buat theme yang mau masuk Theme Store, ada skor minimum yang harus dilewati (70 Theme Store Gambaran dan Requirements).

Lima Metrik

Metrik yang dipakai sepanjang bagian ini, kira-kira urut sesuai kejadiannya waktu halaman dimuat:

  1. TTFB (Time to First Byte): berapa lama browser nunggu byte pertama respons HTML. Di storefront Shopify, sebagian besar waktu ini adalah Shopify ngerender Liquid kamu, jadi TTFB itu metrik yang digerakin kerja sisi server. Gak ada yang bisa mulai sebelum respons datang.
  2. FCP (First Contentful Paint): kapan browser ngegambar teks atau gambar pertama. Stylesheet dan script yang ngeblokir render di <head> itu penyebab umumnya telat.
  3. LCP (Largest Contentful Paint): kapan elemen terbesar di viewport awal selesai dirender, biasanya gambar hero atau produk. Ini metrik yang paling dekat sama kecepatan yang dirasain pengguna.
  4. CLS (Cumulative Layout Shift): seberapa banyak konten yang kelihatan bergeser tak terduga waktu halaman dimuat. Gambar tanpa dimensi, font yang swap telat, dan konten yang disuntik app itu penyebab umumnya.
  5. INP (Interaction to Next Paint): berapa lama halaman merespons secara visual setelah ketukan atau klik. Kerja di main thread, biasanya JavaScript, yang bikin ini lambat.

LCP, CLS, dan INP itu Core Web Vitals (CWV) yang dipakai Google sebagai sinyal ranking. TTFB dan FCP gak dinilai, tapi diagnostik: LCP lambat dengan TTFB lambat nunjuk ke Liquid kamu, LCP lambat dengan TTFB sehat nunjuk ke kerja sisi browser setelahnya. Cara bacanya di bagian gap metrik di bawah.

Apa yang Platform Udah Urus

Sebelum optimasi, penting tau apa yang Shopify udah kerjain otomatis buat semua storefront, biar gak duplikasi usaha:

1. CDN

CDN kelas dunia yang didukung Cloudflare, jadi toko dimuat cepat di seluruh dunia. File yang dikirim lewat CDN otomatis di-minify dan dikompres pakai Brotli dan gzip, dan request pakai HTTP/3 dan TLS 1.3.

URL aset storefront pakai path /cdn di domain yang sama dengan halamannya: /cdn/shop/files/hero.jpg buat file toko, /cdn/fonts/ buat font library. URL same-origin memaksimalkan penggunaan ulang koneksi di browser. Jadi jangan hardcode cdn.shopify.com, pakai filter asset_url dan image_url dari 19 Filters HTML, URL, Media, Color, dan Font, Shopify yang ngerender host yang tepat per request.

Versioning otomatis: gambar di-cache di ribuan server. Waktu kamu ngubah gambar, Shopify ngasih tau CDN lewat nomor versi yang asset_url tambahin ke URL (?v=1384022871). Kalau kamu ngelink gambar tanpa asset_url dan upload versi baru, gambar di toko bisa gak berubah selama sehari atau lebih. Dan cuma parameter v yang dikenali buat versioning, timestamp mentah atau nama parameter lain gak nembus cache. Buat gambar di CSS, ini artinya:

❌ statis, gak pernah update

background: url(bg.gif);

✅ berversi (di file .css.liquid)

background: url({{ 'bg.gif' | asset_url }});

2. Server-side Rendering

Storefront Renderer (SFR) itu renderer sisi server yang didedikasikan buat ngelayanin request storefront secepat mungkin, dan secara signifikan ningkatin performa cache miss (halaman yang gak ada di cache dan harus diambil dari level cache lain atau memori utama).

3. Minifikasi

Shopify otomatis minifikasi file CSS, dan file JavaScript yang sintaksnya valid sampai ES5, waktu diminta storefront. Hasilnya di-cache sampai file diupdate. File asli dikirim kalau: hasil minifikasi malah lebih besar (udah di-minify lebih baik), atau ekstensinya .min.js/.min.css. Trik: minifikasi bisa ngehapus debugger, jadi buat debug, sementara ganti ekstensi ke .min.js.

4. Speculation Rules

Shopify otomatis nyuntik speculation rules di browser yang ndukung, buat prefetch/prerender halaman berikutnya. Aturan default-nya ngasih percepatan terbesar tanpa masalah pemakaian data, cache, atau analitik. Theme bisa nambah aturan sendiri, dibahas di 64 Performance Navigasi dan Loading.

5. Polyfill

Shopify otomatis nyertain es-module-shims waktu dibutuhin, polyfill buat fitur modul JavaScript modern, terutama import maps. Jadi kamu bisa pakai <script type="importmap"> dan <script type="module"> tanpa ngurus kompatibilitas browser lama. Jangan load es-module-shims sendiri, bisa konflik dan overhead.

6. Batas Paginasi

Shopify membatasi paginasi ke 25.000 object. Paginasi dalam ke array besar itu mahal dan bisa ngelambatin request lain. Batas ini juga berlaku buat count: akurat sampai 25.000, di atasnya ngembaliin 25.001 sebagai penanda “lebih dari 25.000”. Kalau kamu kena batas ini, itu tanda desainnya perlu filter (37 Filtering) biar pembeli nyempitin dulu sebelum paging.

Field Data vs Lab Data

Dua jenis data buat ngukur performa:

  1. Field data (data lapangan): apa yang pengguna nyata alami, dari berbagai perangkat, jaringan, dan lokasi, ditangkap lewat RUM (Real User Monitoring).
  2. Lab data: tes sintetis tunggal yang terkontrol di lingkungan konsisten, sebagai snapshot detail.

Aturan mainnya: field data buat nemuin masalah, lab data buat debug, field data lagi buat verifikasi perbaikannya beneran mendarat.

Satu bias yang harus diingat: analitik dan RUM cuma nyakup pengguna yang berhasil ngeload halaman. Pengguna dengan koneksi sangat lambat atau perangkat tua mungkin udah pergi sebelum script analitik jalan (survivorship bias). Jadi “rata-rata” pengguna kamu sering lebih cepat dari rata-rata sebenarnya.

1. Sumber Field Data

  1. Shopify Web Performance Dashboard di admin: RUM privat toko kamu, ngelaporin LCP, INP, CLS per tipe halaman, kategori perangkat, dan wilayah. Datanya dari pengguna Chrome yang opt-in. Buat baseline, deteksi regresi setelah deploy atau install app, nemuin segmen terburuk, dan verifikasi optimasi. Storefront Hydrogen butuh integrasi analitik dulu.
  2. CrUX (Chrome User Experience Report): RUM publik dari pengguna Chrome, diagregasi per origin. Ini sumber data PageSpeed Insights dan laporan Core Web Vitals di Google Search Console. Bisa dipakai buat benchmark kompetitor. Ngelaporin persentil ke-75 dalam jendela 28 hari bergulir, jadi perbaikan butuh berminggu-minggu buat kelihatan penuh, dan halaman trafik rendah bisa gak punya data. TREO Site Speed antarmuka yang nyaman buat ngeksplor CrUX domain manapun.
  3. RUM pihak ketiga (SpeedCurve, New Relic): dimensi kustom, alerting, retensi lebih lama, korelasi sama metrik bisnis. Tapi nambah script ke storefront, jadi hitung bobotnya.
  4. GraphQL Admin API (unstable aja, bisa berubah): field performanceMetrics (RUM per tipe perangkat) dan performanceEvents (event yang ngaruh performa: install app, publish theme), buat dashboard kustom dan alert:
query StorefrontPerformance {
  performanceMetrics(aggregationLevel: DAILY, deviceTypes: [MOBILE], maxDays: 30) {
    deviceType
    metrics
  }
  performanceEvents(maxDays: 30) {
    type
    occurrence
    metadata
  }
}

CrUX dan RUM sendiri ngukur pengguna yang sama tapi bukan populasi yang sama (CrUX cuma Chrome opt-in, p75, lag berminggu). Perbedaan antara keduanya itu wajar, pilih satu dan pakai konsisten waktu ngelacak perubahan.

2. Sumber Lab Data

  1. WebPageTest: alat pilihan performance engineer, analisis detail: waterfall, filmstrip, tes dari perangkat/koneksi/lokasi tertentu. Alat yang tepat buat mendiagnosis rantai request storefront yang lambat termasuk script app, domain pihak ketiga, dan proxy di depan CDN. Jalankan dari lokasi tempat pelanggan nyata berada.
  2. Chrome DevTools: buat development dan debug lokal.
  3. Lighthouse dan PageSpeed Insights: audit level tinggi dan daftar peluang, plus benchmark Theme Store. Mode mobile default-nya pakai throttling jaringan dan CPU yang gak cocok sama campuran pengunjung nyata kamu.

3. Kapan Pakai Mana

RUM kalau: mau tau pengalaman nyata, butuh baseline sebelum/sesudah, ngambil keputusan strategis soal apa yang dioptimasi, verifikasi perubahan. Lighthouse kalau: debug masalah spesifik, butuh pengukuran berulang yang bisa dibandingin selama development, cek otomatis di CI/CD sebelum merge, atau RUM gak cukup (toko baru, trafik rendah, dev store).

Aturan singkatnya: belum tau apa yang lambat → field. Tau apa yang lambat tapi gak tau kenapa → lab. Udah ship perubahan → balik ke field dan tunggu jendela pelaporannya.

4. Waktu Lab dan Field Gak Sepakat

Ketidaksepakatan itu normal, biasanya karena beda apa yang diukur, bukan alat yang rusak. Cari tau populasi mana yang tiap angka gambarin.

Lab bagus, field buruk:

  1. Campuran perangkat: lab jalan di satu profil perangkat, trafik nyata mencakup bertahun-tahun hardware ponsel, dan biaya JavaScript dan render skala sama CPU. Storefront yang cepat di flagship bisa gagal LCP di ponsel murah. Segmentasi RUM per kategori perangkat dulu.
  2. Geografi: tes dari datacenter dekat pelanggan nyembunyiin latensi pelanggan jauh. Cek breakdown wilayah di RUM, ulangi lab dari wilayah terlambat.
  3. State cache: lab biasanya cold first-view, trafik nyata campuran cold dan warm. Kalau lab-nya warm dan pengunjung cold, angka lab optimis.
  4. Variabilitas nyata: pengguna scroll, tap, ganti tab, buka di in-app browser dengan script yang disuntik. INP gak punya padanan lab karena bergantung interaksi nyata.

Field bagus, lab buruk:

  1. Parameter tes: pastiin throttling, emulasi perangkat, dan lokasi cocok sama trafik nyata, bukan kasus terburuk yang gak kamu layani.
  2. Trafik bot dan sintetis: uptime monitor dan scraper gak muncul di RUM, dan sebaliknya, jangan baca angka alat monitoring sebagai pengalaman pelanggan.
  3. Noise satu run: satu run lab itu satu sampel, ambil median beberapa run sebelum percaya ada regresi.
  4. Jendela sampel: field itu agregat, lambat bergerak. Regresi kemarin bisa gak kelihatan di jendela 28 hari CrUX, dan perbaikan bisa kelihatan gak ngefek. Bandingin jendela yang setara, dan pakai RUM sendiri buat yang butuh cepat.

Kalau dua-duanya sepakat metriknya buruk, perbaiki. Kalau cuma satu, cari perbedaan populasinya dulu sebelum ngabisin waktu engineering.

Benchmark Theme Store

Shopify ngevaluasi kiriman Theme Store terhadap toko benchmark biar skornya konsisten dan bisa dibandingin. Kamu bisa jalanin benchmark yang sama:

  1. Bikin dev store baru di Partner account, terpisah dari toko produksi.
  2. Impor produk uji dari CSV standar Shopify lewat Products > Import, biar data produknya sama dengan evaluasi resmi dan performa theme terisolasi dari variabel konten toko.
  3. Ambil link preview: klik ikon mata di samping Online Store, terus ikon link di bar preview, dapat URL shopifypreview.com yang bisa diakses Lighthouse tanpa password toko.
  4. URL tiga halaman: home, satu halaman produk, satu halaman koleksi, misalnya https://12345678.shopifypreview.com/products/sunglasses.
  5. Tambahin ?pb=0 (preview bar off) ke tiap URL biar bar preview gak ngerusak hasil.
  6. Jalankan Lighthouse di tiap URL: Chrome Incognito (tanpa ekstensi), minimal tiga kali dan ambil median, perangkat dan jaringan yang sama. Lewat DevTools tab Lighthouse, CLI npx lighthouse {url} --output json, atau PageSpeed Insights. Catat Performance score (0–100).
  7. Hitung speed score berbobot: home 17%, produk 40%, koleksi 43%. Bobotnya mencerminkan kepentingan tiap halaman buat konversi merchant.

Tapi skor berbobot bukan ambang Theme Store. Syarat penerimaannya: rata-rata biasa skor Lighthouse performa minimal 60 di produk, koleksi, dan home, di desktop dan mobile. Pakai skor berbobot buat lihat gimana perubahan ngegerakin halaman yang penting, dan rata-rata biasa buat cek lolos atau gak.

Peringatan: satu run Lighthouse bisa beda 5–10 poin karena variabilitas CPU dan jaringan. Jangan ambil keputusan dari satu run.

Lighthouse CI

Lighthouse CI (LHCI) ngotomatisasi audit di tiap pull request, nyegah regresi sebelum produksi. Shopify nyediain GitHub Action resmi yang: ngejalanin Lighthouse terhadap preview theme di tiap PR, ngomentarin perubahan skor di PR-nya, dan bisa nggagalin CI kalau skor turun di bawah ambang. Setup-nya lewat .github/workflows/lighthouse.yml, dibahas di 68 Theme Inspector dan Lighthouse CI.

Waktu CI ngelaporin skor turun: cek apakah regresinya di lab atau di data nyata (regresi lab gak selalu kelihatan pengguna), identifikasi metrik mana (LCP, TBT, CLS), pakai analisis gap di bawah, dan revert atau perbaiki sebelum merge.

Debugging Lewat Gap Metrik

Kata tim Performa Shopify: “Langkah pertama debug situs lambat bukan buka alat lab. Lihat data RUM dulu buat nemuin dan memprioritaskan peluang terbesar.” TTFB, FCP, dan LCP punya titik awal yang sama (navigation start), jadi gap di antara mereka ngungkap di mana masalahnya terkonsentrasi.

1. Caranya

  1. Pilih satu tipe halaman dan satu kategori perangkat. Home di mobile dan produk di desktop itu masalah berbeda dengan perbaikan berbeda.
  2. Baca TTFB, FCP, LCP segmen itu di persentil yang sama (Web Performance Dashboard buat toko sendiri, TREO/PageSpeed Insights buat CrUX domain publik, tampilan Distributions yang nampilin bar hijau/kuning/merah).
  3. Kurangkan jadi tiga gap: TTFB sendiri, FCP − TTFB, LCP − FCP.
  4. Ambil gap terbesar sebagai fase tersangka, cocokkan sama pola di bawah.
  5. Reproduksi fase itu di lab (WebPageTest atau panel Performance DevTools) dengan perangkat, koneksi, dan lokasi yang mirip segmen itu, baca waterfall cuma buat fase itu.
  6. Perbaiki satu hal, konfirmasi gap-nya nutup di field, baru lanjut ke fase berikutnya.

Kalau gak ada field data (halaman baru atau trafik rendah), ukur di lab tapi anggap angkanya hipotesis, bukan baseline.

2. Empat Pola

|--->|   time spent in a phase
TTFB     the first byte of the HTML document arrives
FCP      the first content is painted
LCP      the largest content is painted

Pola 1: TTFB lambat, FCP dan LCP cepat sesudahnya

navigation                                        TTFB  FCP  LCP
|------------- waiting on the server --------------->|--->|--->|

Masalahnya di respons server atau render Liquid yang kompleks. Penyebab umum: Liquid mahal (loop bersarang dalam, filter/metafield di dalam loop, render bersarang), overfetching (paginasi terlalu dalam, ngeload semua varian padahal cuma satu yang tampil), proxy di depan CDN Shopify, app proxy atau logika app di jalur request. Bab yang relevan: 58 Performance Liquid dan 63 Performance Apps dan Pihak Ketiga.

Pola 2: TTFB cepat, FCP lambat

navigation    TTFB                                   FCP  LCP
|-------------->|--- rendering blocked or delayed ---->|--->|

HTML datang cepat tapi ada yang menghalangi paint pertama: stylesheet dan script sinkron yang ngeblokir render di theme.liquid (termasuk tag yang disuntik app), anti-flicker snippet A/B testing yang sengaja nyembunyiin halaman, terlalu banyak stylesheet terpisah, DOM besar sebelum paint pertama (mega menu yang diduplikasi buat mobile dan desktop), request blocking ke origin pihak ketiga yang butuh DNS/TLS/koneksi baru. Bab: 60 Performance CSS dan Font, 61 Performance JavaScript dan INP, 63 Performance Apps dan Pihak Ketiga.

Pola 3: TTFB dan FCP cepat, LCP lambat

navigation    TTFB    FCP                                 LCP
|-------------->|----->|--- LCP element discovered and --->|
                          loaded late, or revealed late

Halaman ngegambar sesuatu dengan cepat tapi elemen terbesar telat. Pecah jadi dua: browser nemuin resource-nya telat (masalah discovery) atau nemuin tepat waktu tapi nampilinnya telat (masalah render). Penyebab umum: gambar LCP pakai loading="lazy" (sering dari setting theme yang lazy-load semuanya), gambar LCP itu CSS background (preload scanner gak bisa nemuin sampai stylesheet di-parse), JavaScript yang ngerender elemen LCP atau Section Rendering API yang ngambilnya setelah paint awal, fade-in/carousel/animasi scroll yang nyembunyiin gambar setelah di-download, dialog/cookie banner/email capture yang jadi elemen LCP, gambar jauh lebih besar dari ruangnya karena tanpa widths/sizes. Bab: 59 Performance Gambar dan LCP.

Pola 4: Banyak gap

navigation                     TTFB            FCP        LCP
|---- slow server -------------->|-- blocked --->|-- late -->|

Banyak masalah. Prioritas: perbaiki FCP dulu karena juga ngaruh ke LCP, kecuali ada masalah LCP yang jelas dan gampang (lazy-load gambar LCP), itu duluan. Dan kalau semua fase lambat, curigai satu penyebab yang menjangkau semuanya sebelum ngerencanain tiga proyek: proxy di depan CDN, script berat yang dimuat semua halaman, atau alat pihak ketiga yang ngeblokir render dan nunda gambar. Audit yang dibagi semua tipe halaman dulu.

Praktik Performa Berkelanjutan

Performa itu praktik berkelanjutan, bukan proyek sekali jalan. Situs gak statis: fitur, app, dan konten menumpuk, dan performa alami menurun. Tanpa proses berulang dan kepemilikan jelas, perbaikan dari audit sekali bakal regresi dalam hitungan bulan.

1. Pola Regresi

Hampir semua inisiatif performa ngikutin busur yang sama: audit dan perbaikan teknis → metrik membaik, proyek dianggap sukses → tim pindah prioritas, performa gak dikelola → dalam beberapa bulan, balik ke semula atau lebih buruk. Siklus ini berulang karena performa diperlakukan sebagai bug buat diperbaiki, bukan praktik buat dirawat.

Penyebab regresinya: fitur baru (lebih banyak kode, gambar, script), perubahan desain (gambar lebih besar, animasi kompleks, lebih banyak DOM), app baru (tiap app bisa nambah JavaScript pihak ketiga yang bersaing di main thread), update konten (gambar gak dioptimasi, tracking script berat), dan gak ada pemilik. Hasilnya “death by a thousand cuts”: gak ada satu perubahan yang ngerusak, tapi akumulasinya iya.

Contoh nyatanya: marketing nambah tracking pixel tiap bulan, enam bulan kemudian ada 15 script pihak ketiga dan LCP regresi 2 detik. Merchant install app yang nyuntik JavaScript ke semua halaman termasuk yang gak butuh. Kampanye liburan nambah countdown, pop-up, dan chat widget, kampanye selesai tapi gak ada yang ngehapus script-nya. Redesign upload hero 3MB padahal 200KB kelihatan sama.

2. Siklus Perbaikan

  1. Ukur dan identifikasi: RUM buat peluang terbesar, analisis gap, prioritas berdasarkan dampak ke pengguna (bukan yang termudah), segmentasi tipe halaman/perangkat/geografi.
  2. Riset dan eksperimen: cari solusi, rumuskan hipotesis tiap perubahan, implementasi eksperimental di lingkungan development.
  3. Tes dan validasi: WebPageTest, perbandingan sebelum/sesudah pakai median beberapa run, konfirmasi perbaikannya sesuai harapan sebelum deploy.
  4. Implementasi: deploy cuma yang terbukti membaik di lab, buang yang gak ngefek atau memburuk, dokumentasikan.
  5. Monitor dan verifikasi: tunggu RUM cukup (hari sampai minggu tergantung trafik), verifikasi pengguna nyata ngerasain perbaikannya, cek efek samping ke metrik atau tujuan bisnis lain, bagikan hasilnya.

Contoh satu putaran: RUM nunjukin LCP produk regresi dari 2,1s ke 3,4s dalam dua minggu, berkorelasi sama lonjakan Total Blocking Time → segmentasi: mobile di halaman produk, waterfall WebPageTest nunjukin script pihak ketiga baru yang dimuat sinkron di <head> → dilacak ke app yang baru diinstall, cek apakah app nyediain async atau cuma butuh di halaman tertentu → di development, defer script-nya, WebPageTest konfirmasi LCP balik ke baseline di median beberapa run → deploy → seminggu kemudian RUM konfirmasi LCP balik ~2,1s tanpa efek samping.

3. Keselarasan Organisasi

Performa itu masalah lintas fungsi: Development, Design, Marketing, Product semua bikin keputusan yang ngaruh. Buat agency dan theme developer, ini berarti mengadvokasi struktur sadar performa ke klien:

  1. Champion: seseorang yang memiliki performa sebagai tanggung jawab, ngelacak metrik, ngangkat regresi, koordinasi lintas tim, dengan wewenang dan waktu. Di tim kecil, senior developer yang nambahin monitoring ke workflow rutinnya.
  2. Tim lintas fungsi kecil dari Development, Design, Marketing buat ngevaluasi trade-off kecepatan vs fitur vs bisnis. Gak perlu rapat terus, check-in rutin waktu ada pekerjaan aktif cukup.
  3. Dukungan pimpinan: waktu prioritas bentrok (dan pasti), arahan jelas dari pimpinan yang nyelesaiin. Bingkai buat klien dalam istilah yang mereka pedulikan: konversi, bounce rate, ranking.

Monitoring berkelanjutan: review RUM mingguan atau dua mingguan, cari tren naik bertahap, lonjakan yang berkorelasi sama deploy/install app/perubahan konten, dan degradasi di segmen tertentu. Makin cepat ketahuan, makin gampang dicari sebabnya.

Catatan Hydrogen

Bagian ini asumsinya theme Liquid, di mana Shopify ngerender dan nge-cache HTML dan kerja kamu soal apa yang browser lakuin setelah HTML datang. Hydrogen itu aplikasi React yang kamu tulis dan jalanin sendiri di Oxygen, jadi kamu memiliki lapisan yang platform urus buat theme Liquid: data fetching, caching respons, dan berapa JavaScript per route. Perbedaan intinya: TTFB ditentuin query yang kamu tulis di loader (paralelkan, jangan over-fetch), caching per query dan full-page cache opt-in, update parsial lewat streaming Suspense bukan Section Rendering API, JavaScript weight dari import komponen (semua yang di-import masuk bundle), hydration React yang bikin halaman cepat paint tapi lambat merespons (masalah INP), dan startup worker yang harus diukur. Yang sama: strategi font, dan biaya main-thread script pihak ketiga (tapi di Hydrogen SDK yang di-import jadi bagian bundle, jadi audit bundle size, bukan cuma waterfall). Dan setup analitik dulu, karena Hydrogen gak otomatis ngelaporin CWV ke Web Performance Dashboard. Ini buku theme Liquid, jadi cukup segini.

Peta Delapan Bab Performa

Dokumentasi Shopify ngelompokkan rekomendasi dengan metrik dan dampaknya (High/Medium/Low). Yang esensial (dampak terbesar di theme terbanyak, cek ini dulu): jangan lazy-load gambar LCP, fetchpriority="high" di gambar LCP, jangan sembunyiin gambar LCP di balik animasi, render konten esensial di Liquid bukan JavaScript, hindari loop Liquid bersarang dalam, dan pakai preload hemat. Semuanya dibahas di bab masing-masing:

  1. 58 Performance Liquid (TTFB): loop bersarang, metafield di loop, overfetching varian, paginasi, render bersarang, defer dialog, combined listing, filter sebelum loop, operasi di luar loop, section.index, Section Rendering API, cache filter, block.settings, echo, limit, dan pola mikro-optimasi.
  2. 59 Performance Gambar dan LCP (LCP, CLS): fetchpriority, lazy-load, animasi, background image, srcset/sizes, layout shift, filter Shopify, dialog yang membajak LCP, filter chain, picture.
  3. 60 Performance CSS dan Font (FCP, CLS, INP): jumlah stylesheet, CLS font swap, critical CSS, self-host font, system font, ruang buat konten app, animasi transform, mega menu, stylesheet subsetting.
  4. 61 Performance JavaScript dan INP (INP, LCP): defer/async, load saat interaksi, debounce/throttle, view transition, import maps, lazy DOM, memahami INP, nemuin script terburuk.
  5. 62 Performance Mobile dan Layout (LCP, INP, CLS): throttling nyata, interstitial, responsif, tap target, konten lebih lebar dari layar, paritas konten.
  6. 63 Performance Apps dan Pihak Ketiga: app yang ngeblokir render, audit script, A/B testing, ruang konten app, app performa palsu, request proxy, checkout extension.
  7. 64 Performance Navigasi dan Loading: preconnect, preload, speculation rules, CDN Shopify, Section Rendering API, defer resource non-kritis, defer konten modal.

Plus Theme Check sebagai linter performa di 65 Theme Check Pengenalan, Konfigurasi, Commands dan Theme Inspector buat profil Liquid di 68 Theme Inspector dan Lighthouse CI.

Ringkasan

  1. Lima metrik: TTFB (server/Liquid), FCP (render blocking), LCP (elemen terbesar, kecepatan yang dirasain), CLS (pergeseran layout), INP (respons interaksi, JavaScript). LCP/CLS/INP = Core Web Vitals = sinyal ranking; TTFB/FCP diagnostik.
  2. Platform udah ngurus: CDN Cloudflare same-origin /cdn dengan Brotli/HTTP/3, versioning ?v= lewat asset_url (jangan hardcode URL), SFR, minifikasi CSS/JS ES5 (kecuali .min.*), speculation rules default, polyfill es-module-shims (jangan load sendiri), batas paginasi 25.000 (count jadi 25.001).
  3. Field data (RUM: Web Performance Dashboard, CrUX p75 28 hari, RUM pihak ketiga, Admin API unstable) buat nemuin dan verifikasi; lab data (WebPageTest, DevTools, Lighthouse/PSI) buat debug. Survivorship bias bikin rata-rata kelihatan lebih cepat.
  4. Lab vs field gak sepakat itu normal: cek perangkat, geografi, cache, variabilitas nyata (INP gak ada di lab), parameter tes, bot, noise satu run, jendela sampel. Sepakat → perbaiki, gak → cari perbedaan populasi.
  5. Benchmark Theme Store: dev store + CSV produk uji, preview link ?pb=0, Lighthouse Incognito median 3 run di home/produk/koleksi, skor berbobot 17/40/43, syarat lolos rata-rata biasa ≥ 60 desktop dan mobile. Satu run bisa beda 5–10 poin.
  6. Lighthouse CI di tiap PR lewat GitHub Action Shopify.
  7. Gap metrik: TTFB (server/Liquid/proxy), FCP−TTFB (render blocking, anti-flicker, banyak stylesheet, DOM besar, pihak ketiga), LCP−FCP (lazy-load, background, JS render, animasi, dialog, ukuran gambar). Banyak gap → FCP dulu kecuali LCP gampang, dan curigai satu penyebab bersama.
  8. Praktik berkelanjutan: performa regresi alami lewat fitur/desain/app/konten/tanpa pemilik; siklus ukur → riset → tes (median) → implementasi (cuma yang terbukti) → monitor; champion, tim lintas fungsi, dukungan pimpinan; review RUM rutin.

Bab selanjutnya kita masuk ke optimasi pertama dan yang paling sering jadi penyebab TTFB tinggi: kode Liquid, dari loop bersarang yang tumbuh kuadratik sampai mikro-optimasi kaya echo dan caching filter.

Tampilan Grafik

Tautan Balik