Faisal Journals
🟑 SEVIMA

System Performance

Data Lighthouse audit, load testing JMeter, dan analisis disonansi antara UX satisfaction dan synthetic benchmark.

πŸ“Š System Performance Data

Web Performance (Independent Audit)

Audit tanggal 25 Feb 2026 β€” sevima.com (desktop)

MetricValueScoreStatus
FCP (First Contentful Paint)3.0s6/100πŸ”΄
LCP (Largest Contentful Paint)5.0s8/100πŸ”΄
TBT (Total Blocking Time)1,030ms5/100πŸ”΄
CLS (Cumulative Layout Shift)0.48217/100πŸ”΄
Speed Index18.8s0/100πŸ”΄
Time to Interactive18.6s0/100πŸ”΄
Performanceβ€”8/100πŸ”΄
Accessibilityβ€”73/100🟑
Best Practicesβ€”56/100πŸ”΄
SEOβ€”92/100🟒

Dari riset eksternal menggunakan PageSpeed Insights & GTmetrix:

MetricValueNotes
Average Performance Score81.87/100Termasuk "baik" tapi ada ruang improvement
Information Quality Score92.8%Konten informatif, arsitektur informasi baik
Usability Index94.1%Persepsi user sangat positif
Service Quality Index93.9%User puas dengan fungsionalitas

Masalah yang teridentifikasi:

  • Image optimization kurang (kompresi tidak optimal)
  • DOM element sizes terlalu besar
  • JavaScript execution time menghambat render
  • Accessibility gagal memenuhi minimum requirements (kontras visual)

Load Testing (Apache JMeter)

FaseVirtual UsersTotal RequestsError RateStatus
Ringan5 VU1050.00%βœ… Perfect
Menengah15 VU3150.32%βœ… Marginal
Overload45 VU9451.90%βœ… Under 2% threshold

Analisis Disonansi

Performance Insight β€” Amunisi Loom Audit

Ada disonansi yang sangat menarik: backend mereka solid (error rate < 2% under stress), tapi frontend marketing site sangat lambat (Performance 8/100). Ini menunjukkan engineering resource difokuskan ke produk, bukan website. Untuk Loom Audit, fokus ke product performance (yang 81.87) bukan marketing site (yang 8).

User satisfaction (94.1%) > synthetic benchmark (81.87) β†’ fungsionalitas sudah menang, tapi ada ruang untuk optimization yang bisa jadi scope kontrak kita.

Rencana Aksi Perbaikan (Lighthouse & PageSpeed)

πŸ“Œ Tujuan: Turunkan LCP < 2s (field), FCP < 1.5s stabil, Performance > 85 Fokus: Efficiency dulu, bukan redesign.


⚑ QUICK WIN (Bisa dilakukan < 1–3 hari)

1️⃣ Buang / Ganti Icon Font 379KB (Impact paling besar)

Fact: sevima-icons.ttf = 379KB blocking Action:

  • Ganti ke SVG sprite
  • Atau subset font (glyph hanya yang dipakai)
  • Tambahkan:
@font-face {
  font-display: swap;
}

🎯 Estimasi: -400–600ms LCP


2️⃣ Tambahkan fetchpriority="high" pada Hero LCP

<img src="/image-hero.webp" fetchpriority="high" width="..." height="..." />

🎯 Estimasi: -100–200ms LCP


3️⃣ Inline Critical CSS (Above the Fold)

Fact: Banyak CSS blocking Action:

  • Extract hero + navbar CSS
  • Inline di <head>
  • Load sisanya async

Contoh:

<link
  rel="preload"
  href="/main.css"
  as="style"
  onload="this.rel='stylesheet'"
/>

🎯 Estimasi: -300–500ms FCP


4️⃣ Defer Semua Third Party JS

Pindahkan ke bawah + defer

  • Facebook
  • Mixpanel
  • Clarity
  • Analytics
<script defer src="..."></script>

🎯 Estimasi: -200–300ms TBT


5️⃣ Set Cache-Control (Repeat Visit Boost)

Cache-Control: public, max-age=31536000, immutable

Untuk:

  • fonts
  • images
  • js/css hashed

🎯 Field data akan membaik dalam 28 hari


🧠 Medium Effort (1 minggu)

6️⃣ Kurangi Font Weight

Sekarang:

  • Regular
  • Medium
  • SemiBold
  • Bold

πŸ‘‰ Turunkan jadi 2 weight saja.

🎯 -150–300ms


7️⃣ Delay Animation (GSAP / Glide)

Load setelah:

requestIdleCallback();

Jangan animasi di above-the-fold saat first paint.


πŸ”₯ Hardcore Mode (Kalau mau Score 90+)

  • Hapus FontAwesome (pakai SVG)
  • Hapus jQuery (kalau hanya untuk select2)
  • Server push / preload hero image
  • Convert semua hero background ke WebP AVIF
  • Remove blocking CSS chain

🎯 Prioritas Urutannya

  1. ❗ Icon font 379KB
  2. ❗ Critical CSS inline
  3. ❗ fetchpriority hero
  4. ❗ Defer tracking
  5. Cache TTL

🧩 Diagnosis Jujur

Server sehat (TTFB bagus). Masalah murni front-end layering + marketing scripts.

Ini bukan problem infra. Ini problem asset governance & critical path discipline.

Kalau Anda mau, saya bisa buatkan versi:

  • β€œMinimal change” plan (WordPress friendly)
  • atau β€œRe-architect front layer” plan (clean static + headless WP)
Edit on GitHub

Last updated on