Debugging a Regressed Lighthouse Score: What Tencent EdgeOne Makers Taught Me About Edge-Level Image Optimization

A few weeks ago I was optimizing the Lighthouse performance score of a Laravel + Livewire + Tailwind + Vite landing page. The starting score was 66, and the target was anything above 90. Like most performance work, the biggest villain turned out to be images — specifically, how the hero image and its responsive variants were being served.

The Regression Nobody Wanted

To fix the image problem, we implemented a responsive-image pipeline: WebP variants generated at build time with the Sharp CLI, wired into a reusable Blade <x-responsive-img> component that output srcset and sizes attributes automatically. On paper, this should have pushed the score up.

Instead, the score dropped — from 66 to 41.

Three bugs were responsible:

1. Duplicate hero image fetching. The hero image was being requested twice — once by the component's fallback <img> tag, once by the srcset-driven browser selection — because the fallback source wasn't excluded from the responsive set.
2. Misconfigured sizes attributes. The sizes values didn't match the actual rendered width of the image at each breakpoint, so browsers kept picking oversized variants "just in case."
3. Oversized WebP variants. The Sharp CLI compression settings weren't tuned per breakpoint, so even the "small" WebP files were larger than they needed to be.

None of these were exotic bugs. They're the kind of thing that happens whenever responsive image logic is built and maintained by hand at build time: every new breakpoint, every new image, every layout tweak is another place a mismatch can creep in.

Where Tencent EdgeOne Makers Changes the Equation

While digging into how other teams handle this, I looked into Tencent EdgeOne Makers, the web and AI-agent development and deployment platform built on Tencent's edge network. What stood out wasn't the deployment workflow itself — it was the Edge Functions layer, which ships with built-in capabilities for:

• Adaptive image format conversion — serving WebP (or another modern format) automatically based on what the requesting browser supports.
• Adaptive image resize — generating the correctly sized variant per request, instead of pre-baking a fixed set of breakpoints at build time.

This is a genuinely different approach from what we did manually. Instead of a build-time pipeline that has to predict every size and format a browser might ask for — and that can silently drift out of sync with the actual layout — the edge network resolves format and dimensions per request, at the node closest to the user. The three bugs above are, structurally, the exact class of problem this removes: there's no local sizes math to get wrong and no separate fallback tag to accidentally duplicate, because the edge is answering "what size and format does this specific request need" directly.

Manual Pipeline vs. Edge-Level Optimization

With the Sharp CLI + Blade component setup we built, sizing decisions were made at build time against a fixed set of hardcoded breakpoints. Every layout change or new breakpoint meant another manual pass through the pipeline, which is exactly where the risk of drift came from. Format negotiation was manual too — one WebP set served to every browser regardless of what it actually supported. And the failure mode we hit was a direct consequence of that design: a duplicate fetch, a wrong sizes value, and oversized files, all because the "right" size and format had to be predicted in advance and hardcoded.

EdgeOne Makers' Edge Functions flip that around. Sizing is resolved at request time, at the edge, so there's no static breakpoint list to fall out of sync with the layout. Format negotiation is adaptive — the edge checks what the requesting browser supports and serves accordingly. And because there's no fixed variant set sitting in the codebase waiting to be misconfigured, that entire failure mode simply doesn't apply. There's also less infrastructure to maintain on our side: no Sharp CLI step, no custom Blade component logic, no build step dedicated to image variants — the edge network handles it.

This isn't a claim that hand-rolled pipelines are always wrong — there are cases where you want full control over exactly which variants exist. But for a project like ours, where the bug came from maintaining that control correctly across breakpoints, offloading the decision to the edge removes an entire category of bugs rather than just fixing the three we found.

Takeaways for Other Laravel/Livewire Developers

1. A performance regression is often not "the feature doesn't work" — it's "the feature works, but only for the cases you tested."
2. Responsive images are a request-time problem disguised as a build-time task. The closer the optimization happens to the actual request, the fewer assumptions it has to make.
3. Before building a custom image pipeline, it's worth checking whether your edge/CDN layer already solves the problem — Tencent EdgeOne Makers is a solid example of this being built in rather than bolted on.
4. Debugging performance regressions is easier when you can isolate variables — in our case, writing a reproducible test case for the duplicate-fetch and sizes issues before touching the fix made the root cause obvious.

Pushing the score from 66 to above 90 turned out to be less about writing more optimization code, and more about deciding where that optimization should live. For image-heavy Laravel/Livewire apps, that decision is worth revisiting with edge-level tools like EdgeOne Makers before reaching for another build-time dependency.