Sayudha

68 Theme Inspector dan Lighthouse CI

Properties2
descriptionDua alat pelengkap Theme Check, yaitu Shopify Theme Inspector for Chrome buat memprofil render Liquid lewat flame graph dan sandwich view (cara jalanin, cara baca, pola masalah, troubleshooting) dan Shopify Lighthouse CI GitHub Action buat audit performa dan aksesibilitas otomatis di tiap pull request (requirements, secrets, workflow, status check, semua argumen)
tagsshopify, theme, tools

10 menit baca

Theme Check di 65 Theme Check Pengenalan, Konfigurasi, Commands sampai 67 Theme Check Referensi Aturan M–V nganalisis kode secara statis, tanpa ngejalaninnya. Dua alat di bab ini bekerja di sisi lain: Theme Inspector ngukur berapa lama tiap potongan Liquid beneran dirender di server Shopify, dan Lighthouse CI ngukur hasil akhirnya di browser tiap kali kamu buka pull request. Keduanya jawaban buat pertanyaan yang sering muncul di 57 Performance Dasar, Metrik, dan Cara Ngukur: “TTFB-nya lambat, tapi di mana?” dan “PR ini bikin lambat gak?”

Shopify Theme Inspector for Chrome

Theme Inspector adalah ekstensi Chrome yang memvisualisasiin data profiling render Liquid dalam bentuk flame graph. Kamu pakai grafiknya buat nemuin bagian kode theme yang bikin toko lambat.

Kenapa perlu? Theme yang didesain dengan performa pun bisa melambat karena app dan kustomisasi yang ditambahin ke kodenya, dan kustomisasi Liquid sering jadi penyebabnya. Template Liquid yang lambat ngaruh ke waktu respons server (TTFB), yang ngundur waktu halaman mulai dirender, dan semua metrik lain di 57 Performance Dasar, Metrik, dan Cara Ngukur > Lima Metrik ikut mundur. Setelah kodenya ketemu, kamu optimasi pakai teknik di 58 Performance Liquid.

Ekstensinya dipasang dari Chrome Web Store, dan bisa dipakai di toko kamu sendiri atau toko yang kamu punya akses kolaborator (04 Dev Store, Akun Kolaborator, dan Theme Access > Collaborator Account).

1. Syarat Akses

Kamu butuh staff permission Themes, atau collaborator account dengan izin yang sama. Cara ngecek gampang: kalau kamu bisa buka halaman Themes di admin toko itu, kamu punya izinnya. Kamu cuma bisa memprofil toko yang: terhubung ke Shopify ID kamu, atau kamu punya collaborator account-nya, dan bukan development store.

2. Cara Jalanin

  1. Buka toko yang mau dianalisis. Kalau aksesnya lewat kolaborator, buka toko itu dari Partner Dashboard.
  2. Klik ikon Shopify Theme Inspector for Chrome di area ekstensi Chrome.
  3. Klik Sign In dan masuk pakai login Shopify. Buat akses kolaborator, masuk pakai akun Partner yang punya akses kolaborator ke toko itu.
  4. Buka Chrome DevTools dan pilih tab Shopify. Kalau gak kelihatan, klik >> buat lihat daftar overflow. Tab ini cuma muncul waktu kamu lagi ngelihat toko Shopify.
  5. Navigasi ke halaman toko yang mau diprofil.
  6. Klik ⟳ atau Load Profile buat ngehasilin flame graph halaman itu.

3. Membaca Flame Graph

Flame graph nunjukin kapan tiap node Liquid jalan dan berapa lama. Dari atas tumpukan, timeline-nya mewakili urutan total event dan total waktu render halaman. Hover di timeline dan pilih bagian tertentu buat zoom.

Total waktu render bukan TTFB. Dia gak nyertain overhead tambahan seperti waktu permintaan pengguna nyampe ke backend Shopify; buat kebanyakan pengguna overhead ekstra ini harusnya di bawah 100ms. Jadi kalau TTFB kamu 800ms dan flame graph nunjukin 650ms, ya Liquid-nya memang penyebab utamanya.

Klik bar yang relevan buat lihat detail node, kalau tersedia:

  • Time: waktu server ngerender node itu, termasuk anak-anaknya.
  • Percentage: persentase dari total waktu.
  • tag:, variable:: apakah node itu tag Liquid atau variabel.
  • Code snippet: kode yang di-resolve server.
  • Filename dan nomor baris: lokasi kodenya.

Waktu render bisa sedikit beda tiap kali diprofil karena optimasi di infrastruktur Shopify. Sama seperti Lighthouse, jangan simpulin dari satu run.

4. Sandwich View

Sandwich view mengagregasi waktu tiap node: Self (jumlah waktu eksekusinya sendiri, tanpa anak) dan Total (termasuk anak). Ini berguna buat nemuin node mana yang paling banyak nyumbang ke waktu render halaman, karena flame graph biasa bisa nyembunyiin node kecil yang dipanggil ribuan kali.

Contoh khas: filter:image_url cuma butuh sekitar 50μs (0,05ms) per eksekusi, tapi dieksekusi sampai 2000 kali. Eksekusi berulang itu memperpanjang total render secara signifikan, dan itu yang ditunjukin sandwich view lewat Self time-nya yang tinggi walau tiap pemanggilan cepat.

5. Pola yang Dicari

Waktu nemuin kode yang bikin lambat, timbang manfaat fiturnya terhadap dampak kecepatannya. Kadang kamu perlu ngorbanin sedikit kecepatan buat pengalaman yang lebih laku.

Terlalu banyak node atau node bersarang dalam. Beberapa node cepat tapi dieksekusi ratusan atau ribuan kali, nambah waktu render dan TTFB. Profile view ndukung Find (Control+F / Command+F) buat ngasih hitungan berapa kali sebuah node dieksekusi. Kalau flame graph-nya punya banyak lapisan bersarang, kodenya mungkin belum optimal, dan penyebab umumnya (bisa kombinasi): terlalu banyak kondisional, loop bersarang, include bersarang (58 Performance Liquid > Loop Bersarang: Masalah Terbesar dan 58 Performance Liquid > render Bersarang).

Operasi kompleks di dalam loop. Ngelakuin operasi berat di dalam loop memperlambat render Liquid. Sering kali logika template bisa disederhanain dan disusun ulang buat perbaikan besar.

❌ assign di dalam for: products_by_price dihitung ulang tiap produk padahal nilainya gak berubah per produk

{%- for product in collection.products -%}
{% assign products_by_price = collection.products | sort: "price" %}
// some liquid code
{%- endfor -%}

✅ sort sekali, tetap bisa dipakai di dalam loop

{% assign products_by_price = collection.products | sort: "price" %}
{%- for product in collection.products -%}
   // some liquid code
{%- endfor -%}

Ini contoh paling sederhana dari 58 Performance Liquid > Hoist Operasi ke Luar Loop.

Section non-visual. Section buat script, SEO, analitik, dan sejenisnya sering muncul di flame graph padahal gak ngerender apa-apa buat pengunjung. Evaluasi apakah section itu memang perlu, atau refactor biar lebih efisien.

6. Troubleshooting

  • Bisa memprofil toko mana pun? Gak. Cuma toko yang terhubung ke Shopify ID kamu atau yang kamu punya collaborator account-nya, dan bukan development store.
  • Tab Shopify gak muncul di DevTools. Tab itu cuma muncul waktu kamu lagi ngelihat toko Shopify.
  • This page cannot be profiled. Muncul kalau: akun kamu gak punya akses ke toko itu; kamu nyoba memprofil halaman checkout, yang gak didukung ekstensi ini; atau ada error yang gak tertangani seperti timeout atau koneksi putus.

Shopify Lighthouse CI GitHub Action

Tiap perubahan kode theme bisa berdampak ke performa. Biar kode yang bikin lambat ketahuan sebelum masuk produksi, kamu integrasiin tes Lighthouse ke alur pengembangan lewat Shopify Lighthouse CI GitHub Action. Ini GitHub Action khusus Shopify yang dibangun di atas Lighthouse CI dari Google. Dia ngejalanin audit Lighthouse sebagai bagian CI buat tiap pull request, ngetes performa home page, satu halaman produk, dan satu halaman koleksi, tiga halaman yang sama dengan 57 Performance Dasar, Metrik, dan Cara Ngukur > Benchmark Theme Store. Prasyaratnya theme kamu ada di GitHub, alurnya ada di 08 GitHub Integration dan Version Control.

1. Requirements

  • Development store yang didedikasiin buat Lighthouse CI dan tes performa manual (04 Dev Store, Akun Kolaborator, dan Theme Access > Dev Store).
  • Data toko khusus performa. Biar hasilnya konsisten, isi tokonya dari CSV produk uji, dan toko itu gak boleh punya koleksi, produk, atau varian lain. Ini data yang sama yang dipakai buat ngetes theme sebelum diterima Theme Store (71 Testing Theme buat Theme Store).
  • Kredensial API buat dev store. Lighthouse CI konek ke toko lewat app Dev Dashboard. Bikin app dengan scope read_products dan write_themes, pasang di toko, dan salin client_id dan client_secret dari kredensial app-nya. write_themes perlu karena action-nya ngunggah kode PR sebagai theme buat dites.

2. Langkah 1: Secrets di GitHub

Di repo GitHub theme, tambahin repository secrets: SHOP_CLIENT_ID (client ID app), SHOP_CLIENT_SECRET (client secret app), SHOP_STORE (URL myshopify.com toko, format your-store-name.myshopify.com). Kalau tokonya dilindungi password (dev store selalu), tambahin juga secret berisi password toko. Tanpa itu Lighthouse dialihkan ke halaman password dan yang diaudit halaman password, bukan theme kamu.

3. Langkah 2: Workflow

Bikin file workflow yang ngejalanin shopify/lighthouse-ci-action:

name: Shopify Lighthouse CI
on: [push]
jobs:
  lhci:
    name: Lighthouse
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Lighthouse
      uses: shopify/lighthouse-ci-action@v1
      with:
        client_id: ${{ secrets.SHOP_CLIENT_ID }}
        client_secret: ${{ secrets.SHOP_CLIENT_SECRET }}
        store: ${{ secrets.SHOP_STORE }}
        password: ${{ secrets.SHOP_PASSWORD }}

Simpan sebagai .github/workflows/lighthouse-ci.yml, commit, dan bikin pull request. Kamu bakal lihat GitHub Action yang ngejalanin Lighthouse terhadap kode PR itu.

4. Langkah 3 (opsional): Status Check

GitHub status check nampilin status run Lighthouse CI langsung di UI GitHub, dan bikin PR lolos atau gagal tergantung hasilnya. Caranya:

  1. Pasang Lighthouse CI GitHub app sebagai owner repo theme, dan salin token yang diberikan.
  2. Bikin repository secret bernama LHCI_GITHUB_APP_TOKEN berisi token itu.
  3. Tambahin atribut lhci_github_app_token di workflow:
name: Shopify Lighthouse CI
on: [push]
jobs:
  lhci:
    name: Lighthouse
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Lighthouse
      uses: shopify/lighthouse-ci-action@v1
      with:
        client_id: ${{ secrets.SHOP_CLIENT_ID }}
        client_secret: ${{ secrets.SHOP_CLIENT_SECRET }}
        store: ${{ secrets.SHOP_STORE }}
        password: ${{ secrets.SHOP_PASSWORD }}
        lhci_github_app_token: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
  1. Commit dan bikin PR. Sekarang PR kamu lolos atau gagal sesuai check Lighthouse CI.

Alternatif token: lhci_github_token berisi personal access token GitHub, kalau kamu gak mau masang app-nya. Perbedaan keduanya dijelasin di dokumentasi Lighthouse CI.

5. Semua Argumen

Wajib:

  • client_id dan client_secret: dari app Dev Dashboard, selalu berpasangan. Wajib kecuali pakai access_token.
  • access_token: Admin API access token dari custom app lama, cuma buat app yang dibikin sebelum Januari 2026. Wajib kecuali pakai client_id + client_secret.
  • store: URL {shop}.myshopify.com.

Opsional:

  • password: password toko, wajib buat toko berpassword seperti dev store.
  • product_handle: handle produk buat tes halaman produk. Default produk pertama.
  • collection_handle: handle koleksi buat tes halaman koleksi. Default koleksi pertama.
  • theme_root: direktori root file theme di repo, kalau theme-nya gak di root repo (misalnya strategi source/compiled di 08 GitHub Integration dan Version Control > Version Control Strategy: Source vs Compiled).
  • pull_theme: ID atau nama theme yang settings dan template JSON-nya ditarik ke theme pengembangan. Tanpa ini, dipakai setting default theme. Berguna biar yang diaudit konfigurasi yang mirip toko sungguhan, bukan preset kosong.
  • lhci_min_score_performance: skor performa minimal buat lolos, desimal 0–1, default 0.6, selaras dengan ambang Theme Store.
  • lhci_min_score_accessibility: skor aksesibilitas minimal, desimal 0–1, default 0.9, sejalan dengan 55 Accessibility.

Contoh dengan ambang yang lebih ketat dan halaman yang ditentuin:

      with:
        client_id: ${{ secrets.SHOP_CLIENT_ID }}
        client_secret: ${{ secrets.SHOP_CLIENT_SECRET }}
        store: ${{ secrets.SHOP_STORE }}
        password: ${{ secrets.SHOP_PASSWORD }}
        product_handle: sunglasses
        collection_handle: all
        pull_theme: 123456789012
        lhci_min_score_performance: 0.75
        lhci_min_score_accessibility: 0.95

6. Waktu CI Ngelaporin Skor Turun

Skor Lighthouse satu run bisa beda 5–10 poin, jadi kalau CI gagal tipis, cek dulu apakah itu variabilitas atau regresi nyata dengan ngejalanin ulang. Kalau konsisten turun: lihat metrik mana (LCP, TBT, CLS) yang bergerak, pakai 57 Performance Dasar, Metrik, dan Cara Ngukur > Debugging Lewat Gap Metrik buat nyempitin penyebab, dan kalau TBT/TTFB yang naik, buka Theme Inspector di theme pengembangan yang sama buat lihat Liquid mana yang berubah. Perbaiki atau revert sebelum merge, itu seluruh alasan check-nya ada.

Kapan Pakai Alat Mana

  • Theme Check: waktu nulis kode, di editor dan CI. Nangkep kesalahan tanpa ngejalanin apa-apa.
  • Theme Inspector: waktu TTFB tinggi atau setelah app/kustomisasi ditambah. Nunjukin node Liquid mana yang makan waktu di server.
  • Lighthouse CI: waktu tiap PR, sebagai penjaga gawang. Nunjukin hasil di browser (performa, aksesibilitas) dari perubahan itu.
  • Lighthouse manual dan field data: waktu ngukur pengalaman pengguna nyata, dari 57 Performance Dasar, Metrik, dan Cara Ngukur > Field Data vs Lab Data.

Ringkasan

  1. Theme Inspector for Chrome memvisualisasiin profiling render Liquid sebagai flame graph; dipasang dari Chrome Web Store, butuh permission Themes (atau kolaborator), gak bisa buat dev store atau halaman checkout.
  2. Jalanin: buka toko (dari Partner Dashboard kalau kolaborator), Sign In di ekstensi, DevTools → tab Shopify (cek >>), navigasi ke halaman, klik Load Profile.
  3. Flame graph nunjukin kapan dan berapa lama tiap node jalan; total render bukan TTFB (overhead tambahan biasanya < 100ms). Klik node buat Time (termasuk anak), Percentage, tag/variable, snippet, file dan baris.
  4. Sandwich view ngejumlahin Self (tanpa anak) dan Total; ngungkap node cepat yang dipanggil ribuan kali, misalnya filter:image_url 50μs × 2000.
  5. Pola masalah: terlalu banyak node atau bersarang dalam (kondisional, loop bersarang, include bersarang, pakai Find buat ngitung eksekusi), operasi kompleks di dalam loop (hoist assign keluar), section non-visual.
  6. Lighthouse CI GitHub Action (shopify/lighthouse-ci-action@v1) ngaudit home, produk, dan koleksi di tiap PR; butuh dev store khusus berisi CSV produk uji, dan app Dev Dashboard dengan read_products + write_themes.
  7. Secrets: SHOP_CLIENT_ID, SHOP_CLIENT_SECRET, SHOP_STORE, plus SHOP_PASSWORD (tanpa itu Lighthouse ngaudit halaman password). Status check lewat lhci_github_app_token (app Lighthouse CI) atau lhci_github_token (PAT).
  8. Argumen: client_id/client_secret atau access_token (custom app pra-2026), store, password, product_handle, collection_handle, theme_root, pull_theme, lhci_min_score_performance (default 0.6), lhci_min_score_accessibility (default 0.9).
  9. Theme Check buat nulis, Theme Inspector buat TTFB, Lighthouse CI buat tiap PR, field data buat pengalaman nyata.

Bab selanjutnya kita bahas parser Liquid yang lebih ketat: apa yang berubah, error apa yang dulu diam-diam ditoleransi dan sekarang ditolak, cara ngecek theme kamu, dan cara migrasi tanpa ngerusak toko.

Tampilan Grafik

Tautan Balik