Frequently asked questions

Yes. Webstudio uses the IPX optimizer to serve optimal formats (AVIF, WebP, or optimized JPEG) based on browser support. Cloud hosting works out of the box. For self-hosted Docker setups ensure:

1. You pulled the latest container image
2. Dependencies are installed (pnpm install / npm install)
3. No proxy strips Accept headers (required for content negotiation)
4. Caching layer (CDN/reverse proxy) isn’t serving stale JPEG variants

If you only see optimized JPEGs, typically the Accept header is lost or optimization config is blocked.

Slow server response times are often caused by Resources (API calls) placed at the root level. If you're using a Resource globally but only need it on specific pages (like Airtable for a careers page), move the Resource to the body of that specific page instead of the root. Airtable is particularly slow - consider switching to Baserow for faster API responses. Server response times can drop from 1200ms to 200ms by moving Resources appropriately. Caching options for Resources are planned to help with slow APIs.

Slow server response times are often caused by API resources being loaded on every page, even when not needed. Solutions:

1. Move API resources from the root to specific pages where they're actually used
2. Consider faster CMS alternatives - Airtable is notably slow while Baserow is faster
3. Implement caching for API responses when data doesn't change frequently

Moving a slow Airtable resource from root to page-specific usage can reduce server response time from 1.2s to 200ms.

API limits vary by platform: Airtable's free plan has very restrictive limits that can be hit quickly. Baserow has more generous limits (around 10 concurrent requests) and works well for sites with under 1000 visitors per day. For production sites, consider self-hosting Baserow for more freedom, or use dedicated blog CMS platforms like Ghost, Hyvor Blogs, or Zenblog. Always implement caching to avoid hitting limits on every page load.

Webstudio uses atomic CSS where each CSS rule contains one property, which makes CSS stop growing after reaching a certain size. This approach dramatically reduces file sizes - Webstudio.is was reduced from 160kb to 16kb CSS. Unlike traditional builders like Webflow that can generate 75,000+ characters just for grid-spans, atomic CSS prevents bloated stylesheets and improves performance.

Intermittent server-side issue or heavy assets. Steps:

1. Retry later (could be transient load)
2. Optimize large media / reduce oversized assets
3. Temporarily remove unusually large collections or heavy embeds
4. Check browser console & network panel for failing requests
5. Contact support with project ID if a minimal single-text page still times out

Yes, Webstudio plans to add cache options for resources (GitHub issue 4077). This would allow users to override CMS/API cache headers and enable Cloudflare edge caching, which would improve performance and reduce API calls to the origin server. This is particularly useful for data that doesn't change frequently.

Weglot doesn't work well with Webstudio because Webstudio sites are Single Page Applications (SPAs). SPAs are faster than traditional websites because they don't reload the entire page on each navigation—instead, they dynamically update content in the browser.

Weglot struggles with SPAs for several reasons:

1. Content detection timing: Weglot scans the page HTML on load, but SPA content is rendered dynamically by JavaScript after the initial page load, so Weglot may miss content entirely.

2. Navigation without page reloads: When you navigate between pages in an SPA, the browser doesn't perform a full page reload. Weglot relies on page loads to detect and translate new content, so navigating to a new page won't trigger translation.

3. Dynamic content updates: Even with Weglot's "Dynamic" setting (which watches for DOM changes using a body selector), it can cause performance issues and may not catch all content changes reliably.

4. DNS/proxy complexity: Weglot typically works by proxying your site through their servers, which adds complexity and potential points of failure for SPA architectures.

For multilingual Webstudio sites, consider using a headless CMS with built-in i18n support (use our CMS Finder to find one that fits your needs) and fetching translated content based on language parameters in your URLs.