A Shift From Fixes to Culture
In August 2020, only 4% of Wix websites were achieving good Google Core Web Vitals (CWV) scores. That number was despite earlier technical work, including the introduction of Server-Side Rendering (SSR). The realization that months of targeted fixes had yielded such poor results forced a fundamental rethink: performance could no longer be a project for a dedicated team of specialists. It had to become an organizational priority.
Over the following period, that change in mindset translated into infrastructure updates, a rewrite of core functionality, and a gradual rollout designed to avoid disrupting existing sites. The results have been substantial. The worldwide ratio of Wix websites with green CWV scores has climbed from 4% to over 33%—an increase of 737%. The trend is expected to continue as more improvements are deployed. Data from the Core Web Vitals Technology Report, sourced from the Chrome User Experience Report (CrUX) and HTTP Archive, illustrates the shift:
The business value of this progress is clear. Sites with good CWV performance qualify for the maximum performance ranking boost in Google search results, and they tend to see higher conversion rates and lower bounce rates from an improved visitor experience.
Why Scale Makes Optimization Hard
Wix operates at a scale that makes conventional performance optimization strategies insufficient. The platform houses over 210 million users across 190 countries and serves more than five million domains. Beyond content sites, it supports e-commerce, blogs, forums, bookings, events, membership systems, and an app store with themes for specific verticals like restaurants, fitness, and hotels.
With such diversity, there is no known layout or feature set to optimize for. Websites on the platform have almost total design freedom, so improvements must work across an enormous range of configurations and functionality. The positive side of this scale is that an optimization which succeeds benefits millions of sites at once.
Beyond sheer size, several constraints shaped the approach:
- Preserving existing sites. A core requirement was improving performance for all websites already built on Wix without changing their look, feel, or behavior. Sites needed to work exactly as before, but load faster.
- Keeping development velocity. Performance work could not slow down feature releases. The goal was to build in a level of automation that would prevent performance regressions without requiring constant manual effort.
- Educating the organization. Making performance a company-wide competency required training engineers, partners, and even customers efficiently. This took deliberate planning and repeated iteration.
Why the Organization Had to Change
The old model was simple: a small performance team identified bottlenecks and fixed them, bringing in others only when needed. Progress was made, but implementing significant improvements was a constant struggle. The workload exceeded the capacity of that team, and ongoing feature work often interfered with optimization efforts. There was also a lack of data and insight into where the real bottlenecks were, making it difficult to focus work where it would have the most impact.
Around two years ago, it became evident this approach was untenable. Several factors, some external and some within Wix’s own market, pushed performance to the top of the corporate agenda:
- Mobile-first traffic. Six years ago, over 70% of sessions on Wix websites came from desktop, with under 30% from mobile. Today those numbers have flipped. Mobile devices, despite improvements, remain underpowered compared to desktops—particularly in regions with poor connectivity—so the quality of the visitor experience was declining over time.
- Higher customer expectations. Website owners now understand that loading speed directly affects their success. They prefer platforms that deliver good performance and will leave those that don’t.
- Google’s ranking shift. Starting in 2021, Google began giving a ranking boost to fast mobile sites rather than just penalizing slow ones. This raised the stakes for site owners and SEOs in their choice of platform.
- Heavier websites. As demand for speed grows, so does demand for richer experiences: videos, animations, and customization. Since websites are getting heavier and more complex, holding the performance line gets harder.
- Better tooling and standard metrics. Performance measurement used to be specialized work. Tools like Google Lighthouse and PageSpeed Insights have made it far more accessible, and Google’s Core Web Vitals (CWV) have become an industry standard, with monitoring integrated into services such as the Google Search Console.
All of this drove a change at the highest level. At an all-hands company update, the CEO announced that good performance for websites built on the platform was a strategic priority for Wix as a whole, and that units across the company would be measured on their ability to meet that goal.
That announcement marked the transformation of the performance team. They moved from executing specific speed enhancements to interfacing with every level of the organization, helping other teams pursue performance on their own. The first job was education: what website performance means and how to measure it. After that came organized design and code reviews, training programs, and internal tools designed to support these efforts. The team leaned on the accumulated experience from past performance work and tapped into the wider performance community through conferences, outside experts, and study of modern architectures such as the Jamstack.
Choosing What to Measure
Website performance only improves when work is directed by the right measurements. For years, the industry lacked a shared standard, making it hard to compare results across different testing tools. This changed when Google introduced Core Web Vitals (CWV), a set of three primary metrics targeting visibility, responsiveness, and visual stability:
- LCP — Largest Contentful Paint
- FID — First Input Delay
- CLS — Cumulative Layout Shift
Wix analyzes field data using CWV, while relying on lab measurements during development. Lab tests are critical for enforcing performance budgets and preventing regressions. Ideally, budget checks are baked into the CI/CD pipeline so a performance failure blocks the deployment itself. Wix built its own budgeting service, Perfer, because of its enormous scale: hundreds of components are combined into thousands of configurations across millions of live sites. Testing every combination demands a dedicated cluster, called WatchTower, which currently executes up to 1,000 Lighthouse tests per minute.
Field Data Collection
Lab testing cannot cover all possible configurations and scenarios. Production data is collected anonymously from every Wix session via custom instrumentation. Besides CWV, this code reports TTFB, FCP, TBT, and TTI, along with lower-level details like DNS lookup and SSL handshake times. These richer measurements make it possible to trace a performance issue back to its root cause, whether that is an internal software or infrastructure change, or a problem with a third-party service such as a CDN.
Having field data aligned with Google’s CrUX collection methodology is important, since CrUX is the input for Google’s performance-based search ranking signal. Should a deployment degrade performance without being flagged by lab tests, immediate rollback is possible thanks to RUM visibility.
Infrastructure and Architecture Changes
Seven years ago, Wix operated a single data center in the USA that served users globally. Today, multiple centers span the globe, alongside CDNs from several providers, ensuring rapid and reliable delivery to users in 190 countries. The broader infrastructure allowed for a complete rewrite of front-end code and a deliberate shift: moving as much computation as possible from browsers to fast servers.
This shift almost always improves performance because it reduces the JavaScript either under execution or awaiting download. Lower JavaScript size correlates directly with better metrics:
A related benefit of server-side execution is cacheability. On a first visit, the landing page HTML is generated by Server-Side Rendering (SSR) and propagated to a CDN. Subsequent visits — even by unrelated users — can be served directly from CDN cache without touching the origin servers. That essentially replicates the on-demand mechanism of advanced Jamstack services: HTML is generated at the first request and distributed at runtime rather than at build time.
Client-side code still makes pages dynamic by calling backend APIs. Certain API results are cached in the CDN too. For instance, a shopping cart icon’s HTML is generated on the server, but the item count is determined and rendered client-side, letting the page HTML be cached while every visitor sees their own count. When the site owner publishes an update, the cached HTML is purged immediately.
Keeping the Main Thread Responsive
To prevent client-side business logic from blocking rendering, Wix moved that logic into Web Workers. The main thread is dedicated primarily to rendering, while Web Workers take over tasks like handling vertical-solution logic (e-commerce, bookings) and communicating with backend services: sending requests, parsing responses, and managing the resulting state. Off the main thread, this code no longer blocks event handling, improving FID in the field and TBT in lab tests.
Image Delivery at Scale
The weight of web pages is growing largely because of media. Google CrUX data shows that median image bytes have increased more than eightfold over the past decade, outpacing median network speed gains. According to Wix RUM data, the LCP element is an image in almost 75% of sessions. Fast delivery of first-viewport images is essential, but so is image quality: any change that visibly degrades visuals contradicts good user experience objectives.
For instant delivery, images are served via CDN and cached by browsers with long HTTP caching headers, dramatically reducing repeat-visit load times. Optimization comes through several complementary techniques:
- Modern formats. Uploaded images are automatically converted to WebP for browsers that support it. WebP files generally come out 25-35% smaller than PNG or JPG equivalents.
- Smart resizing. Manipulations like cropping and resizing happen server-side before download. Taking viewport size, screen resolution, and pixel depth into account ensures only the required pixels travel over the network. AI and ML models run on those servers to generate the highest-quality resized results.
- Lazy loading. Resources outside the initial viewport are not fetched until they scroll into view; if they never appear on screen, the download never happens. This reduces network contention for above-the-fold essentials such as the LCP image, and is applied automatically to images and other resource types.
What’s Next for Wix Performance
Performance work at Wix has shifted from one-off fixes to a sustained platform effort. Over two years, the cumulative result is a sharp increase in the share of sites achieving good scores across all three Core Web Vitals compared with a year prior. The company views speed as an ongoing process, not a finished project, and is evaluating new browser capabilities alongside internal infrastructure changes. Performance budgets and continuous monitoring are now in place to ensure future optimizations deliver measurable gains rather than regressions.
Promising Browser Features on the Radar
AVIF. Wix is actively investigating AVIF as a next-generation image format. For photographic content using lossy compression, AVIF can substantially reduce download sizes compared with WebP while preserving perceived quality. The format also supports progressive rendering, which can improve perceived performance on slower connections, though it does not directly influence CWV metrics.
CSS content-visibility. The content-visibility:auto property lets the browser defer rendering work for off-screen elements, skipping styling and layout for their subtrees until needed. This is particularly relevant for Wix pages, which tend to be long and content-dense, and for EditorX sites that rely on expensive grid and flexbox layouts. Two practical obstacles remain: the property is only supported in Chromium-based browsers, and implementing it without affecting visual appearance or behavior on any Wix site is non-trivial.
Priority Hints. Priority Hints, currently in Chrome Origin Trial, aim to give developers finer control over resource download order. Assigning higher priority to a foreground image over a background image, for example, could help ensure significant content loads first. The caveat is that incorrect usage can degrade download speed and, by extension, CWV scores — making careful implementation essential.
Better Tooling for Site Creators
Because Wix supports deep customization, users can build both fast and slow sites depending on their design choices. The platform’s goal is to surface the performance impact of those decisions during the building process, analogous to how the existing SEO Wiz tool guides users toward better search visibility. The intention is not to restrict flexibility but to inform it so users can make deliberate trade-offs.
The Net Effect
Embedding a performance culture across Wix allowed improvements to touch nearly every part of the stack, from media delivery to software architecture. Individual changes varied in impact, but the compounding effect is what delivers broad benefits. These results are measurable at scale and visible to end users through tools like WebPageTest and PageSpeed Insights, as well as feedback from their own site visitors — feedback that in turn reinforces Wix’s commitment to continued speed work.
Related Resources
- How to Optimize Your Wix Site for Core Web Vitals (Joint Google and Wix webinar)
- “How Wix improved website performance by evolving their infrastructure” by Alon Kochba
- “Front-End Performance Checklist 2021” by Vitaly Friedman
- Learn about Wix performance, Wix.com
- “My Website is Slow, Now What?” by Dan Shappir
