Cara Meningkatkan Skor Google Lighthouse: Server vs Kode Website

Cara meningkatkan skor Google Lighthouse pada website membutuhkan pemisahan masalah server dan kode frontend. Riset untuk artikel ini menemukan 7 kasus yang cukup kuat untuk dimasukkan sebagai kasus utama: empat implementasi/publikasi independen dan tiga eksperimen terkontrol dari satu paper Indonesia. Jumlah ini lebih rendah dari target 8–12 karena beberapa kandidat 2025–2026 tidak memiliki tanggal, identitas proyek, metode pengujian, atau langkah teknis yang cukup untuk memenuhi standar validasi.

Definisi Lighthouse

Google Lighthouse adalah alat audit otomatis dan open-source untuk mengevaluasi kualitas sebuah halaman web. Lighthouse dapat dijalankan melalui Chrome DevTools, PageSpeed Insights, command line, atau modul Node.js; hasil audit berfungsi sebagai indikator masalah dan peluang perbaikan, bukan bukti final mengenai akar penyebabnya. developer.chrome Kategori utama yang dinilai dalam laporan Lighthouse modern adalah:

• Performance: Kecepatan tampilan, kesiapan interaksi, dan stabilitas visual.
• Accessibility: Masalah aksesibilitas yang dapat dideteksi secara otomatis.
• Best Practices: Kesehatan dan keamanan implementasi web.
• SEO: Persyaratan teknis dasar agar halaman dapat ditemukan dan dipahami mesin pencari. developer.chrome

Skor Performance

Skor Performance 0–100 merupakan rata-rata berbobot dari skor metrik individual. Nilai mentah setiap metrik dikonversi ke skor 0–100 menggunakan distribusi log-normal berdasarkan data situs nyata di HTTP Archive. developer.chrome

Pada model skor Lighthouse yang didokumentasikan Chrome, bobotnya adalah FCP 10%, Speed Index 10%, LCP 25%, TBT 30%, dan CLS 25%. Karena transformasinya tidak linear, kenaikan dari 40 ke 60 tidak boleh diperlakukan sebagai peningkatan pengalaman pengguna yang identik dengan kenaikan dari 70 ke 90. developer.chrome

Metrik utama

TTFB tidak ikut langsung dalam bobot skor Performance, tetapi menjadi fondasi FCP dan LCP: konten tidak dapat dirender sebelum dokumen mulai diterima. Lighthouse juga membedakan server response time dari TTFB penuh; audit “Reduce server response times” gagal ketika respons dokumen utama melewati 600 ms, sementara DNS dan redirect dapat berada di luar nilai server-response yang dilaporkan audit tersebut. developer.chrome

Lighthouse, PSI, dan CWV

Lighthouse berfokus pada initial page load dalam lingkungan simulasi. Masalah yang baru terjadi setelah pengguna men-scroll, membuka menu, atau melakukan interaksi lain bisa tidak tertangkap. web Core Web Vitals saat ini terdiri dari LCP, INP, dan CLS; keberhasilan CWV ditentukan pada persentil ke-75 dari pengalaman pengguna. TBT digunakan Lighthouse sebagai indikator laboratorium terhadap blocking main thread, tetapi bukan pengganti identik untuk INP karena INP membutuhkan interaksi pengguna nyata. web

Lab dan field data

Lab data diperoleh dalam kondisi perangkat dan jaringan yang dikontrol atau disimulasikan. Keuntungannya adalah relatif mudah direproduksi, dapat menghasilkan trace, dan bisa diuji segera setelah perubahan kode. web Field data berasal dari pengalaman pengguna nyata dengan variasi perangkat, browser, jaringan, lokasi, status cache, dan pola interaksi. PageSpeed Insights dan Search Console menggunakan data lapangan CrUX, sedangkan RUM dapat mengumpulkan data yang lebih spesifik untuk pengguna situs sendiri. web Akibatnya:

• Skor Lighthouse yang baik tidak membuktikan seluruh pengguna memperoleh CWV yang baik.
• Skor Lighthouse buruk tidak selalu berarti semua pengguna mengalami halaman buruk.
• Perubahan lab dapat terlihat segera, sedangkan agregat field memerlukan trafik dan waktu observasi.
• CLS dan INP lapangan dapat menangkap kejadian setelah initial load yang tidak terlihat pada satu audit Lighthouse. web

Penyebab skor berubah

Skor dapat berbeda walaupun kode tidak berubah karena nondeterminisme halaman, variasi jaringan, respons server, hardware klien, perebutan CPU, proses browser, iklan, third-party script, dan perbedaan konfigurasi throttling. Dokumentasi Lighthouse secara eksplisit menyarankan pengujian berulang dan penggunaan median; median lima run disebut sekitar dua kali lebih stabil daripada satu run. github Perbedaan besar juga muncul ketika:

• Membandingkan mobile dengan desktop; baseline harus konsisten dengan prinsip mobile first bila situs diuji sebagai mobile.
• Menggunakan versi Lighthouse yang berbeda.
• Membandingkan PSI dengan DevTools lokal.
• Salah satu pengujian memperoleh CDN/page-cache hit dan yang lain cache miss.
• Konten, iklan, eksperimen A/B, atau consent banner berubah.
• Extension browser, antivirus, atau proses lain memakai CPU.
• Pengujian dijalankan bersamaan pada mesin yang sama. github

Server vs Code

Lighthouse menunjukkan apa yang lambat pada satu pemuatan, tetapi tidak selalu menjelaskan mengapa. Klasifikasi berikut membantu mencegah kesimpulan keliru bahwa semua TTFB tinggi disebabkan hosting.

Hosting dan infrastruktur

DevTools Network memisahkan DNS Lookup, Initial Connection, Waiting/TTFB, dan Content Download. Nilai Waiting mencakup satu network round trip dan waktu server menyiapkan respons; oleh karena itu, ia bukan pengukur murni kemampuan CPU hosting. developer.chrome

Website dan frontend

Lighthouse mendefinisikan script di tanpa async atau defer, serta stylesheet yang berlaku untuk perangkat saat ini, sebagai kandidat render-blocking. DevTools Coverage dapat membedakan kode yang dipakai dari CSS/JS yang dimuat tetapi tidak diperlukan. developer.chrome

Masalah gabungan

LCP dapat diuraikan secara konseptual menjadi empat komponen berikut.

1. TTFB: Waktu sebelum HTML mulai diterima.
2. Resource load delay: Waktu sampai browser menemukan dan mulai meminta resource LCP.
3. Resource load duration: Waktu transfer resource.
4. Element render delay: Waktu setelah resource tersedia sampai elemen benar-benar dirender.

Di stack WordPress, kombinasi TTFB, hero image, dan font sering muncul bersamaan; panduan terpisah membahas LCP WordPress lambat meskipun cache aktif. Karena itu, LCP 7 detik dapat merupakan kombinasi backend 1,5 detik, hero image yang baru ditemukan setelah JavaScript berjalan, file gambar besar, dan main thread yang masih sibuk. Memindahkan hosting hanya menangani bagian pertama; mengompresi gambar hanya menangani bagian ketiga. TTFB tinggi harus diklasifikasikan lebih lanjut:

• Backend: Waktu aplikasi, template rendering, API, atau database.
• Infrastructure: CPU, worker, disk, routing, load balancer.
• Cache: Miss, revalidation, atau key yang salah.
• CDN: Edge miss atau jalur edge-to-origin.
• Network: DNS, TCP/TLS, round trip, lokasi pengguna.
• Redirect: HTTP ke HTTPS, non-www ke www, atau rantai URL.

web.dev juga menyarankan membandingkan field TTFB dengan lab TTFB dan menguji URL yang jarang diakses atau parameter cache-bypass. Perbedaan besar dapat menunjukkan bahwa lab test memperoleh cache hit yang tidak mewakili pengguna nyata. web.developers.google

Diagnosis Praktis

Daftar Lighthouse bersifat indikatif. Contohnya, “Reduce unused JavaScript” membuktikan bahwa kode tidak digunakan dalam satu skenario audit, tetapi belum membuktikan kode tersebut aman dihapus dari semua route atau interaksi. Akar penyebab baru dapat disebut terverifikasi jika perubahan terisolasi menghasilkan perbaikan pada trace atau metrik terkait. Contohnya: bundle diperkecil, transfer JS turun, long task menghilang, kemudian TBT turun pada pengujian dengan kondisi yang sama.

Metodologi Before–After

Prosedur berikut disarankan saat melaporkan pengujian before-after pada artikel teknis CodeF.

1. Bekukan baseline. Simpan URL, commit, waktu pengujian, lokasi, konfigurasi CDN, status login, dan konten.
2. Catat versi. Rekam versi Lighthouse, Chrome, OS, serta metode DevTools, CLI, PSI, atau Lighthouse CI.
3. Pisahkan mobile dan desktop. Jangan membandingkan baseline mobile dengan hasil desktop.
4. Pertahankan throttling. Gunakan profil perangkat, CPU slowdown, dan jaringan yang sama.
5. Kontrol cache. Pisahkan cold-cache dan warm-cache; jangan mencampur CDN hit dengan origin miss.
6. Jalankan sekurangnya lima kali. Gunakan median, serta simpan minimum–maksimum untuk menunjukkan variasi.
7. Jangan menjalankan audit paralel. Perebutan CPU dapat mengubah TBT dan skor. github
8. Ubah satu kelompok penyebab. Jika migrasi penuh tidak memungkinkan isolasi, hindari mengatribusikan seluruh peningkatan kepada satu teknik.
9. Simpan HTML/JSON report dan trace. Catat skor serta FCP, LCP, TBT, CLS, Speed Index, dan TTFB.
10. Validasi lapangan. Periksa CrUX, Search Console, atau RUM setelah data pascadeployment tersedia.

Contoh Lighthouse CI untuk lima run: npx -p @lhci/cli lhci collect \
--url https://example.com \
-n 5 Dokumentasi Lighthouse merekomendasikan nilai agregat seperti median atau persentil, bukan satu hasil tunggal. Skor Performance harus dilaporkan bersama metrik individual karena optimasi yang nyata dapat tidak banyak mengubah skor jika metrik yang berubah memiliki bobot kecil atau sudah berada di bagian datar kurva skor. github

Format pelaporan

Untuk setiap URL dan perangkat, gunakan tabel pelaporan dengan kolom before dan after seperti contoh berikut.

Perubahan skor sebaiknya dinyatakan dalam poin, misalnya 41 menjadi 84 adalah +43 poin. Persentase relatif seperti 104,9% secara aritmetis dapat dihitung, tetapi mudah disalahartikan karena skor Lighthouse bukan skala rasio linear.

Validasi Sumber

Dari penelusuran 2025–19 Oktober 2026, beberapa kandidat tidak dimasukkan ke daftar utama:

• Orchestra Media 74→96 dan iPixelP 42→96: angka dan stack tersedia, tetapi halaman kasus tidak mencantumkan tanggal pelaksanaan atau publikasi yang dapat diverifikasi; langkah optimasinya juga terlalu umum. webcraftdev
• MacRumors 42→96: sumber pelaksana menjelaskan penghapusan jQuery, CSS Modules, dan penundaan konten blocking, tetapi tidak menampilkan tanggal proyek/publikasi yang cukup untuk memastikan periode 2025–2026. audent
• Homeland Restorers 38→94: tanggal Juli 2025 dan skor mobile tersedia, tetapi uraian teknis before–after terlalu tipis untuk format how-to yang diminta. premiersol
• Kasus Toronto 52→97: tindakan seperti migrasi Kinsta, pengurangan plugin, WebP dan critical CSS disebutkan, tetapi proyek dianonimkan dan tidak dilengkapi laporan audit asli. belovdigital
• Meerako Shopify/Next.js 28→96: metrik dan tindakan cukup terperinci, tetapi klien hanya disebut “Dallas-based retailer” dan bukti audit atau URL proyek tidak diberikan. meerako
• Wipro AEM Edge Delivery Services: booklet 2025 menyebut 55/70 menjadi 97/100, tetapi konteks device, identitas storefront, dan pengujian tidak cukup jelas untuk direkonstruksi. wipro
• JABstract landscaping rebuild: pengujian 28 September 2026 menyebut desktop 88→99, mobile 70→72, dan LCP 2,3→0,9 detik, tetapi langkah implementasinya belum cukup rinci untuk studi utama. jabstract

Studi Kasus Keberhasilan

Studi Kasus 1: Portfolio Azfar Razzaq , Bundle JavaScript dan Font Blocking

Identitas

• Website/proyek: Portfolio pribadi Azfar Razzaq
• Platform/teknologi: Tidak dinyatakan secara eksplisit dalam sumber
• Pelaksana: Azfar Razzaq
• Negara: Tidak disebutkan
• Tanggal pelaksanaan: Sebelum publikasi; tanggal tepat tidak disebutkan
• Tanggal publikasi: 25 Maret 2026
• Sumber asli: DEV Community , Real Portfolio Optimization Case Study

A. Apa Masalahnya?

Baseline mobile memperoleh skor 55, sedangkan desktop 68. Kontribusi TBT dan CLS sudah maksimal, tetapi FCP, LCP, dan Speed Index memperoleh kontribusi nol sehingga masalah utamanya bukan layout shift atau blocking time, melainkan keterlambatan tampilnya konten. dev Lighthouse melaporkan potensi penghematan 2.445 KiB unused JavaScript. Total bundle sekitar 2.517 KB, dengan home.js sekitar 2.005 KB dan index.js sekitar 472 KB. dev Request Google Fonts menambah sekitar 1.020 ms pada render-blocking chain. Gambar situs secara keseluruhan juga berukuran sekitar 8.000 KB sebelum optimasi. dev

B. Sumber Masalah

Klasifikasi: CODE. Pelaksana memverifikasi bahwa sebuah library diimpor terlalu luas padahal halaman hanya menggunakan sebagian kecil fungsinya. Ia juga menemukan font dimuat melalui Google Fonts embed dan gambar masih berupa PNG/JPEG berukuran besar. dev Ini lebih kuat daripada sekadar mengikuti label Lighthouse karena pelaksana memeriksa output bundle, file dominan, pola import, request font, dan ukuran aset.

C. Before & After

Sumber menyebut pengujian baseline dilakukan beberapa kali dan penilaian utama menggunakan mobile, tetapi tidak menyebut versi Lighthouse, profil perangkat, throttling, maupun median numeriknya. dev

D. How To

1. Jalankan Lighthouse beberapa kali pada live domain dan gunakan incognito agar extension tidak ikut memengaruhi hasil.
2. Periksa kontribusi setiap metrik, bukan hanya skor total.
3. Buka diagnostics “Reduce unused JavaScript” dan periksa hasil build.
4. Identifikasi library yang membuat home.js membengkak.
5. Ganti import seluruh library dengan import subset yang benar-benar diperlukan.
6. Setelah bundle dikurangi, skor mobile naik dari 55 menjadi 87.
7. Unduh dan self-host font dalam format WOFF2 untuk menghilangkan request eksternal yang menghambat render.
8. Setelah font dipindahkan, skor mencapai sekitar 95–96.
9. Tambahkan fetchPriority="high" pada gambar LCP.
10. Konversi gambar PNG/JPEG non-LCP menjadi WebP dan kompres pada kualitas sekitar 75–80%.
11. Jalankan ulang Lighthouse dan periksa apakah insight, transfer size, serta delay benar-benar turun. dev

E. Hasil dan Bukti

Skor mobile naik 41 poin, dari 55 menjadi 96, sedangkan desktop naik 32 poin, dari 68 menjadi 100. Pengurangan bundle memberi lompatan paling jelas, 55→87, kemudian self-hosted font mendorong hasil ke sekitar 95–96. dev Keterbatasannya: laporan tidak mempublikasikan nilai mentah FCP, LCP, TBT, CLS, versi Lighthouse, median final, live URL, atau file JSON audit. Karena beberapa perubahan diterapkan bertahap, hanya perubahan 55→87 yang cukup kuat untuk dikaitkan langsung dengan pengurangan bundle.

F. Referensi

• Artikel utama

Studi Kasus 2: Kashif Aziz , Migrasi WordPress ke Astro

Identitas

• Website/proyek: kashifaziz.me
• Platform sebelum: WordPress
• Platform setelah: Astro 5, TypeScript, Tailwind CSS, MDX, Sharp, Cloudflare Pages
• Pelaksana: Kashif Aziz
• Negara: Tidak disebutkan
• Tanggal pelaksanaan: Sebelum 15 Desember 2025
• Tanggal publikasi: 15 Desember 2025
• Sumber asli: WordPress to Astro Migration Journey

A. Apa Masalahnya?

Situs WordPress telah menggunakan caching, CDN, image optimization, dan plugin performa, tetapi skor Performance tetap berada di kisaran 70–80. First visit membutuhkan sekitar 3,2 detik dan repeat load dengan cache sekitar 1,8 detik. kashifaziz Pelaksana mengidentifikasi sekitar 450 KB JavaScript dari theme dan plugin, termasuk jQuery, analytics, social sharing, comment system, dan script tema. Caching mengurangi PHP/database overhead, tetapi tidak menghilangkan frontend JavaScript yang tetap dikirim ke browser. kashifaziz

B. Sumber Masalah

Klasifikasi: MIXED. Masalah berasal dari kombinasi runtime WordPress/PHP/database, dependensi plugin, dan frontend JavaScript. Migrasi kemudian menghilangkan runtime dinamis untuk halaman konten, database query saat request, serta sebagian besar client-side JavaScript. kashifaziz Karena seluruh arsitektur diubah sekaligus, sumber tidak membuktikan berapa poin yang berasal dari Astro, Cloudflare, image optimization, atau penghapusan plugin secara individual.

C. Before & After

Sumber tidak menyatakan apakah angka tersebut mobile atau desktop, versi Lighthouse, jumlah run, maupun throttling. kashifaziz

D. How To

1. Inventarisasi posting, halaman, media, plugin, dan fitur WordPress.
2. Petakan setiap URL agar struktur lama dapat dipertahankan.
3. Export konten WordPress melalui XML.
4. Konversi konten menjadi MDX dan validasi metadata menggunakan Astro Content Collections serta Zod.
5. Pertahankan pola URL /blog/post-slug/; gunakan file _redirects untuk URL yang tidak dapat dipertahankan.
6. Hasilkan semua halaman sebagai static HTML pada build time.
7. Gunakan Astro Image/Sharp untuk membuat ukuran responsif dan format WebP.
8. Terapkan dimensi gambar dan lazy loading untuk konten bawah fold.
9. Hapus comments dan fitur dinamis yang tidak dianggap penting.
10. Gunakan Web3Forms untuk form tanpa backend.
11. Deploy output statis ke Cloudflare Pages.
12. Manfaatkan edge cache, Brotli, HTTP/2, HTTP/3, dan distribusi global.
13. Jalankan local production build, mobile test, cross-browser test, kemudian Lighthouse pada deployment produksi. kashifaziz

Contoh perintah deployment dari sumber: npm run build lalu npm run deploy.

E. Hasil dan Bukti

Migrasi ke Astro pada kasus ini menyerupai pola static site generation untuk halaman konten, walau stack dan trade-off fitur dinamis berbeda. Performance meningkat 28 poin, TBT turun 450 ms menjadi nol, dan CLS turun dari 0,15 menjadi nol. Hasil paling signifikan berasal dari penghilangan JavaScript frontend dan runtime server pada halaman konten. kashifaziz

Ada inkonsistensi internal: narasi menyebut skor terakhir WordPress 78, sedangkan tabel hasil mencantumkan baseline 72. Judul juga menyebut “migrated in 2026” walaupun halaman bertanggal 15 Desember 2025; karena itu, artikel valid dalam rentang riset tetapi kronologi judulnya perlu diberi catatan. kashifaziz

F. Referensi

• Studi kasus asli
• Live site: kashifaziz.me

Studi Kasus 3: Carda Health , Optimasi Webflow dan Hero LCP

Identitas

• Website/proyek: Carda Health
• Platform/teknologi: Webflow
• Pelaksana: Grégoire Geoffroy
• Negara: Tidak dicantumkan
• Tanggal pelaksanaan: Partnership berlangsung hingga Agustus 2026; audit dan perbaikan tertentu diverifikasi 30 Juli–27 Agustus 2026
• Tanggal publikasi: Tidak ditampilkan oleh halaman
• Sumber asli: Carda Health Case Study

A. Apa Masalahnya?

Homepage memperoleh Lighthouse Performance sekitar 55 pada mobile, LCP 8,6 detik, dan FCP 5 detik. Sumber menyebut “compounding problems” pada Webflow, khususnya CSS yang tidak diperlukan, discovery/prioritas hero image, gambar di luar viewport, dan format image delivery. gregoiregeoffroy

B. Sumber Masalah

Klasifikasi: CODE. Akar masalah yang didokumentasikan berada pada frontend Webflow: unused CSS lintas halaman, hero image art-directed yang tidak diprioritaskan, non-viewport imagery, dan format gambar. Tidak ada bukti bahwa hosting atau origin server menjadi penyebab dominan. gregoiregeoffroy

C. Before & After

Angka disebut sebagai data dari engagement changelog. Pelaksana juga membuat Python batch runner berbasis PageSpeed Insights API untuk menguji sekumpulan URL. gregoiregeoffroy

D. How To

1. Audit homepage dan identifikasi LCP hero serta payload CSS.
2. Aktifkan fitur Per Page CSS pada Webflow agar halaman tidak mengunduh CSS global yang tidak diperlukan.
3. Tambahkan preload untuk hero image.
4. Sertakan atribut media dan imagesrcset pada preload agar browser memilih art-directed source yang benar.
5. Terapkan lazy loading hanya pada gambar di luar viewport.
6. Pindahkan image delivery ke format generasi baru pada bagian yang didukung Webflow.
7. Buat batch runner menggunakan PageSpeed Insights API untuk menguji banyak URL secara lebih konsisten.
8. Verifikasi hasil pada production, bukan hanya preview atau staging. gregoiregeoffroy

E. Hasil dan Bukti

Mobile Performance naik 41 poin, LCP turun 7,3 detik atau sekitar 85%, dan FCP turun 4,2 detik atau sekitar 84%. Desktop naik dari 68 menjadi 94. gregoiregeoffroy Keterbatasannya: tanggal publikasi halaman, versi Lighthouse, jumlah run, throttling, dan laporan JSON/screenshot tidak ditampilkan. Beberapa perubahan dilakukan bersama-sama sehingga kontribusi individual Per Page CSS, preload, lazy loading, dan format gambar tidak dapat dipisahkan.

F. Referensi

• Studi kasus asli
• Live site: cardahealth.com

Studi Kasus 4: Boonaboo , Redesign E-commerce Next.js

Identitas

• Website/proyek: Boonaboo, e-commerce produk ibu dan bayi
• Platform/teknologi setelah redesign: Next.js, HTML, Tailwind CSS
• Pelaksana: MY Aura Puti Agdira, Sari Setyaning Tyas, Yuyun Khairunnisa
• Institusi/negara: Politeknik Media Kreatif, Jakarta, Indonesia
• Tanggal pelaksanaan: Sebelum evaluasi dan publikasi 2026
• Tanggal publikasi: Online 1 September 2026
• Sumber asli: Paper Boonaboo

A. Apa Masalahnya?

Baseline mobile memperoleh Performance 41, FCP 3,4 detik, LCP 17,2 detik, TBT 1.030 ms, Speed Index 4,4 detik, dan CLS 0,11. Desktop memperoleh 76 dengan FCP 0,8 detik, LCP 2,5 detik, TBT 240 ms, Speed Index 1,4 detik, dan CLS 0,031. ojs.ninetyjournal Observasi menemukan homepage terlalu panjang, navigasi lemah, tidak ada product filtering, layout terlalu padat, dan beberapa image asset tidak teroptimasi. ojs.ninetyjournal

B. Sumber Masalah

Klasifikasi: CODE. Bukti penelitian menghubungkan masalah dengan struktur layout, navigation architecture, ukuran image asset, responsive implementation, dan efisiensi kode. Paper tidak menyajikan bukti masalah CPU, database, origin server, atau hosting. ojs.ninetyjournal

C. Before & After

D. How To

1. Lakukan pretest Lighthouse untuk mobile dan desktop.
2. Gabungkan hasil teknis dengan observasi dan System Usability Scale dari 20 responden.
3. Restrukturisasi homepage agar konten prioritas tampil lebih ringkas.
4. Perbaiki information architecture dan navigation menu.
5. Tambahkan product filtering.
6. Kurangi visual density melalui spacing dan hierarchy yang lebih jelas.
7. Kompres dan optimalkan image asset.
8. Implementasikan responsive design.
9. Bangun prototype fungsional menggunakan HTML, Tailwind CSS, dan Next.js.
10. Jalankan posttest Lighthouse pada mobile dan desktop menggunakan instrumen yang sama. ojs.ninetyjournal

Paper hanya menyebut “code efficiency improvements” secara umum dan tidak memberikan repository, potongan konfigurasi Next.js, ukuran bundle, atau detail image pipeline.

E. Hasil dan Bukti

Mobile naik 43 poin, dari kategori Poor menjadi Needs Improvement; desktop naik 23 poin menjadi 99. Paper menyebut kenaikan mobile sebagai 104,88%, tetapi untuk komunikasi teknis lebih aman menyebut +43 poin karena skor Lighthouse bukan skala linear. ojs.ninetyjournal Keterbatasan penelitian adalah tidak adanya versi Lighthouse, run count, throttling, kondisi cache, nilai metrik individual setelah redesign, control group, maupun pemantauan pengguna nyata. Dengan banyak perubahan sekaligus, paper membuktikan keberhasilan redesign secara keseluruhan tetapi tidak membuktikan kontribusi kausal tiap perubahan.

F. Referensi

• Paper lengkap
• DOI: 10.69916/jkbti.v5i3.566

Studi Kasus 5: Prototype Blog UGM , Third-party Script ke Web Worker

Identitas

• Website/proyek: Prototype blog berbasis skenario nyata
• Platform/teknologi: HTML5, CSS, JavaScript, Web Worker, Service Worker
• Pelaksana: Muhammad Pazrin Andreanor dan Nur Rokhman
• Institusi/negara: Universitas Gadjah Mada, Indonesia
• Tanggal pelaksanaan: Sebelum Januari 2026
• Tanggal publikasi: IJCCS Vol. 20 No. 2, April 2026
• Sumber asli: Website Optimization by Relocating Third-Party Script Using Web Worker

A. Apa Masalahnya?

Third-party script dieksekusi pada main thread sehingga bersaing dengan rendering dan user interaction. Pada prototype blog, kondisi tanpa Web Worker menghasilkan TBT 367 ms dan Performance 82. journal.ugm.ac

B. Sumber Masalah

Klasifikasi: CODE. Akar masalah diverifikasi melalui perubahan lokasi eksekusi dan pemeriksaan call stack. Setelah offloading, aktivitas komputasi tetap ada tetapi berpindah ke background thread; ini lebih kuat daripada sekadar menyimpulkan dari audit “third-party code”. journal.ugm.ac

C. Before & After

D. How To

1. Bangun baseline dengan third-party script berjalan pada main thread.
2. Instrumentasikan aplikasi untuk menangkap pemuatan script dari DOM.
3. Tempatkan script dalam secure iframe sandbox.
4. Jalankan pekerjaan script pada Web Worker.
5. Gunakan Service Worker sebagai perantara komunikasi.
6. Terapkan Proxy Pattern untuk operasi DOM/window yang tidak dapat dilakukan langsung dari worker.
7. Ukur Lighthouse sebelum dan sesudah.
8. Pantau memory melalui Chrome DevTools dan kedalaman call stack melalui Console.
9. Uji kondisi cold load, warm load, dan new session untuk tinjauan resource. journal.ugm.ac

E. Hasil dan Bukti

Performance naik 12 poin, LCP turun 0,5 detik, FCP turun 0,3 detik, TBT turun 87 ms, dan CLS menjadi nol. journal.ugm.ac Kasus ini merupakan implementasi eksperimental yang sengaja dikembangkan untuk penelitian, bukan website produksi publik. Paper juga tidak menyebut Lighthouse version, device profile, jumlah run, atau konfigurasi network throttling.

F. Referensi

• PDF paper
• DOI: 10.22146/ijccs.108581

Studi Kasus 6: Prototype Company Profile UGM , Main-thread Offloading

Identitas

• Website/proyek: Prototype company profile berbasis skenario nyata
• Platform/teknologi: HTML5, CSS, JavaScript, Web Worker, Service Worker
• Pelaksana: Muhammad Pazrin Andreanor dan Nur Rokhman
• Institusi/negara: Universitas Gadjah Mada, Indonesia
• Tanggal publikasi: April 2026
• Sumber asli: Paper UGM

A. Apa Masalahnya?

Prototype memiliki navigation, slider, contact form, dan third-party script yang dieksekusi pada main thread. Baseline TBT mencapai 367 ms dan Performance 82. journal.ugm.ac

B. Sumber Masalah

Klasifikasi: CODE. Eksperimen mempertahankan website dan intervensi yang sama, kemudian memindahkan eksekusi third-party script ke background worker. Penurunan TBT dan call-stack depth pada main thread mendukung mekanisme yang diajukan. journal.ugm.ac

C. Before & After

D. How To

Langkah implementasinya sama dengan prototype blog: isolate script dalam sandbox, offload ke Web Worker, gunakan Service Worker untuk komunikasi, dan gunakan Proxy Pattern untuk operasi DOM terbatas. Pengujian Lighthouse dilakukan kembali setelah mekanisme worker aktif. journal.ugm.ac Call stack main thread rata-rata dilaporkan turun dari sekitar 10 menjadi 4–6, sedangkan aktivitas background thread tetap tinggi. Artinya pekerjaan tidak dihapus, melainkan didistribusikan ulang. journal.ugm.ac

E. Hasil dan Bukti

Performance naik 15 poin, TBT turun 157 ms, LCP turun 0,3 detik, dan Speed Index turun 0,5 detik. journal.ugm.ac Keterbatasannya sama dengan prototype blog: bukan deployment produksi, tidak ada URL publik, tidak ada RUM, dan parameter Lighthouse tidak dipublikasikan. Klaim abstrak mengenai tambahan memory 5–10 MB juga tidak sepenuhnya selaras dengan tabel memory yang menunjukkan perubahan jauh lebih kecil, sehingga trade-off memory perlu diverifikasi ulang. journal.ugm.ac

F. Referensi

• PDF paper
• DOI: 10.22146/ijccs.108581

Studi Kasus 7: Prototype E-commerce UGM , TBT dan LCP

Identitas

• Website/proyek: Prototype e-commerce berbasis skenario nyata
• Platform/teknologi: HTML5, CSS, JavaScript, Web Worker, Service Worker
• Pelaksana: Muhammad Pazrin Andreanor dan Nur Rokhman
• Institusi/negara: Universitas Gadjah Mada, Indonesia
• Tanggal publikasi: April 2026
• Sumber asli: Paper UGM

A. Apa Masalahnya?

Prototype e-commerce merupakan objek paling kompleks, dengan product listing, cart, filtering, dan dynamic UI. Baseline LCP mencapai 2,7 detik, TBT 350 ms, dan Performance 75. journal.ugm.ac

B. Sumber Masalah

Klasifikasi: CODE. Third-party JavaScript membebani main thread yang juga menjalankan dynamic UI e-commerce. Eksperimen memverifikasi penyebab dengan membandingkan sistem identik tanpa dan dengan offloading. journal.ugm.ac

C. Before & After

D. How To

1. Jalankan product listing, cart, filtering, dan third-party script pada main thread sebagai baseline.
2. Tangkap third-party script melalui application-side logic.
3. Isolasi script dalam iframe sandbox.
4. Pindahkan pekerjaan nonkritis ke Web Worker.
5. Gunakan Service Worker untuk pertukaran data.
6. Proxy permintaan DOM/window yang memang diperlukan kembali ke main thread.
7. Ukur LCP, FCP, TBT, CLS, Speed Index, Performance, memory, dan call-stack behavior.
8. Bandingkan kondisi tanpa dan dengan worker. journal.ugm.ac

E. Hasil dan Bukti

Performance naik 19 poin, tertinggi di antara tiga prototype. LCP turun satu detik, FCP turun 0,4 detik, dan TBT turun 110 ms. journal.ugm.ac Hasil menunjukkan bahwa offloading dapat efektif ketika third-party execution benar-benar menjadi bottleneck. Namun, pendekatan ini bukan solusi universal: script yang sangat bergantung pada DOM, urutan sinkron, atau API browser tertentu memerlukan proxy dan komunikasi kompleks; paper juga meminta pengujian lanjutan pada lebih banyak perangkat, browser, dan kondisi jaringan. journal.ugm.ac

F. Referensi

• PDF paper
• DOI: 10.22146/ijccs.108581