TL;DR: A slow web page with 3,850 checkboxes was taking 38 seconds to load. By collaborating with Claude Code, I shifted from server-side rendering to a client-side approach, cutting load times to 1.5 seconds—a 25× performance boost. The key? Identifying that TagHelpers were the real bottleneck and letting AI guide the refactor with precision and speed.
Every developer has faced a page that just refuses to load fast enough. In my case, it wasn’t a complex algorithm or a massive database slowing things down—it was 3,850 innocent-looking checkboxes very similar to the one featured below. What started as a frustrating 38-second load time turned into a lesson on performance optimization and the power of collaborating with Claude.
Here’s how I worked with Claude Code to turn that sluggish page into a 1.5-second success story.
Identifying the Bottleneck of a 38-Second Load Time
The data would include a list of stores, with each one offering options to select a specific day of the week. The problem was that we had 550 stores, 7 days a week, so we were rendering 3850 checkboxes. The framework we were using for UI utilized TagHelpers to help render the controls and ensure that the styling was consistent across multiple applications in the ecosystem. This page was loading in about 38 seconds, which was way too long. After doing some testing on the load speed, I noticed that each tag helper was taking an average of about 5 milliseconds to load.
Mapping Out a Plan with Claude
I then took that information to Claude-Code and asked it to evaluate the page and provide options on how to fix the problem:
Prompt:
In the store scheduling feature, the first page generates checkboxes based on how many stores and days of the week there are. Right now there are 7 days, and about 550 stores. This takes the server about 40 seconds to render that page. Help me plan what strategies we could use to make the load time better.
After letting it think about the problem, Claude came back with a few options:
- Client-side Virtualization
- Server-side Pagination
- Lazy Loading with Search/Filter
- Database Query Optimization
- Client-side Rendering with JSON
- Caching Strategies
It included some information about each option, as well as the impact and effort to make the change. When looking at what option it provided, I realized I could have given it more information about what I had learned about the load time.
Prompt:
I can tell you from experimentation that the problem lies with rendering the page. Fetching the data does not take that long. Let’s focus on how to speed up the rendering.
Claude took that information and responded with the following:
Good insight! With 3,850+ DOM elements and Tag Helpers, rendering is definitely the bottleneck. Here are rendering-focused optimization strategies:
- Replace Tag Helpers with Raw HTML(BIGGEST WIN)
- Switch to Client-Side Rendering
- Implement Virtual Scrolling
Recommended Implementation Plan
Phase 1: Quick Wins (2-4 hours)
Replace with raw HTML checkboxes
Remove hidden inputs, use data-* attributes
Hoist conditional checks outside loops
Expected: 40s → 15-25s
Phase 2: Client-Side Rendering (1-2 days)
Return JSON from controller
Build a table with JavaScript + DocumentFragment
Update save logic to serialize from the DOM
Expected: 15-25s → 3-8s
Phase 3: Virtual Scrolling (2-3 days)
Implement virtual scrolling with clusterize.js or a custom solution
Expected: 3-8s → < 2s (instant perceived load)
I thought this sounded like a good plan, but I was not sure if all of the phases were really needed. I was mostly interested in investigating phase 2, and when I asked if Claude thought we could just do phase 2 without doing phase 1:
Yes, absolutely! Phase 2 (client-side rendering) makes Phase 1 unnecessary because you’re bypassing Razor rendering entirely.
I then told Claude, “Great! Let’s do phase 2!” and set it loose to make the changes needed to implement this change.
Over the next few hours, Claude and I worked to refactor the pages to use the client-side rendering. Like most things I have asked Claude-Code to help with, there were revisions along the way that needed to be prompted after the results. One problem was that the look and feel was off on the controls that we were generating now, so I gave Claude Code an example of what one of the controls looked like and asked Claude to make them match. After a few iterations, we had it working perfectly.
Lessons Learned: Optimizing the Right Problem
Watching a page take 38 seconds to load was frustrating. Now that it loads in 1.5 seconds, the difference is remarkable—especially since what Claude Code estimated as a 1-2 day project took less than 4 hours.
The biggest takeaway wasn’t just the 25x performance improvement. I realized how much the right context matters. When I shared that each TagHelper was taking 5 milliseconds to render, Claude Code immediately shifted from database optimizations to questioning whether we should be doing server-side rendering at all. That one data point changed everything.
This also reinforced that AI tools work best as collaborative partners. Claude Code suggested a three-phase plan, but I still needed to question whether Phase 1 was necessary. (It wasn’t.) The implementation needed some refinement along the way, but those iterative adjustments are part of any real development process.
For our users, this means a page that actually feels responsive. For our team, fewer complaints about the scheduling feature. And for me, it’s a reminder that sometimes the best solution isn’t optimizing what you have—it’s stepping back and asking whether you’re solving the right problem.
Takeaways for Developers
Turning a 38-second load into a 1.5-second success wasn’t just about faster checkboxes—it was about learning to collaborate effectively with AI. Claude Code didn’t just generate solutions; it helped me reframe the problem, prioritize the right optimizations, and execute changes far faster than expected.
As developers, we often focus on micro-optimizations, but sometimes the biggest win comes from rethinking how we build—and being open to tools that challenge our assumptions.
Have you tried using AI tools like Claude Code or ChatGPT for performance debugging or refactoring? I’d love to hear your experiences and what worked (or didn’t) for you in the comments. Check out the Keyhole Software blog for more content on AI for developers.
