Wix Studio Two technical differences: layout, responsive, backend and life without Velo

5 hours ago

8 min read

Wix Studio Two (also written as Studio 2) looks like a new editor, but the bigger change is in what it publishes. The runtime stays the same, while components, layout, responsive scaling and the backend work differently. Velo code and CSS selectors from Wix Studio don't carry over, and every Studio Two site gets the same fixed backend limits.

How we tested: we compared two published demos of the same Wix template, Umpa Umpa, one built in Wix Studio and one in Studio Two, on four pages and nine window widths (2 November 2026). Backend numbers come from Wix's developer documentation, and the code structure from our own export of a test site. Studio Two is in its first release, so details can change.

Wix Studio Two technical differences at a glance

Runtime: the same Wix renderer with React 18, but a different component library.
Layout: grid-first sections, fewer absolutely positioned elements, many wrappers removed from the layout.
Responsive: sizes scale smoothly as proportions of the container, with one main breakpoint at 1023 px instead of stepped sizes on four to six breakpoints.
Weight: about equal: more HTML, less CSS and far fewer font files.
Backend: 0.3 CPU cores, 400 MB of memory and 60 seconds per request for every site, with no auto-scaling.
Code: React components, Data Sources and HTTP endpoints instead of the $w API, web modules and HTTP functions.

Same engine, new components

Both demos run on the same Wix runtime, Thunderbolt, with React 18.3.1 and the same page renderer bundle. The site model even names the editor: editorName is Studio on one demo and StudioTwo on the other. What changes is the component library the editor publishes.

Area	Wix Studio	Studio Two
Component library	thunderbolt	thunderboltBuilder
Typical containers	Container_ResponsiveBox, MenuContainer_Responsive	ResponsiveContainer, BackgroundGroup, PinnedLayer
Container wrappers (data-testid)	responsive-container-content	internal-container-root, background-layer, content
Header and footer	Standard containers	HeaderContainer_TransparentScreen, FooterContainer_TransparentScreen

For anyone who styled Wix Studio sites with custom CSS or targeted elements by class, this is the first practical difference: class names and test IDs are new, so old selectors match nothing.

A grid-first layout

On desktop the two homepages look almost the same: nine sections with the same content. Under the surface, Studio Two builds the page differently.

Homepage at 1440 px	Wix Studio	Studio Two
Page height	10,364 px	8,543 px
Elements with display: grid	94	110
Elements with display: flex	112	60
Elements with display: contents	1	57
Absolutely positioned elements	122	74
Font files loaded	13	4

Wix Studio Two vs Wix Studio: DOM structure of one section, with element counts for grid, flex, display contents and absolute positioning — Wix Studio Two keeps wrappers in the DOM but takes them out of the layout.

Studio Two removes service wrappers from the layout with display: contents: they stay in the DOM but don't create a box of their own. That's why it needs half as many flex containers for the same design. In the exported code the hierarchy is strict: page, section (always a grid), container, then a grid or a stack. Stacks have no gap property, so spacing comes from margins, and grids accept a limited set of track definitions.

Both templates share one SEO issue worth fixing on any project: the H1 is a small label above the hero, and in Studio Two several large section titles are paragraphs styled as headings.

How responsive design behaves now

This is the change designers will feel most. Wix Studio switches sizes in steps at its breakpoints: in our template the hero heading was 45 px on desktop, 35 on tablet and 25 on mobile, with four to six breakpoints per page. Studio Two scales sizes smoothly and needs one to three, with the main one at 1023 px.

Wix Studio Two vs Wix Studio responsive design: steps at breakpoints versus proportional scaling with a plateau between 768 and 1023 px — Wix Studio switches sizes at breakpoints; Wix Studio Two scales them with the container.

Sizes are proportions, not pixels

Studio Two stores sizes as scaled pixels (SPX). You design in pixels on a 1280 px canvas, and the published site keeps each value as a share of the container width: a 215 px wordmark becomes about 16.8 percent of it. The scale follows the container, not the window, so a component behaves the same in a full-width section and in a narrow column. Mobile has its own reference width of 390 px. Minimum and maximum sizes set in the editor become clamp() values: the CSS of the Studio Two homepage had 46 of them against 5 in Wix Studio, and 5 vw units against 176.

Two ranges to test

Wide screens. Without an upper limit, scaled sizes keep growing. The wordmark was 322 px wide at a 1920 px window and would reach about 430 px at 2560. Set a maximum section width or a scaling limit before handover.
768 to 1023 px. In our template sizes froze in this range while the layout switched to one column, and the page grew from about 6,500 to 12,500 px. Check both edges and the middle.

Wix's feature list adds tools for this: breakpoints set for the whole site, font size per breakpoint and limits on scaling for large phones. If you write your own CSS, keep it inside the system. A fixed font size in px takes an element out of proportional scaling, while a clamp() with a minimum, a scaled value and a maximum keeps it consistent with the rest of the page.

Page weight: a draw

Homepage at 1440 px	Wix Studio	Studio Two
DOM nodes	963	960
HTML	1,425 KB	1,771 KB
Inline CSS / style tags	1,005 KB / 40	932 KB / 28
External scripts	31	27
Network requests	132	199
Images / with native lazy loading	21 / 8	15 / 0

Neither generation wins clearly. Studio Two sends about a quarter more HTML, rendered on the server with inline styles, but less CSS and four font files instead of thirteen. Two of the three inner pages were 7 to 14 percent lighter in DOM. None of the Studio Two images used native lazy loading and the page made more requests, so run Lighthouse on your own template rather than trusting either number. Our timings were taken with a warm cache and serve only as a rough guide.

One detail for privacy policies: Studio Two loads its animation libraries, @wix/interact and the motion packages, from the public jsDelivr CDN rather than from Wix's own servers. The platform adds them, so a cookie banner can't switch them off. We now mention jsDelivr in our clients' privacy policies.

Backend: fixed limits for every site

Wix publishes one set of backend limits for all Studio Two sites, free or premium. In Wix Studio, Velo resources depend on the premium plan.

Limit	Studio Two	Velo in Wix Studio
CPU	0.3 cores per instance	1 vCPU (micro) or 2 vCPU (standard) containers
Memory	400 MB, more crashes the process	400 MB, up to 600 MB
Time per request	60 s, then a 504 error	14 s
Scaling	One instance per data center, no auto-scaling	More containers on higher plans
Instance lifetime	Restarts every 5 minutes	Not published

So Studio Two allows longer requests than Velo, but with a much smaller processor and no scaling. Next to serverless platforms the gap is wider: Vercel Functions start at 300 seconds and 2 GB of memory and scale on their own. Wix Headless follows a different model again, with a budget of 1 second of CPU time and up to 20 sub-requests per request, and scaling up to 1,000 requests per second per project. We put every platform side by side in Wix Studio Two vs Wix Studio.

What fits in Studio Two:

Form handling and writing to the CMS.
Calls to external APIs, including AI. Waiting for a response doesn't use CPU, and 60 seconds covers most text generation.
Reading and preparing Wix data for your components.
Service plugins in Wix flows, such as extra fees in the cart.

What should run somewhere else:

Processing images, PDFs or video: 0.3 cores and 400 MB run out fast.
Tasks longer than a minute, such as catalog imports or chains of AI calls.
Traffic peaks from sales or newsletters: there is no scaling.
Incoming webhooks and scheduled jobs: neither exists yet.
Anything kept in memory between requests: the instance restarts every five minutes.

Our pattern for heavier client projects: Studio Two serves pages, components and light endpoints, while an external serverless service takes webhooks, cron and heavy work and writes results back to Wix through the REST API.

Working without Velo

Velo code doesn't carry over to Studio Two. Here is how the pieces map, based on Wix's own comparison of the two editors:

Velo in Wix Studio	Studio Two
$w API and page code	Editor React Components with props connected in the editor
Datasets	CMS Data Sources, display only
wix-location, wix-window, wix-site	Site SDK packages from npm, such as @wix/site-service-router
Web modules	HTTP endpoints, called only by the site's own frontend
HTTP functions (incoming webhooks)	Not available; use an external service
Data hooks	Data events: run after save, own collections only
Routers	Dynamic pages
Scheduled jobs	Not available; use an external scheduler
Custom elements	Editor React Components
Velo packages	npm packages
Wix IDE, Local Editor, Git	Code tab with VS Code in the browser; export to React (beta)
Custom CSS	Not supported in the docs; listed in Wix's feature list

In practice a Velo page splits into three parts: a React component for the UI, a Data Source for shared state and an HTTP endpoint for anything that needs the backend. Some patterns have no home yet. On parnii.de, a router sends visitors from draft items of a CMS collection back to the section page. Studio Two has no routers or dynamic page hooks, so this logic has to move into a component or out of Wix.

Your site as code

Studio Two can export a site as a code project. In our export of a test site we found a Yarn monorepo with one folder per page: structure.jsx for the elements, layout.css and style.css, and an interactions file that plays animations through @wix/interact. The theme is a set of tokens for colors, heading and paragraph styles, button styles, boxes and lines. Instructions for coding agents ship with the export: AGENTS.md, CLAUDE.md and skills.

Two findings matter before you rely on it. The untouched export didn't pass Wix's own linter: one value was a floating-point rounding error instead of zero. And according to the skills that ship with the export tool, importing back replaces the theme, header, footer and menus and recreates every page except Home with new IDs, so links to page IDs and anchors break. Use the round trip on new sites, not on live client sites.

Before you move a project

List every Velo file and map it with the table above.
Rewrite custom CSS by element ID and theme variables, not by generated classes.
Test at 768, 1023, 1024, 1920 and 2560 px.
Fix heading levels in the template you start from.
Move webhooks, cron and heavy jobs to an external service.
Add jsDelivr to the privacy policy.

parnii note

We treat Studio Two as a new platform, not an upgrade: new design-led sites start there, and existing Velo projects stay in Wix Studio until there's a reason to rebuild. Measuring a template the way we did here takes a day, which is cheaper than finding the tablet plateau after launch.

FAQ

Does Studio Two use a different engine than Wix Studio?

No. Both run on the same Wix runtime with React 18. Studio Two publishes a different component library, a grid-first layout and proportional sizes, so its HTML and CSS look very different.

Can I reuse my Velo code in Studio Two?

Not directly. Page code, the $w API, web modules, routers, data hooks and scheduled jobs aren't in the first release. UI moves to React components, shared state to Data Sources and backend calls to HTTP endpoints.

Is a Studio Two site faster than a Wix Studio site?

Not clearly. In our test of the same template, Studio Two sent more HTML but less CSS and fewer fonts. Measure your own pages with Lighthouse before you decide.