From AI Prototype to Production: What We Learned Launching the SPEQ Landing Page
How we reduced page weight by 95% and improved load times by 90%
Subscribe to Our Build LogHow we reduced page weight by 95% and improved load times by 90%
Subscribe to Our Build LogAI tools can generate a stunning website in hours. But getting it production-ready? That's where the real engineering begins.
We just launched the landing page for SPEQ. The initial result created using Loveable.dev was visually impressive—live on Cloudflare's CDN within hours. Upon deeper inspection, our Lighthouse audit told a different story: 18-second load times (LCP) on mobile, failing performance metrics, and completely unreadable to SEO crawlers.
These performance problems can have a real-world impact on an online tool or buisness:
Here's how we transformed it into a high-performance, SEO-optimized site with a 95% reduction in page-weight (3.17MB to 176kB) and 90% LCP acceleration (18s to 1.8s).
Google Chrome dev tools has a lighthouse integration that tests any site for performance, security, best-practices and SEO optimization. We ran lighthouse analyses in both Desktop and Mobile emulation modes and followed their recommendations. This article will focus on mobile test results.
The webpage was served as a blank HTML document, and the actual content was injected by React once the JavaScript was downloaded, parsed and evaluated. This is how many sites work, and I honestly didn't notice any poor performance with my own eyes. However, downloading and parsing our JavaScript bundle (which contains the entire ReactJS lib) can take quite a few milliseconds during which time the page is completely blank. To make matters worse, SEO crawlers do not evaluate JavaScript, so they will never see the content that we spent hours crafting.
The hero image that Loveable generated for the site is beautiful, but Loveable chose to leave the image in a very bulky (and slow) format: a 3MB PNG file. Mobile devices would also receive this massive file even though their screens are much smaller.
Because the hero image was so large, it would load well after the rest of the site was rendered. When that happened, the content below the image would get shifted downward. This resulted in a Cumulative Layout Shift (CLS) of 0.36 which is considered poor.
Loveable chose three beautiful fonts for the site. Unfortunately these fonts are not standard system fonts, and they all needed to be downloaded before the site could be rendered. One of the fonts was used only for the SPEQ logo at the top of the page. Another was used for the easter egg that is hidden within the hero image.
Sendpulse's heavy-weight forms that do not require dual validation of email addresses are incredibly bulky: They download their own CSS and javascript bundles including jQuery (who still uses jQuery?). This added more network and computation pressure to our lightweight site.
This is more of a CDN setup issue. Images and assets were not set for CDN or browser caching, so every load of the page would be just as slow as the first load.
Compression: Our AI-generated hero image was a beautiful 3MB PNG. We compressed it to 133KB using Squoosh.app (MozJPEG, 75% quality) with zero visible loss. Similarly, we compressed the background PNG from 100KB to 5KB using the AVIF format. Result: 13.8s (77%) faster LCP.
Responsive Images: Claude Code created a scaled down image (800px wide, 41KB) and used srcset to serve device-appropriate assets. This proved a little tricky due to the pixel density on modern devices: although an iPhone 16 viewport is 393 pixels wide, it has a pixel density of 3, which brings its effective width to 1179. As a result, the srcset parameter used in our image tags was still loading the larger image on modern mobile devices. To get around this, we trick the browser into thinking that the image will only occupy half of the viewport on mobile devices with size="...50vw". This gave us another full second of LCP improvement.
Reserving space for the hero image ensures that the content below is not shifted when it loads. By setting width="1536" height="1024" in the img tag, and specifying width=full; height=auto, the browser automatically calculates the height needed to be reserved for the image for the device's viewport size.
Client-side rendering means search engines see an empty page. We integrated Puppeteer into our build process to render the site in a headless browser. From there, we grab the fully rendered HTML and write it to our index.html file in /dist — better SEO and faster first paint (FCP was one full second faster: almost 50% improvement).
We asked Claude Code to pick the closest fonts that were available in standard system fonts. We also converted the SPEQ logo to a SVG so that we maintain the exact look without needing to download the entire font file. This saved 700ms on LCP.
Claude Code and Cloudflare made it simple to replace SendPulse's heavy JavaScript form with a custom implementation that calls SendPulse's API directly. To keep our API keys secure, we built a Cloudflare Worker as a secure API proxy. We will publish a separate article about this, because it is a good case study about the merits of Spec Driven Development (SDD). This removed lighthouse warnings about best practices and improved LCP by 700ms.
We can cache our assets for a full year to ensure repeat visitors get a snappy experience. This is thanks to Vite's asset hashing, which ensures that our images, css and js files will get a new unique identifier if they change at all. We setup the new caching policies by adding a _headers configuration file in our public directory. Cloudflare reads this and sets response headers based on its values.
We replayed our git history and deployed each milestone to a temporary site on Cloudflare to capture how much each change improved performance.
| Improvement | Lighthouse Score | Mobile LCP |
|---|---|---|
| Baseline | 60% | 18.0s |
| Image Compression (MozJPG) | 72% (+12%) | 4.2s (-13.8s) |
| Pre-rendering | 84% (+12%) | 4.3s (FCP -1s) |
| Remove custom fonts | 90% (+6%) | 3.5s (-0.7s) |
| Responsive Images + preload headers | 95% (+5%) | 2.5s (-1s) |
| Lightweight form | 99% (+4%) | 1.8s (-0.7s) |
| Metric | Non-Optimized | Optimized | Improvement |
|---|---|---|---|
| Total Transfer Size | 3.17 MB | 172.70 KB | 3.00 MB (94.7%) |
| Total Requests | 16 | 6 | 10 (62.5%) |
| CSS | 37.03 KB | 11.43 KB | 25.60 KB (69.1%) |
| Fonts | 41.19 KB | 0.00 B | 41.19 KB (100.0%) |
| Images | 2.94 MB | 52.16 KB | 2.89 MB (98.3%) |
| JavaScript | 150.52 KB | 101.91 KB | 48.61 KB (32.3%) |
AI tools excel at rapid prototyping, but production-readiness still requires engineering fundamentals. Performance, SEO, and security still need human expertise (for now). That said, AI was incredibly useful in finding and implementing solutions to the problems once the trained eye of an expert found them.
The engineer's role is evolving: from writing every line to orchestrating, optimizing, and ensuring quality. AI accelerates development, but we're still responsible for making our sites fast, secure, and robust.
Spec-Driven-Development (SDD) also has a large role to play here. By specifying non-functional requirements like performance, responsiveness and SEO-friendliness, AI agents can build software that is production-ready on the first try. SPEQ will incorporate this by providing safe defaults and suggesting non-functional requirements to creators. Further, companies can include their unique standards as part of their SPEQ, thus ensuring that they are met on the first iteration.
Want to dive deeper into the technical details? Drop a comment or DM us. Also, be sure to subscribe to our newsletter for weekly learnings like this as we build out SPEQ: a collaborative SDD tool for everyone.
Subscribe to Our Build LogBe the first to experience the future of product development