You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of the public-site performance plan (master issue linked above). Needs no CDN or new infrastructure.
Goal
Reduce how much JavaScript and how many bytes each public page sends, so LCP, INP and CLS improve whatever the TTFB.
Tasks
Record a baseline first: Lighthouse on a sample tenant (home, docs page, blog post) plus server-side TTFB, so each change below can be measured.
Render pages with server components. (Improve public site rendering performance #78) Today packages/page-builder/scripts/add-use-client.mjs marks every built file "use client", and src/renderer/page-renderer.tsx and apps/sites/components/site-page-renderer.tsx are client components, so the whole layout JSON and every block ship to the browser and run there.
Add a renderer entry that works on the server. Static blocks render on the server; only interactive blocks (FAQ, marquee, forms, theme mode switcher, docs search) stay client components.
Exclude that entry from the post-build "use client" step. The builder entry used by apps/web stays fully client.
Move theme resolution (resolveSiteTheme) out of the client wrapper.
Lazy-load the chat widget (Improve public site rendering performance #78) (apps/sites/app/sites/[teamId]/layout.tsx): render only the launcher button; load the panel when the browser is idle or on first interaction.
Lock down images.remotePatterns (Improve public site rendering performance #78, IMAGE_REMOTE_HOSTS) in apps/sites/next.config.mjs. It is hostname: "**" today, which makes the optimizer an open image proxy; limit it to the media host(s).
Preload the active theme fonts only. (Improve public site rendering performance #78) Fonts are self-hosted with preload: false (apps/sites/lib/fonts.ts); add <link rel="preload"> for the fonts the active theme uses.
Preconnect for media origins (local Lighthouse on sendlit.app, 19 Oct, 4 mobile runs): the homepage loads an above-the-fold image from cdn.medialit.cloud, but the page has no <link rel="preconnect"> for that origin, which Lighthouse estimates costs about 300 ms on mobile.
Proposal: when rendering a page, collect the origins of images and media used in the first blocks (hero, first section) and the site's configured media CDN, then emit preconnect (plus dns-prefetch as a fallback) in the head automatically. This should be general for any hosted customer and any media host, not hard-coded to MediaLit.
Activity
clbotdev commentedon Oct 19, 2026
Preconnect for media origins (local Lighthouse on sendlit.app, 19 Oct, 4 mobile runs): the homepage loads an above-the-fold image from
cdn.medialit.cloud, but the page has no<link rel="preconnect">for that origin, which Lighthouse estimates costs about 300 ms on mobile.Proposal: when rendering a page, collect the origins of images and media used in the first blocks (hero, first section) and the site's configured media CDN, then emit
preconnect(plusdns-prefetchas a fallback) in the head automatically. This should be general for any hosted customer and any media host, not hard-coded to MediaLit.s3rot0n1n commentedon Oct 25, 2026
I ran pagespeed on sendlit.app hosted via frontlit sites, here are the numbers:
https://pagespeed.web.dev/analysis/https-sendlit-app/eg0cjx7p2n?form_factor=desktop
https://pagespeed.web.dev/analysis/https-sendlit-app/eg0cjx7p2n?form_factor=mobile
clbotdev commentedon Oct 25, 2026
Baseline and results recorded (Lighthouse 13, mobile, simulated throttling, median of 5, same sample tenant). The full table is in #142.
#142 also fixes article and feed images that still served full-size originals: blog post image bytes 172 KB → 44 KB.
The editor preview in apps/web is unchanged; #142 only touches the server
Imageprimitive and the sites app.Merge pull request #142 from codelitdev/perf/sites-phase1-followups
clbotdev commentedon Oct 25, 2026
Done: #78 (implementation) and #142 (article/feed images). Measurements in #142 and in this issue's comments.