FrameWorks Studio
FrameWorks Studio · Speed Playbook

Why vibe-coded sites feel slow, and the fix.

Every point from the reel "Your vibecoded website is slow because you a…" (Josh Hoeg, Vibe Coding & AI). For each one: what it is, what it does, and what it means for Exclusive Hookah Lounge.

Everything here comes from the reel's on-screen checklist and title cards: "My website", "Claude", "Slow", "Mistakes". His audio couldn't be transcribed here, so the "what he means" lines are explanations written for this page, not his exact words.

20Points in his checklist
3Marked as mistakes (red X)
15Apply to Exclusive (5 need a backend)
~290 KBHTML on every page today
01

The 20 points, explained.

Grouped by where the slowness comes from. Green check = do it. Red X = the mistake to remove.

Fix on EHL applies and needs workPartly doneN/A needs a backend EHL doesn't have

A · What the browser downloads

01Compress images ✓

Fix on EHL
WhatServe images in modern formats (WebP/AVIF) at the size they're shown, not raw camera files.
WhyImages are usually most of a page's weight. Smaller files means less to download before the page looks done.
EHL: real photos are JPGs of 470–720 KB each. As WebP at display size they'd be ~120–200 KB.

02Add lazy loading ✓

Partly done
WhatOnly load images and videos when they're about to scroll into view.
WhyThe first screen loads fast because the browser isn't fetching the whole page at once.
EHL: 44 of 54 images on the home page are lazy. The home page has 20 videos, and they need strict play-when-visible rules.

03Minify JS and CSS ✓

Fix on EHL
WhatStrip spaces, comments and dead rules out of code files.
WhySmaller code downloads and parses faster, especially on phones.
EHL: about 200 KB of CSS is inlined, unminified, into every page, including many old rules the redesign overrode.

04Split code into chunks ✓

Fix on EHL
WhatGive each page only the code it needs instead of one giant bundle.
WhyThe Careers page shouldn't download the home page's Instagram rail and hookah slider code.
EHL: every subpage carries the full home-page CSS (Terms is 248 KB of HTML). Move shared CSS into one cached file and page CSS into small files.

05Defer non-critical scripts ✓

Fix on EHL
WhatLoad extras (smooth-scroll, maps, analytics) after the page is visible.
WhyScripts that block the page make the first paint late. Deferring them lets content show first.
EHL: the Lenis smooth-scroll library loads from jsDelivr on every page. It should be deferred, or dropped, because it's a common cause of scroll "jank".

06Unused dependencies ✗

Fix on EHL
WhatLibraries, fonts and files that ship but are never used. He marks this as a mistake.
WhyEvery unused file is wasted download and parse time.
EHL: old hero.mp4 and hero-mobile.mp4 (5.6 MB) still ship. Three font families with full weight ranges are loaded. Leftover CSS from earlier designs is still in every page.

B · How fast it's delivered

07Add CDN ✓

Partly done
WhatServe files from servers close to each visitor.
WhyShorter distance means faster responses everywhere.
EHL: Cloudflare Pages is already a CDN. But menu photos, some videos and fonts are hot-linked from Unsplash, Pexels and Google. Self-host the key ones so they get Cloudflare's speed too.

08Cache API responses ✓

Fix on EHL
WhatTell browsers how long they can reuse a file, so repeat visits don't re-download it.
WhyThe second page someone opens should be near-instant.
EHL: the _headers file only sets the favicon type. Add long cache headers for images, video, fonts and versioned JS/CSS.

09Compress API payloads ✓

Partly done
WhatGzip/Brotli compression on everything sent over the wire.
WhyText files shrink 70–80% in transit.
EHL: Cloudflare does this automatically. The real win here is shrinking the files themselves (points 1, 3 and 4).

10Server-side caching ✓

Partly done
WhatThe server keeps ready-made pages instead of rebuilding them per visit.
WhyPages come back in milliseconds.
EHL: pages are already pre-built static files at Cloudflare's edge, so this is effectively done.

11Load balancer ·

N/A
WhatSpread traffic across several servers.
WhyOne server doesn't choke during traffic spikes.
EHL: Cloudflare's network already handles this for a static site.

C · How smooth it feels

12Unnecessary re-renders ✗

Fix on EHL
WhatRedrawing parts of the page that didn't change. He marks this as a mistake.
WhyConstant redraws are what make scrolling stutter. This is the "glitchy" feeling.
EHL: scroll-linked effects (word reveals, parallax, sticky bars, 20 videos) all run while scrolling. Each one should only animate transform/opacity and only while on screen.

13Debounce input handlers ✓

Partly done
WhatWait a beat after typing or scrolling before running heavy code.
WhyThe page stays responsive instead of reacting to every keystroke or pixel.
EHL: menu search is debounced. Scroll and resize handlers should all go through one shared requestAnimationFrame loop.

14Loading skeletons 💀 ✓

Partly done
WhatGrey placeholder shapes while content loads.
WhyNothing jumps when content arrives, and waiting feels shorter.
EHL: menu photos and the OpenTable widget have skeletons. Every image box should reserve its size so the layout never shifts.

15Paginate large lists ✓

Partly done
WhatShow long lists a chunk at a time.
WhyFewer elements on screen means faster rendering and smoother scrolling.
EHL: the menu renders one tab at a time (Kitchen is 71 items). Rendering the next group only as you near it would make it lighter still.

16Lighthouse audit ✓

Fix on EHL
WhatGoogle's free speed test built into Chrome.
WhyIt scores the site and names the exact files slowing it down. Run it before and after every fix.
EHL: run on home, menu and reservations, mobile mode. Target 90+ performance and no layout shift.

D · The database (backend sites only)

17Index the database ✓

N/A
WhatAdd lookup indexes so the database finds rows instantly.
WhyTurns slow full-table scans into fast lookups.

18Cache expensive queries ✓

N/A
WhatStore the results of heavy queries for reuse.
WhyThe same heavy work isn't redone for every visitor.

19N+1 database queries ✗

N/A
WhatRunning one query per item in a list instead of one query for all. He marks this as a mistake.
Why100 items means 101 trips to the database.

20Database connection pooling ✓

N/A
WhatReuse open database connections.
WhyOpening a fresh connection per request is slow.
For later: 17–20 matter for sites with a backend (logins, live ordering, dashboards). EHL is static, so they don't apply today.
02

Exclusive, by the numbers.

What I measured on the current build.

200 KBCSS inlined into every single page, unminified
20Videos on the home page
470–720 KBSize of each real lounge photo (JPG)
5.6 MBUnused old hero videos still shipping
1Cache rule in _headers (favicon only)
3Font families, full weight ranges
4Scroll listeners on the home page
152Hot-linked menu photos from Unsplash
03

The fix order, biggest win first.

This is what the new skill will run on every FrameWorks site, starting with Exclusive.

Baseline Lighthouse audit

Score home, menu and reservations on mobile so every change is measured.

Point 16

Move CSS/JS out of the HTML

One shared, minified, cached site.css and site.js, plus a small file per page. Pages drop from ~290 KB to ~30 KB.

Points 3, 4

Cache headers

Long-term caching for images, video, fonts and versioned files. Repeat visits become instant.

Points 8, 10

Convert images to WebP at display size

Width and height on every image so nothing shifts. Lazy-load everything below the first screen.

Points 1, 2, 14

Video discipline

Posters, preload none, play only when visible, one playing at a time per section. Delete unused videos.

Points 2, 6

Kill scroll jank

One requestAnimationFrame loop for all scroll effects, transform/opacity only. Defer or remove Lenis.

Points 5, 12, 13

Trim fonts and dependencies

Only the weights in use, preload the two main fonts, remove dead CSS.

Point 6

Self-host key third-party files

Menu photos and critical media served from Cloudflare instead of other sites.

Point 7

Re-audit and compare

Lighthouse again, side-by-side with the baseline, then deploy.

Point 16