From cdd632ecda1e0c995b43cde9dc45c56606950d2d Mon Sep 17 00:00:00 2001 From: Metrohan Date: Fri, 17 Jul 2026 13:39:19 +0300 Subject: [PATCH 1/2] perf: drop excess preconnect hints, file SPA/no-SSR mobile FCP follow-up PSI flagged >4 preconnect hints after the earlier preload+swap change made the jsdelivr/cdnjs preconnects redundant (those origins are already deferred, so pre-warming the connection buys little). Down to the two Google Fonts origins that still matter. Also files issue 02: post-fix mobile PSI (Performance 52) shows FCP/LCP now bottlenecked on JS boot time (SPA has no SSR), not render-blocking CSS anymore -- that's an architectural change, not a markup patch. Co-Authored-By: Claude Sonnet 5 --- .../issues/02-spa-no-ssr-slow-mobile-fcp.md | 54 +++++++++++++++++++ frontend/index.html | 2 - 2 files changed, 54 insertions(+), 2 deletions(-) create mode 100644 .scratch/perf-third-party-images/issues/02-spa-no-ssr-slow-mobile-fcp.md diff --git a/.scratch/perf-third-party-images/issues/02-spa-no-ssr-slow-mobile-fcp.md b/.scratch/perf-third-party-images/issues/02-spa-no-ssr-slow-mobile-fcp.md new file mode 100644 index 0000000..dad50dd --- /dev/null +++ b/.scratch/perf-third-party-images/issues/02-spa-no-ssr-slow-mobile-fcp.md @@ -0,0 +1,54 @@ +# Mobile FCP/LCP stuck around 5s: no SSR, blank until JS boots + +Status: needs-triage + +## Context + +After fixing render-blocking CDN CSS and the CLS regressions (see issue 01 +and the `fix/google-search-console` PR), a fresh mobile PageSpeed run +(Moto G Power, Slow 4G, 2026-07-17 13:35) still scores Performance 52: + +- FCP 4.9s, LCP 5.0s, TBT 0ms, CLS 0.364, SI 4.9s +- LCP breakdown: TTFB 0ms, **"Öğe oluşturma gecikmesi" (element render + delay) 2700ms** — i.e. almost the entire LCP time is spent *after* + resources finish loading, waiting for something to actually paint. +- The render-blocking-CSS audit is now down to just our own bundled + `index-*.css` (~120ms estimated savings) — the Bootstrap/FontAwesome/ + Google Fonts preload+swap fix from the earlier round worked as intended. + +## Root cause + +`frontend/` is a client-rendered SPA (Vite + React, `ReactDOM.createRoot` +in `main.jsx`, no SSR/prerendering). Under throttled mobile networks, +nothing paints until: HTML → JS bundle downloads → parses → executes → +React mounts. CSS optimization can't fix this because the bottleneck has +moved to JS boot time, not stylesheet blocking. + +## Why this is a separate issue + +Fixing this properly means one of: +1. Server-side rendering or static prerendering for at least the initial + HTML shell (e.g. Vite SSR, or a prerendering step for the + landing/listing pages that dominate organic traffic). +2. Reducing the JS payload needed before first paint (the `vendor-*.js` + chunk is 163KB / 54KB gzipped) via further code-splitting. + +Both are meaningfully larger changes than the markup/nginx/CSS fixes +already shipped — they touch the build pipeline and possibly hosting +(SSR needs a Node runtime, not just static files behind nginx). Out of +scope for incremental PageSpeed patches. + +## Suggested approach (not decided) + +- Start with a scoped prerendering pass (e.g. `vite-plugin-ssg` or a + simple build-time render of `/`, `/takvim`, `/hackathonlar`, etc. — the + pages in `frontend/public/sitemap.xml` — into static HTML) rather than + full SSR, since these pages don't need per-request personalization. +- Re-measure FCP/LCP against the *current* baseline (this issue) after + any change, not the original pre-fix numbers, to isolate the effect. + +## Acceptance criteria + +- [ ] Mobile FCP/LCP measurably improve without regressing CLS/TBT +- [ ] The homepage still functions correctly for client-side interactions + (filters, search, favorites) after any prerendering change diff --git a/frontend/index.html b/frontend/index.html index e00a0f3..93d4389 100644 --- a/frontend/index.html +++ b/frontend/index.html @@ -28,8 +28,6 @@ - -