A few years ago, working with a client at WhitePrompt, I found myself inside one of the most performance-critical codebases I had ever touched. As part of the Frontend and Performance team, our responsibility went beyond build and maintain features, we owned the SEO metrics and Web Vitals numbers for a product receiving 11 million monthly visits, ranked among the top 1,000 most accessed domains in the world. It was there that I truly understood the impact a developer can have on CRO (Conversion Rate Optimization) through performance work.
The Usual Suspects
One of our ongoing challenges was improving LCP (Largest Contentful Paint). For those unfamiliar, LCP is one of the Core Web Vitals metrics that measures perceived load speed by tracking how long it takes for the largest visible content element on a page to render. In other words, it approximates the load time of the most important element a user sees. At the time, our rendering strategy was hybrid: part of the content was server-side rendered (SSR), and part was loaded on the client side (CSR). In the diagram below, you can see a rough sketch of the app’s main page, the content below the red stroke line was loaded client-side, while everything above it came fully rendered from the server.
Not the best element was being recognized as LCP
The team’s challenge was clear: LCP had started drifting between the yellow and red zones, and our goal was always to stay in the green. So, what could we do? We had several options on the table:
- Reduce the load time of the current primary LCP element by optimizing requests and their order
- Reduce the size of the main image to improve loading (lazy-load, prefetch, fetchpriority, modern formats, etc.)
- Remove potential render-blocking processes (e.g., @import in CSS)
- Improve TTFB (Time to First Byte) through better CDN caching strategies
All of these are valid and valuable, they can and should be applied. But given how far our metric was from where we needed it to be, the team had a gut feeling that none of them alone would close the gap. So we started testing all of them to improve our numbers.
After exhausting several scenarios and following every recommendation in the Web Vitals documentation on LCP, something caught my eye, not a technique, but an example. A classic walkthrough of the old Instagram loading screen, where the LCP element is identified before the full page finishes loading. The reason: during the loading process, the LCP candidate isn’t fixed. It shifts, gets replaced by larger elements, and only stabilizes once the page settles. What the documentation was quietly showing was: the LCP element is not a given, it’s a moving target, and if it’s a moving target, it can be aimed. That’s when an idea hit me.
Rethinking the Problem: What If We Chose Our LCP?
What if, instead of just trying to load our elements faster, we deliberately changed which element became the LCP? What if we intentionally steered what we wanted our LCP to be? Sure, it sounds obvious when you say it out loud, but stop for a moment and think: when was the last time you saw engineering and product team sit down and discuss how to structure a page so that the web vitals metrics lands exactly where they want it? In most projects, performance is treated as something you bolt on later: “we’ll apply the optimizations once the feature is done and the numbers will follow.” But that’s not always how it works, and in high-traffic, high-stakes environments, that assumption can cost you more than you’d expect: leaving money out on the table.
Running the Tests
I ran some tests. First, I tried shifting the LCP focus by improving the load performance of the main image and changing the focus. It worked, but the gain wasn’t significant enough.
Then I tried something different: I increased the font size and visual weight of the main page title (which, fortunately, used very well-optimized fonts loading techniques), while reducing the font size property of the title inside the CSR-loaded content block.
.ssr_main_title {
font-size: 72px; /* previously 56px */
}.csr_secondary_title {
font-size: 48px; /* previously 62px */
}73% Improvement. Two Lines of CSS.
After a few rounds of testing, the LCP element shifted to the page’s main title. The result: a 73% improvement in our LCP metric compared to previous values, and we were back in the green zone. Two lines of CSS achieved what none of the conventional optimization alternatives had managed to deliver.
The only remaining challenge was negotiating this with the rest of the team (and designers). Once they saw the numbers and understood the impact, they were on board, and we shipped the layout change to the product’s home page. A design layout decision suggested by a developer.
What I want you to take away from all of this: be intentional with your metrics.
With just two lines of css, huge impact was achieved
Intention Over Automation
With AI tooling and an abundance of performance resources available today, performance optimizations need to be part of the conversation from the very first wireframe and architectural decisions, not an afterthought. But here’s a quiet irony worth naming: the same AI-assisted workflow that makes us more productive can also flood us with techniques, checklists, and optimization patterns all at once, and that volume of “correct answers” can actually pull our focus away from simpler, more creative insights that don’t come from a checklist at all. They come from rethinking how the solution was conceived in the first place.
Plan ahead for what you want to achieve and how you’ll get there, but leave room for that kind of thinking too. In my case, after reading through the documentation and following every recommended optimization path, the solution came from the simplest example in the docs: one where the technique isn’t even explicitly named, just quietly implied. It was there all along just waiting to be used with intention.
Let’s Build With Purpose
At White Prompt, performance isn’t something we layer on at the end, it’s part of how we think from the first wireframe. If you’re looking for a team that sweats the details that actually move the needle, we’d love to hear about your project. Let’s talk.
