I’m what you’d call a “wannabe developer.” My main focus is SEO, but I like trying new things and getting my hands dirty when something breaks.
The project was simple enough: a WordPress site dedicated to the 90s classic PC games I keep recommending to people. Instead of hand-coding the theme, I described the layout I wanted, gave an AI the homepage content, and asked it to build a custom theme from scratch.
To be fair, it did a decent job. The site launched with a perfect 100/100 on Lighthouse for both mobile and desktop. Clean HTML, fast load, no obvious mess.
Then I made a few small content edits to the homepage, re-ran the test, and the mobile score dropped to 89. Desktop stayed at a clean 100.
This is not a deep performance war story. The fix was a single image attribute. But the reason that attribute ended up in the wrong place says a lot about why AI-generated code still needs a human code review.
The Symptom: Visual Priority vs. DOM Order
A flawless desktop score next to an 89 on mobile is classic throttling behavior. Fast desktop connections easily mask critical path bottlenecks that PageSpeed’s simulated 4G and mid-range mobile hardware immediately expose. The drop indicated an asset was needlessly competing for early bandwidth.
The mobile report pointed straight to an image in the Largest Contentful Paint (LCP) path: a screenshot from Disney’s Aladdin.
That was odd, because the image is not visible on the initial screen. The homepage opens with a massive data table of games spanning roughly 25 rows, you can see the live layout at bestclassicpcgames.com. On a mobile viewport, that table completely takes over the screen and pushes the actual game sections deep below the fold. The Aladdin screenshot is the first image in the source code, but visually, it is nowhere near the initial viewport.
The Bug: A Naive Heuristic
Checking the theme template revealed the issue:
<img src="..." alt="Aladdin video game" width="800" height="450" fetchpriority="high">
The code is valid, but the assumption is wrong. The AI relied on a naive heuristic: it assumed the first image tag in the HTML source code was the hero image.
In a standard blog layout, that logic usually holds up. But lacking spatial awareness of the massive HTML table altering the viewport hierarchy, the AI forced mobile browsers to waste limited early bandwidth downloading a hidden asset.
The fix was immediate:
<img src="..." alt="Aladdin video game" width="800" height="450" loading="lazy">
Chasing the Cache Ghost
The code update was correct, but the first retest still returned an 89 and showed fetchpriority="high" in the rendered source.
I spent twenty minutes looking for a phantom optimization layer, a WordPress filter, or a plugin conflict before realizing I was just being gaslit by a server-side cache. The template was already fixed, but the caching layer was cheerfully serving the pre-edit HTML.
Once I purged the cache properly, the issue disappeared. Mobile snapped back to a stable 100 with a 1.0s LCP. It was a useful reminder: before chasing a performance regression, make sure the testing tool is actually seeing the code you changed.
The Takeaway for Auditing AI Themes
The AI didn't "fail" here; it made a reasonable guess based purely on source order. But because AI lacks visual and contextual awareness of the rendered page, it can write technically flawless code that completely reverses your asset delivery strategy.
If you are using LLMs to scaffold themes or components, add a quick global grep to your review pipeline:
-
Audit
fetchpriorityandloading="lazy": Verify them against the actual viewport hierarchy rather than DOM order. Look out for images buried under heavy layout elements, data tables, or hero sliders. - Isolate the Testing Environment: Save yourself the debugging panic, always purge your server caching layers and test cleanly to avoid auditing stale code.
AI-generated code is clean enough to ship, but it still requires a human to verify whether its structural assumptions match reality.
Top comments (0)