` placeholders
* **Avoid injecting content above the fold** after initial render (cookie banners, notification bars)
* **Use `font-display: optional`** for custom fonts to prevent FOUT-based layout shift
```css theme={null}
@font-face {
font-family: 'Inter';
src: url('/fonts/inter.woff2');
font-display: optional;
}
```
## Hiveku-Specific Tips
Go to **Publishing > Enhancements** and enable the performance bundle — optimized cache headers, preload hints, compression. See [Site Enhancements](/how-tos/site-enhancements).
If your site is Next.js, switch `![]()
` to `` for automatic optimization (WebP conversion, responsive srcset, lazy loading).
```tsx theme={null}
import Image from 'next/image';
```
```tsx theme={null}
const Chart = dynamic(() => import('./Chart'), { ssr: false });
```
Keeps the initial bundle small and defers loading until the component is actually needed.
Under 1MB is ideal for cold start performance. Audit dependencies — a `moment` or `lodash` full import can single-handedly double bundle size. Use `date-fns` and lodash submodules instead.
## Image Optimization Walkthrough
In DevTools Network tab, filter by image type, sort by size. Anything over 500KB is a candidate.
Use `sharp`, ImageMagick, or an online tool. WebP is universally supported; AVIF is smaller but slightly less compatible.
```html theme={null}
```
```html theme={null}
```
Don't lazy-load the hero — that hurts LCP.
## Third-Party Script Audit
Run Lighthouse. Look at the "Third-party usage" section. Anything taking over 500ms of main thread time is a candidate for:
* **Defer** — load after the page is interactive (chat widgets, analytics)
* **Replace** — swap heavy tools for lighter ones (Plausible instead of Google Analytics if privacy + perf matter more than integrations)
* **Remove** — if nobody uses it, it shouldn't be loading
Chat widgets, cookie consent banners, and A/B testing tools are the top three CLS offenders. Audit them specifically — they often inject content above the fold after the page renders, which tanks both LCP and CLS.
## Cache Strategy
Hiveku's CDN caches static assets by default. For maximum effect:
* **Versioned assets** — set `Cache-Control: max-age=31536000, immutable`. Asset URLs change with each deploy, so the browser caches forever with no staleness risk.
* **HTML** — shorter cache (e.g., 60s) or `no-cache` with ETag validation so updates appear fast
* **API responses** — cache carefully. Use `Cache-Control: private, max-age=60` for user-specific data, public cache for non-personalized
## Verify It Worked
1. Run Lighthouse before making changes — note your baseline scores
2. Deploy optimizations
3. Run Lighthouse again on the same page
4. Target 90+ on Performance for mobile
5. Confirm LCP \< 2.5s, INP \< 200ms, CLS \< 0.1
Don't stop at Lighthouse — real-user data lives in Google Search Console's Core Web Vitals report (or PageSpeed Insights with the CrUX field data panel). That's what affects rankings.
## Troubleshooting
A render-blocking script is the usual culprit. In DevTools Network, filter by "JS" and look at what's loading before the hero image — anything with high priority that isn't essential is blocking paint. Defer it or remove it. Alternatively, server response time is too high — check Time to First Byte in the waterfall.
Profile the interaction in DevTools Performance tab. Record, click the slow element, stop recording. The flame chart shows exactly which function is eating the main thread. Common offenders: large state updates, synchronous DOM queries inside loops, analytics firing on every click.
Something you added is inserting content dynamically above the fold. Most common causes: a new chat widget, a cookie consent banner, a notification bar, or a late-loading hero image without fixed dimensions. Compare the "Before" and "After" diagnostic screenshots in Lighthouse.
Lighthouse is synthetic (simulated). CrUX is real users with their real networks and devices. Improvements take 28 days to fully reflect in CrUX because it's a rolling window. If the gap is large, your synthetic test conditions don't match your real users — try throttling harder (3G, slow CPU) to match actual field conditions.
Lighthouse may be complaining about dimensions (served larger than displayed), not file size. Check the Lighthouse report details — it tells you the exact mismatch. Serve the right size for each breakpoint with `srcset`.
## What's Next?
Run a full SEO + performance audit with the AI
Enable optimized headers, caching, and compression
```
## INP Improvements
INP measures how fast the page responds to user input. Slow JavaScript is almost always the culprit.
* **Break up long tasks** — split 200ms+ operations into smaller chunks with `setTimeout` or `requestIdleCallback`
* **Debounce expensive handlers** — especially `onScroll`, `onInput`, `onResize`
* **Move work off the main thread** — Web Workers for heavy computation, server for data crunching
* **Defer non-critical third-party scripts** — chat widgets, analytics, A/B test tools
The "Performance" tab in Chrome DevTools shows you exactly which handlers are blocking the main thread. Record an interaction, find the long task, optimize the handler.
## CLS Improvements
CLS penalizes layout shifts that happen after initial render. Most fixes are structural.
* **Always set `width` and `height`** on images, videos, iframes, and embeds
* **Reserve space for ads and lazy-loaded content** — empty `