## Summary - move the complete GitBook documentation tree and assets into Builder under `/docs` - generate the exhaustive MCP page from the local CLI source in the same change - publish GitBook from a release-gated `docs` branch containing the exact successfully released revision - run MCP documentation tests, typechecking, and stale-output checks with the existing generated-docs check - remove links to the Community Discussions repository ## Technical choices - Import the current documentation as a linear snapshot so the branch satisfies Builder's required-linear-history protection. - Keep the Markdown wrapper separate from the TypeScript generator at `scripts/docs/mcp-page.md`. - Generate through `packages/cli/local.js` so CLI guidance and its documentation are reviewed together. - Let `check:generated-docs` reject CLI changes that leave the committed MCP page stale. - After both GitHub release creation and package publication succeed, fast-forward the read-only `docs` branch to the immutable release tag commit. A divergent update fails instead of publishing a different revision. - Configure GitBook to publish `/docs` from the `docs` branch, not directly from `main`. - Exclude `/docs` from the repository-wide `oxfmt` scan so imported GitBook Markdown retains its established formatting; generator tests and stale-output checks still validate the MCP page. - Exclude `transcripts/` and GitHub Discussions from the migration. ## Todo - [x] Import documentation, navigation, includes, and assets under `/docs`. - [x] Generate the MCP page from the local CLI source. - [x] Move MCP generation and validation into Builder. - [x] Require MCP documentation updates alongside CLI changes. - [x] Publish released revisions through a read-only `docs` branch. - [x] Remove Community repository links from Builder and the migrated docs. - [x] Preserve and verify a final Community Git bundle locally. - [ ] Merge this pull request. - [ ] Let the next successful release create or advance the `docs` branch. - [ ] Repoint GitBook Git Sync to `webstudio-is/webstudio`, branch `docs`, root directory `/docs`. - [ ] Verify `docs.webstudio.is`, navigation, assets, anchors, and the MCP page in production. - [ ] Delete `webstudio-is/webstudio-community`. ## Verification - `pnpm check:generated-docs` - `pnpm lint` - `pnpm oxfmt --check` - `git diff --check origin/main...HEAD` - generator regression test demonstrated failing when the GitBook wrapper behavior was removed, then passing after restoration - no fixture inputs or outputs are affected ## Known limitation All documentation merged after the previous release waits for the next successful release before GitBook publishes it. This deliberately keeps the public MCP reference aligned with an installable CLI revision. Ref #5986
9.4 KiB
description
| description |
|---|
| Achieve perfect Lighthouse scores with Webstudio's built-in optimizations and best practices. |
⚡ Performance
Webstudio sites are fast by default. This guide covers what's automatic and what you control.
Measuring Performance: Core Web Vitals vs PageSpeed
PageSpeed Insights runs a single Lighthouse test from one server location. It's useful for spotting issues, but a single synthetic test doesn't reflect real-world performance.
Core Web Vitals (LCP, CLS, INP) are what actually matter—they measure real user experiences across all devices, networks, and locations. A site can score 100 on PageSpeed but still have poor Core Web Vitals if real users experience slow loads.
Check your Core Web Vitals in:
- Google Search Console – Real field data from Chrome users
- PageSpeed Insights – The "Field Data" section at the top (if available)
Focus on passing Core Web Vitals thresholds, not chasing a perfect Lighthouse score.
What Webstudio Does Automatically
Image Optimization
The Image component automatically:
- Converts images to WebP/AVIF – Modern formats with better compression
- Compresses images – Reduces file size without visible quality loss
- Generates responsive sizes – Serves appropriately sized images based on screen width
- Sets width and height attributes – Prevents Cumulative Layout Shift (CLS)
You upload a high-quality image once, and visitors receive an optimized version.
{% hint style="info" %} These optimizations only apply to the Image component. Images added via HTML Embed, Content Embed, or other methods won't receive automatic optimization. {% endhint %}
Cloudflare Edge Deployment
Published sites deploy to Cloudflare Workers across 320+ global locations. Your site loads from the server closest to each visitor.
Atomic CSS
Webstudio generates minimal CSS. Styles are deduplicated and optimized, resulting in smaller file sizes than traditional class-based approaches.
Server-Side Rendering (SSR)
Pages are rendered on the server and delivered as complete HTML. This improves:
- First Contentful Paint (FCP) – Content appears faster
- SEO – Search engines receive fully rendered pages
- Time to Interactive – Less JavaScript to parse
What You Control
Image Loading: Lazy vs Eager
In the Image component settings:
| Setting | Use When |
|---|---|
| Eager | Above-the-fold images (hero, logo). Improves LCP. |
| Lazy | Below-the-fold images. Defers loading until needed. |
{% hint style="info" %} Set your hero image and logo to eager. Everything else can be lazy. {% endhint %}
Font Loading
Upload fonts directly to Webstudio instead of using external services like Google Fonts.
Why it matters:
- Eliminates third-party requests
- No additional SSL/TLS handshake to external domains
- Fonts load from the same edge location as your site
- No render-blocking external stylesheets
- No third-party tracking (Google Fonts logs visitor IP addresses)
See How to Use Custom Fonts for setup instructions.
{% hint style="danger" %} Common font mistakes:
- Large font files – Use
.woff2format for best compression - Too many font weights – Only upload weights you actually use (e.g., 400 and 700, not 100-900)
- Unused fonts – Uploaded fonts are prefetched even if not used on the page. Delete fonts you don't need from assets.
- Too many font families – Each family adds load time. Stick to 1-2 families. {% endhint %}
Subsetting Fonts (Removing Unused Characters)
Most fonts include characters for multiple languages (Latin, Cyrillic, Greek, Vietnamese, etc.). If your site only uses Latin characters, you can dramatically reduce font file size by downloading a subsetted version.
Using Google Fonts API to get Latin-only fonts:
- Go to Google Fonts and select your font
- Modify the embed URL to request only Latin characters:
https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap&subset=latin
- Open that URL in your browser – it returns CSS with links to
.woff2files - Download those
.woff2files and upload them to Webstudio
Example size reduction:
| Font | Full | Latin-only |
|---|---|---|
| Inter Regular | ~100KB | ~20KB |
| Roboto Regular | ~150KB | ~25KB |
{% hint style="info" %}
For even smaller files, use the text= parameter to include only specific characters:
https://fonts.googleapis.com/css2?family=Inter&text=ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789
{% endhint %}
Alternative tools for subsetting:
- glyphhanger – Subset fonts based on actual characters used on your site
- FontSquirrel Webfont Generator – Upload a font and select subsets
- Transfonter – Online font converter with subsetting options
Third-Party Scripts
Add scripts in Project settings or Head Slot.
Always use defer or async to prevent render-blocking:
| Attribute | Behavior | Use When |
|---|---|---|
defer |
Downloads during HTML parsing, executes after parsing completes, maintains order | Most scripts (analytics, widgets, libraries) |
async |
Downloads during HTML parsing, executes immediately when ready, no guaranteed order | Independent scripts that don't rely on other scripts |
type="module" |
Automatically deferred | ES modules |
| (none) | Blocks HTML parsing until downloaded and executed | ❌ Avoid unless absolutely necessary |
{% hint style="info" %}
When in doubt, use defer. It's safer than async because scripts execute in order.
{% endhint %}
Best practices:
- Always add
defer– Never add scripts withoutdeferorasync - Minimize third-party dependencies – Each external script adds latency
- Load scripts from fast CDNs – Use well-known CDNs that are likely already cached
Measuring Performance
Lighthouse
Run Lighthouse in Chrome DevTools (F12 → Lighthouse tab) or use PageSpeed Insights.
Key metrics:
| Metric | Target | What It Measures |
|---|---|---|
| LCP (Largest Contentful Paint) | < 2.5s | When main content is visible |
| FID (First Input Delay) | < 100ms | Responsiveness to interaction |
| CLS (Cumulative Layout Shift) | < 0.1 | Visual stability |
| FCP (First Contentful Paint) | < 1.8s | When first content appears |
| TTFB (Time to First Byte) | < 800ms | Server response time |
Common Issues and Fixes
| Issue | Cause | Fix |
|---|---|---|
| Poor LCP | Hero image loads slowly | Set image to eager, ensure it's not unnecessarily large |
| High CLS | Images without dimensions | Webstudio sets dimensions automatically; check custom embeds |
| Slow TTFB | Heavy API calls on page load | Optimize CMS queries, reduce API calls |
| Render-blocking resources | External fonts or scripts | Use uploaded fonts, defer scripts |
CMS Performance
When fetching data from external APIs:
- Minimize API calls per page – Combine requests where possible
- Use caching – Configure your CMS for appropriate cache headers
- Avoid synchronous chains – Multiple dependent API calls slow page load
See CMS for configuration details.
Self-Hosted Performance
When self-hosting, performance depends on your hosting provider. Webstudio Cloud uses Cloudflare's global edge network; self-hosted deployments may have different characteristics.
For optimal self-hosted performance:
- Choose a hosting provider with edge locations (Vercel, Netlify, Cloudflare Pages)
- Enable caching
- Use a CDN for assets
Related
- Image – Image component settings
- How to Use Custom Fonts – Font upload guide
- SEO settings – Related optimization settings
- CMS – External data fetching
- Cloudflare Website Builder – How Webstudio uses Cloudflare