# High TTFB (2.5s mobile) on Wix Studio site despite optimization – anyone solved this?

**URL:** <https://forum.wixstudio.com/t/high-ttfb-2-5s-mobile-on-wix-studio-site-despite-optimization-anyone-solved-this/79603>\
**Category:** Ask the community\
**Tags:** cms, wix-blocks, wix-studio, question\
**Created:** [September 3, 2026, 2:32pm UTC](https://forum.wixstudio.com/t/high-ttfb-2-5s-mobile-on-wix-studio-site-despite-optimization-anyone-solved-this/79603 "2026-09-03T14:32:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nico\_Dudli](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/nico_dudli/32/122133_2.png) [@Nico\_Dudli](https://forum.wixstudio.com/u/Nico_Dudli)\
**Post date:** [September 3, 2026, 2:32pm UTC](https://forum.wixstudio.com/t/high-ttfb-2-5s-mobile-on-wix-studio-site-despite-optimization-anyone-solved-this/79603/1 "2026-09-03T14:32:23Z")

</div>

**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.

> **[PageSpeed Insights](https://pagespeed.web.dev/analysis/https-www-technovice-net/rdfohahtj1?form_factor=desktop)**

**Working in**  
Live site (Basic plan)

**Site link**

> **[TechNovice | Technology, AI, Cybersecurity & eSIM Reviews](https://www.technovice.net/)**
>
> TechNovice is an independent technology publication covering AI, cybersecurity and eSIMs through real-world tests, practical analysis and expert insights.

**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.

---

<div class="post-metadata">

**Author:** ![Webhil](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/webhil/32/122559_2.png) [@Webhil](https://forum.wixstudio.com/u/Webhil)\
**Post date:** [September 21, 2026, 1:13am UTC](https://forum.wixstudio.com/t/high-ttfb-2-5s-mobile-on-wix-studio-site-despite-optimization-anyone-solved-this/79603/2 "2026-09-21T01:13:32Z")

</div>

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.