The one number
29.8seconds
That’s how long your homepage takes to show its main content on a phone.
Not to finish loading — to show the headline and the picture. The first text arrives at 4.1 seconds. The page doesn’t respond properly to a tap until 38.
(should be under 2.5)
(should be under 1.8)
(should be under 5)
mobile
Here’s the part that actually matters, given what you told me: not wanting traffic makes this worse, not better.
A stranger off a search result who gives up after four seconds costs you nothing — you didn’t want them anyway. But that also means there’s no cold traffic absorbing the damage. Everyone who hits that 29.8-second wall is someone who has watched you for months and finally tapped the link in your bio. The entire cost lands on the warm audience, the only audience you asked for.
Don’t take that number from me — it is one click: open PageSpeed Insights on your own homepage, make sure the Mobile tab is selected, and look at the big number and “Largest Contentful Paint”. It’s Google’s own tool, it’s free, and there’s nothing to log into.
Or hand it to your own AI and let it argue with me →
I own the website https://brandvideo.pro/ — it's built on Squarespace. Someone has told me that on a phone my homepage takes about 29.8 seconds to show its main content, that it downloads roughly 80 MB in total, and that most of that is autoplaying background video. I don't want to take their word for it. Check it independently. Run Google PageSpeed Insights (https://pagespeed.web.dev/) against https://brandvideo.pro/ and report the MOBILE results: the performance score, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift, the total page size, and which individual files are the biggest. Then tell me straight whether their claim is exaggerated, roughly right, or actually understated. If you can't browse the web, say so clearly and instead give me the exact steps to run the test myself and what to look at.
Thirty seconds is longer than you think.
Left is brandvideo.pro. Right is one of the rebuilt pages, same photographs, measured on its live URL. Both clocks run in real time.
Now
brandvideo.pro
Rebuilt
brandvideopro-skyline.matewishkey.com
You already teach this. It’s the first three seconds.
In Script Lab you rewrite the first eight words, because that’s where the video is won or lost. On the Reels you tell people the hook has about three seconds before the thumb moves on. You’ve built a whole community on the idea that the opening is not a detail.
A web page has the same curve and it’s steeper, because there’s no motion carrying the viewer through it — they’re holding a blank rectangle, deciding. I’m not going to quote you an industry bounce-rate statistic; you’ve watched more real retention graphs than any of those studies. Just apply your own note to your own page.
If a member sent Christy a video that held on black for twenty-nine seconds before the first frame, the note would write itself.
That’s the whole argument. Not “rank better” — finish your own hook.
It’s one cause, and you’ll enjoy the joke.
Opening the homepage on a phone pulls 82.8 MB across 225 requests. Of that, 76.5 MB — 92% — is video. 73.2 MB is three autoplaying background clips arriving in 77 separate chunks from Squarespace’s video CDN, and another 4.5 MB is the VideoAsk widget loading before anyone clicks it.
The video guy’s website is being eaten alive by video. It isn’t carelessness, yours or Squarespace’s: autoplaying background footage is exactly what a template offers you the moment you have footage this good — and you do. It just costs thirty seconds on a phone, and the phone is where all 120,000 of them are.
Prompt: which files, exactly →
For https://brandvideo.pro/ (my Squarespace site), I want to know exactly what is making the homepage heavy on a mobile phone. Give me: the total page weight, a breakdown by file type (video, images, scripts, fonts), and specifically which autoplaying background videos are on the homepage and roughly how many MB each one is. Also tell me whether any third-party widgets (for example VideoAsk) load on arrival rather than when someone clicks them. I'm not technical. If you need me to look at something myself, give me the exact clicks — which browser menu, which tab, which column — and tell me what a bad number looks like versus a normal one.
- Swap the background videos for a still frame from the same clip. Squarespace will use a poster image in the same slot. The look survives — it’s the same frame, just not moving. ≈73 MB → a few hundred KB. A settings change, not a rebuild.
- If you want motion, keep exactly one. Below the fold, muted, under three seconds, under 2 MB, with a poster frame showing first so nothing is blank while it arrives. Keeps the feel, pays for it once instead of three times.
- Load the VideoAsk widget when someone clicks it. Right now it downloads for every visitor on arrival, whether or not they ever open it. 4.5 MB and 24 requests off the first load.
Prompt: walk me through it in Squarespace →
I'm on Squarespace 7.1. My homepage uses autoplaying background video behind several sections, and I've been told that's roughly 73 MB of the page and the reason it takes about 30 seconds to appear on a phone. I want to replace those background videos with a still image — ideally a frame taken from the same clip, so the page still looks like it does now. Walk me through it inside the current Squarespace editor, one step at a time, and wait for me to confirm each step before you give me the next. Cover: 1. how to find which sections are using background video, 2. how to switch a section's background from video to image, 3. how to get a still frame out of my own video clip to use as that image, 4. what size and file format to upload so it stays sharp without being heavy, 5. how to check afterwards that I haven't broken the layout on mobile. If I want to keep exactly ONE short background video somewhere on the page, tell me how to make it cheap — under about 2 MB, a few seconds, muted, with a poster image showing first — and what of that is possible in Squarespace's own settings versus needing a code block. Important: if any menu or setting has moved and you're not certain what it's called now, say so rather than guessing, and describe what I should be looking for instead.
Your hosting is fine, by the way — the server answers in 220 ms, which is good. Nothing here is a platform problem or a “you need a developer” problem. It’s payload.
For scale: the page in the right-hand phone serves 11 requests and 361 KiB and scores 98 out of 100 on the same test. Same photographs. Roughly 220 times lighter.
Prompt: did it actually work? →
I've made changes to https://brandvideo.pro/ to reduce how much video loads on the homepage. Re-run Google PageSpeed Insights on MOBILE and compare the result against these measurements from before the change: Performance score 8 out of 100 Largest Contentful Paint 29.8 s Total Blocking Time 5,200 ms Cumulative Layout Shift 0.419 Page weight 82.8 MB across 225 requests Show it as a before-and-after table, tell me plainly whether it worked, and list anything still worth fixing in order of how much difference it would make. Don't be encouraging for the sake of it — if it barely moved, say so.
Three more things, none of them about Google.
These came out of crawling all 31 pages. I’ve left out everything that only matters to search engines, because you’ve told me it doesn’t matter to you — and you’re right.
images across the site have no alt text. That’s your members using screen readers, and anyone whose images don’t load on a train.
layout shift on mobile — the page moves while it loads. On a phone that means people tap the wrong thing. On desktop it’s a clean zero, so it’s a phone issue only.
/, /join-now and /join-soon are near-identical copies
of the same 1,250-word page. Three places to update the day the room is full —
and two of them are the links people paste into DMs.
That last one is your own point, really. You don’t want anyone hitting a dead end. Right now there are three doors into the same full room and nothing keeping them in sync.
The site is the one piece of your work a member can take apart.
120,000 people follow you to learn how to make something properly. Almost none of them will ever see your timeline, your lighting or your edit. The website is the one piece of your output they can open, inspect and — this is the part — copy. Some of them are building their own right now, off the back of your episodes.
So the argument isn’t “be findable”. It’s that this is the one asset that went out without the note on it. And unlike most notes, this one is an afternoon’s work.
If you wanted it, there’s an episode in here. You’ve made the website ones already. “My own site was failing the three-second rule” — with a stopwatch on screen and the before-and-after — is a better hook than anything I could write for you, and the measurements are already done. Take them.
I’m not selling you anything.
No invoice attached, no proposal, no rebuild pitch. I built the five designs because I wanted to find out whether it could be done with your own photographs and your own words — that was as much for me as for you.
So take the numbers and do whatever you like with them. That is what the four prompts folded into this page are for — paste them into whatever AI you already use and it will check my arithmetic, find the heavy files and walk you through the change in Squarespace without me in the room. Someone inside your own community would do it for free and be pleased to be asked, too. The full audit — all 31 pages, every measurement, including the ones I’ve deliberately left out of this page — is here: the audit in full.
And if you want the site to stay unfindable, none of this is in tension with that. Fast and
invisible aren’t opposites. Two lines in robots.txt and a noindex tag keep
you out of Google entirely, and your own people still open the page in two seconds instead of
thirty. This page you’re reading has exactly that tag on it — it isn’t indexed, and it never will be.
Either way: thanks for replying, and a community that’s full is a good problem to have.
— MateMateWishKey