type: config

name: Bumicerts Lighthouse homepage performance

bestDirection: higher


status: crash

description: Baseline Lighthouse run failed because CLI does not accept one shared --output-path for multiple outputs

hypothesis: Initial objective eval script can build, serve, and run Lighthouse with JSON+HTML artifacts in one invocation.

rollback_reason: Lighthouse CLI requires distinct output path handling for multiple formats; no app code was changed.

next_action_hint: Run Lighthouse JSON only in autoresearch loop, then generate/copy HTML artifact in a separate command for the final report.


description: Baseline eval still failed before Lighthouse output

hypothesis: JSON-only Lighthouse eval should fix output path failure.

rollback_reason: Run exited quickly with no captured stderr; likely shell compatibility or preflight issue before app build/server completed.

next_action_hint: Run the script with bash tracing or inspect generated build/server logs, then harden the eval script.


description: Baseline eval still failed after stale lock cleanup

hypothesis: Removing stale .next/lock before build should let baseline eval proceed.

rollback_reason: Run still exited before useful output; stale lock was not the only preflight issue.

next_action_hint: Inspect build log immediately; pgrep may match the autoresearch shell text itself, so lock cleanup condition may be wrong.


status: keep

description: Baseline Lighthouse performance score for mobile homepage/root route

hypothesis: Root route Lighthouse score is limited primarily by LCP and transfer weight, while TBT and CLS are already good.

scoring_reference: Chrome Lighthouse scoring doc: weighted performance metrics FCP 10%, Speed Index 10%, LCP 25%, TBT 30%, CLS 25%.


status: discard

description: Converted landing PNG photos to JPEG and updated homepage references; transfer/LCP improved but rounded Lighthouse score did not

hypothesis: Large local PNG landing images dominate transfer weight and delay LCP; JPEG versions should improve Lighthouse performance.

result: Transfer dropped from 12522.1 KiB to 3392.4 KiB and LCP from 41.7s to 11.4s, but performance_score stayed 74.

rollback_reason: Primary metric did not improve after rounding; image optimization alone is insufficient.

next_action_hint: Address the text LCP render delay from client-side framer-motion/landing hydration or reduce app-wide client providers on the static homepage.


description: Made hero H1/icon visible immediately instead of framer-motion entering; LCP improved but Speed Index worsened and score dropped

hypothesis: Animated opacity/transform on the text LCP candidate delays the Largest Contentful Paint metric.

result: LCP improved to 7.5s, but Speed Index worsened to 4.7s and score dropped to 73 in this run.

rollback_reason: Primary Lighthouse score regressed.

next_action_hint: Keep image compression, but prefer broader route/provider JS reductions or re-run noisy variants before removing hero text animation.


description: Resized/compressed JPEG landing images more aggressively; transfer improved but score regressed in noisy run

hypothesis: Smaller physical image dimensions should reduce transfer and image decode enough to improve Lighthouse score.

result: Transfer dropped to 2135.7 KiB, but Speed Index worsened to 4.7s and performance_score fell to 72.

rollback_reason: Primary score regressed; image bytes are not the only score driver and Lighthouse variance is material.

next_action_hint: Target client bundle/root providers or run repeated samples after structural changes; avoid relying on byte reduction alone.


description: Split root landing page out of marketplace layout and use minimal root providers on /; keep compressed landing JPEGs

hypothesis: The static landing route was paying for app-wide marketplace providers and large passthrough PNG assets; isolating / and using smaller JPEGs should improve Lighthouse's weighted score.

result: Performance score improved from 74 to 75; FCP improved 1209→1058ms, Speed Index 3433→1262ms, TBT 41→0ms, total bytes 12522→1866 KiB, LCP 41.7→9.9s.

scoring_reference: Chrome Lighthouse performance score weights: FCP 10%, Speed Index 10%, LCP 25%, TBT 30%, CLS 25%.

kept_without_commit: Autoresearch was run from /Users/satyam/Desktop/Projects as requested; no repository commit was made.


description: Kept root route/provider split and image compression; made hero LCP text/icon render immediately

hypothesis: With the homepage isolated from heavy providers, the remaining LCP delay is the framer-motion entry animation wrapping the H1 and icon; rendering the LCP content immediately should improve the weighted score.

result: Performance score improved to 84; LCP improved to 4.6s, Speed Index to 1.2s, and TBT stayed 0ms.

kept_without_commit: No commit was made; changes remain in the bumicerts-monorepo working tree.


description: Removed unused Cormorant Garamond italic/600 font preloads while preserving homepage weights

hypothesis: The H1 LCP candidate depends on Garamond; preloading unused Garamond variants competes with critical font/image work and delays text LCP.

result: Score improved 84→89; LCP improved 4622→3776ms while FCP/Speed Index/TBT stayed essentially stable.

why_safe: Kept normal weights used on the homepage (300, 400, 500, 700) and removed only the unused italic style plus 600 weight from the Garamond font config.

next_action_hint: Consider a small homepage-specific app icon asset or reduce remaining global font/provider payload, but verify visual impact and avoid broad app regressions.


description: Tested a 96px homepage hero icon asset to replace the oversized 512px app icon

hypothesis: The oversized 512px PNG app icon in the hero H1 contributes unnecessary transfer/decode work near the LCP candidate; a smaller derived icon should improve LCP and score without visual impact.

result: Total byte weight stayed similar/slightly worse in this run and LCP regressed 3776→4041ms; score fell 89→87.

rollback_reason: Primary Lighthouse score regressed, likely due to noise or because the icon was not the limiting LCP resource after font optimization.

next_action_hint: Do not prioritize tiny icon asset swaps; inspect remaining LCP font/CSS critical path or repeat promising high-level provider/font reductions.


description: Removed Garamond 500 preload by changing homepage wordmark to normal weight

hypothesis: After removing italic and 600, the remaining Garamond 500 preload may still compete with the H1's critical 300 weight; changing the small navbar wordmark to normal should allow dropping 500 safely.

result: Score stayed flat at 89; LCP was marginally lower but Speed Index/TBT worsened slightly, so there was no primary improvement.

rollback_reason: Primary Lighthouse score was unchanged versus the best run, so the experiment is not kept.

next_action_hint: Do not spend more effort shaving small font variants; focus on structural JS/CSS or critical LCP resource ordering with a clear score gain.


description: Replaced client TopNavbar on the landing route with a server-rendered static navbar

hypothesis: The root page still imports a client TopNavbar with framer-motion, vaul drawer, theme toggle, and progressive blur; replacing it with equivalent server-rendered navigation should reduce route JavaScript and improve Lighthouse score.

result: Total byte weight changed little and performance score regressed 89→85, with LCP worsening to 4.394s.

rollback_reason: Primary Lighthouse score regressed; the client navbar was not the current limiting factor, and the static variant also altered mobile menu behavior.

next_action_hint: Revert to TopNavbar. Focus next on reducing the LCP text/font critical path or validating the 89 score with repeat runs rather than removing low-impact client UI.


description: Tested rendering the hero H1 with system Georgia instead of Garamond while restoring the best TopNavbar route split

hypothesis: Because the H1 is the LCP element, using a system serif for only that text might avoid webfont-dependent LCP delay without broad layout changes.

result: Score stayed flat at 89; LCP was effectively unchanged versus best (3773ms vs 3776ms) and Speed Index/TBT were slightly worse.

rollback_reason: Primary score did not improve; the H1 font face itself is not the remaining bottleneck after prior font preload reduction.

next_action_hint: Focus on non-font critical path or validate current best with repeated measurements; avoid visual font substitutions unless there is a measurable win.


description: Added explicit fetchPriority=high to the hero background and inline icon images

hypothesis: Although Next Image priority preloads the hero image and icon, Chrome still reported them as low-priority requests; explicit fetchPriority=high might improve critical resource ordering and LCP.

result: Score regressed to 79 and LCP worsened to 5712ms; byte weight was unchanged.

rollback_reason: Primary Lighthouse score regressed substantially; fetchPriority did not improve this Next/Image preload path and may have competed with critical fonts/CSS.

next_action_hint: Remove explicit fetchPriority. Current promising baseline remains root route split + compressed landing JPEGs + immediate H1 + reduced Garamond variants.


description: Removed the hero background image's framer-motion opacity/scale entrance animation

hypothesis: The animated background starts at opacity 0 and may delay visual completeness; rendering it immediately could improve Speed Index and possibly LCP without changing content.

result: Speed Index improved to 1058ms, but LCP regressed to 4399ms and the overall score fell to 85.

rollback_reason: Primary Lighthouse score regressed; the background animation is not worth changing for performance score.

next_action_hint: Avoid optimizing Speed Index in isolation while LCP has 25% weight; look for changes that reduce LCP without sacrificing other weighted metrics.


description: Reduced Garamond preload set to only the critical 300 weight used by the hero H1

hypothesis: The LCP element uses Garamond 300, so preloading only that weight could reduce font contention and total bytes while preserving the critical above-the-fold font.

result: Total byte weight fell slightly to 1811.5 KiB, but LCP regressed to 4317ms and score dropped to 85.

rollback_reason: Primary Lighthouse score regressed; removing noncritical Garamond weights did not improve the critical path and could affect visual typography elsewhere.

next_action_hint: Restore Garamond weights 300/400/500/700 normal. Further font shaving is not promising; consider repeated validation or other structural route-level changes.


description: Removed priority preload from the small inline app icon inside the hero H1

hypothesis: The small inline icon preload may compete with the hero text font and background image; leaving only the actual hero background as priority could improve LCP ordering.

result: Score regressed from the current best 89 to 87; LCP worsened to 4113ms while other metrics were stable.

rollback_reason: Primary Lighthouse score regressed; keeping the icon priority is better for the current LCP behavior.

next_action_hint: Restore the icon priority. Remaining promising work likely requires structural changes or repeated validation rather than deprioritizing small above-the-fold assets.


description: Removed priority preload from the hero background image while keeping the inline icon priority

hypothesis: Because the H1 text is the LCP element, the large hero background preload might compete with critical fonts; deprioritizing it could improve LCP ordering without hurting above-the-fold rendering too much.

result: Score regressed 89→87 and LCP worsened to 4036ms; FCP and TBT were stable.

rollback_reason: Primary score regressed; the hero background priority supports rather than harms the current critical path.

next_action_hint: Restore hero background priority. Avoid further priority toggles; remaining opportunities likely require larger architectural changes or repeated current-best validation.


description: Converted compressed landing JPEG photos to resized AVIF and updated homepage references

hypothesis: Lighthouse image delivery still reported modern-format savings for the landing photos; AVIF should reduce transfer weight and image decode cost without changing content.

result: Total byte weight improved from ~1826 KiB to 1531 KiB, but LCP regressed to 4325ms and performance score fell to 85.

rollback_reason: Primary Lighthouse score regressed despite lower bytes; AVIF decode/critical-path behavior appears worse for this above-the-fold route than JPEG.

next_action_hint: Keep the JPEG landing assets for now. Further image byte reductions should be validated specifically against LCP, not just total transfer.


description: Attempted to remove secondary hero text/CTA motion after restoring JPEG refs, but file corruption caused build parse errors

hypothesis: Rendering the hero paragraph and CTA immediately could reduce above-the-fold hydration/motion work without affecting content.

error_details: Build failed: Hero.tsx line 21 and WhatIsBumicert.tsx line 143 contained stray text from a malformed edit around image src/coverImage attributes.

rollback_reason: Crash due to edit corruption, not a meaningful performance result.

next_action_hint: Repair Hero.tsx image src and WhatIsBumicert coverImage attributes to valid JSX, restore JPEG refs, then retry the secondary motion-removal idea only after the build passes.


description: Rendered hero paragraph and CTA immediately instead of animating them with framer-motion

hypothesis: Removing nonessential above-the-fold framer-motion wrappers for the paragraph and CTA should reduce hydration/scheduling work while preserving content and layout.

result: Build passed after repairing JSX, but score regressed 89→85; LCP worsened to 4345ms and TBT rose to 25ms.

rollback_reason: Primary Lighthouse score regressed; secondary hero motion removal is not beneficial for the measured weighted score.

next_action_hint: Restore paragraph/CTA motion. Current best remains root isolation + JPEG assets + immediate H1/icon + reduced Garamond styles.


description: Removed Instrument Serif from the highlighted phrase inside the hero H1 so the LCP text uses one font family

hypothesis: The H1 is the LCP element and mixes Garamond with Instrument Serif italic; making the highlighted phrase use the parent Garamond should reduce LCP font dependency and improve score.

result: Score regressed 89→85; LCP worsened to 4336ms and TBT rose to 16ms, with no transfer-weight benefit.

rollback_reason: Primary Lighthouse score regressed and visual emphasis was reduced.

next_action_hint: Restore Instrument Serif in the H1. Further LCP font substitutions appear unpromising; consider validating the best configuration or exploring route-level code splitting for below-the-fold sections.


description: Replaced oversized 279KB app favicon.ico with a 32px ICO generated from the app icon

hypothesis: Lighthouse reported /favicon.ico twice at ~286KB each; shrinking the favicon should reduce initial transfer weight and may improve performance score without changing page content.

result: Total byte weight improved substantially to 1548.6 KiB, but performance_score stayed flat at 89 and TBT/Speed Index slightly worsened in this run.

rollback_reason: Primary Lighthouse score did not improve; total-byte-weight is diagnostic and not directly part of the weighted score.

next_action_hint: The smaller favicon is a good hygiene idea for a separate review, but for this autoresearch primary metric it is not enough. Consider combining only if a future primary-score improvement also keeps byte weight low.


description: Returned children directly for the root route instead of wrapping / in next-themes ThemeProvider

hypothesis: The static landing page defaults to light theme and should not need next-themes; removing ThemeProvider on / may reduce client work and improve Lighthouse without changing content.

result: Score stayed flat at 89; LCP was marginally lower but TBT rose to 21ms, so there was no primary improvement.

rollback_reason: Primary Lighthouse score did not improve; keeping ThemeProvider preserves existing theme behavior on the landing page.

next_action_hint: Consider validating current best with repeated runs or only structural changes that can move rounded score above 89.


description: Removed decorative animated scroll indicator and ArrowDown icon from the hero

hypothesis: The animated scroll hint is decorative above-the-fold client work; removing it could reduce hydration/script overhead without changing core content.

result: Score regressed 89→85; LCP worsened to 4413ms and TBT rose to 17ms, with no meaningful byte-weight change.

rollback_reason: Primary Lighthouse score regressed and the UI affordance was removed.

next_action_hint: Restore the scroll indicator. Small decorative removals are not moving the score; prioritize validating the current best or larger route-level code splitting if acceptable.


description: Repeated current restored configuration to validate whether best score 89 was stable under run-to-run noise

hypothesis: Recent failed micro-optimizations may be dominated by Lighthouse variance; re-running the current restored best configuration can estimate stability and avoid overfitting to one lucky 89.

result: Repeat scored 85 with LCP 4410ms, suggesting the earlier 89 was not consistently reproduced under current workspace state or local variance.

rollback_reason: Primary score did not improve; this was a validation run, no code change intended.

next_action_hint: Inspect workspace for leftover unintended changes, especially favicon and restored Hero state; compare against the exact kept #10/#9 state before trusting subsequent experiments.


description: Inlined hero CTA button styles to avoid importing the shared Button component on the landing hero

hypothesis: The hero CTA uses Button only in its asChild styling path, but importing Button also pulls in radix Slot/CVA/motion button code; an equivalent inline Link may reduce initial JS while preserving UI.

result: Score returned to 89 with LCP 3776ms, but did not exceed the current best; Speed Index/TBT were slightly worse than best.

rollback_reason: Primary Lighthouse score was unchanged, so this complexity/duplication is not kept.

next_action_hint: Avoid duplicating shared Button styles for no score gain. Look for route-level code splitting or collect repeated samples of larger structural changes.


description: Moved below-the-fold landing sections behind a client dynamic-import wrapper

hypothesis: The landing route imports several below-the-fold client sections with framer-motion/state; dynamically splitting them behind the hero may reduce initial route JS and improve Lighthouse performance.

result: Score regressed to 84 and LCP worsened to 4484ms. Dynamic wrapper added indirection and did not reduce the measured critical path.

rollback_reason: Primary Lighthouse score regressed; below-the-fold dynamic splitting as implemented is not beneficial and could harm SEO/SSR for lower content.

next_action_hint: Remove DeferredHomeSections and restore direct server imports. Future structural changes should preserve SSR and target actual critical chunks, not blanket dynamic imports.


description: Restored direct SSR imports for below-the-fold homepage sections instead of the dynamic client wrapper

hypothesis: The discarded dynamic wrapper was still present in the workspace; restoring direct server imports should preserve SSR and remove client-loading indirection, improving LCP/score.

result: Score improved to 90, crossing the green threshold. LCP improved to 3618ms, Speed Index to 1201ms, TBT to 1ms while keeping byte weight low from the smaller favicon/current assets.

why_safe: This restores the original server-rendered section structure rather than hiding content behind client dynamic imports, so it avoids SEO/SSR risk.

kept_without_commit: No commit was made; autoresearch is running from /Users/satyam/Desktop/Projects so git auto-commit is unavailable.