I’m having trouble with
High Time to First Byte (TTFB) on my Wix Studio site. PageSpeed Insights shows 2.5s TTFB on mobile (“poor” range, threshold is 1.8s), and LCP is affected too (2.8s). INP and CLS are both fine, so it’s specifically a server response time issue.
Working in
Live site (Basic plan)
Site link
What I’m trying to do
Bring TTFB consistently under 1.8s. My main concern is crawl budget, I get a lot of AI/search bot traffic and slow server response can throttle crawl rate.
What I’ve tried so far
Compressed all images heavily (Squoosh)
Removed almost all third-party apps/widgets
Checked my 301 redirects (recent URL restructure), all clean single-hop, no chains
Read a thread here confirming Elite plan mainly improves CMS/database performance, not general page load, so not convinced a plan upgrade alone fixes this
Extra context
One page’s HTML response is around 2MB, which seems unusually large and might be a factor. Curious if dynamic/CMS-driven pages vs. static pages make a measurable TTFB difference, or if there’s anything else within Wix’s control that actually moves the needle.
2MB HTML on a single page is the problem. TTFB won’t drop until you fix that.
A normal Wix page serves 150–400KB of HTML. You’re at 2,000KB. That’s not “content” — it’s embedded state, inline scripts, or datasets serialized into the DOM at page load. The server has to build that 2MB document before it sends byte one, which is why your TTFB is pathological.
Check these:
Repeaters bound to large collections without pagination — every row goes into the initial HTML
Lightboxes that load at page-init instead of on-demand
Custom code dumping API responses into hidden elements or data attributes
Inline JSON blobs (datasets pushed into window.__INITIAL_STATE__ or similar)
Third-party scripts with embedded config that scales with your catalog size
Find what’s putting 1.6MB of extra markup in the page. Chrome DevTools → Network → click the document request → Preview tab shows the raw HTML. Search for repeated patterns, large inline <script> blocks, or data-* attributes with serialized objects.
The images and redirects you’ve already fixed don’t touch TTFB — that’s server assembly time. This is a content problem, not a caching problem. Most likely: a repeater or dynamic section loading an entire collection (products, blog posts, bookings) at once instead of lazy-loading or paginating.
If the 2MB is in Wix’s own boilerplate and you can’t identify a source, that’s a platform-level issue — escalate to support with the URL and the 2MB figure. But check your own repeaters first.