At 432,406 pixels tall on a 1920x1080 screen, this page loads without crashing the browser. The original version took 5 seconds to the first content paint, another 20 seconds to render the first part of testimonials, then froze and became unresponsive. It contained 800 testimonials built with Elementor.
The task was to implement lazy loading on a WordPress page. The page held 800 client testimonials and had been built with Elementor. On most machines it was slow to load. On some machines it failed entirely; the browser ran out of memory trying to render everything at once. The constraint was three days and no JavaScript.
Luca and his team started with the standard approach: stripping scripts, disabling plugins, trying Elementor's native options. Each attempt broke something else. Elementor had scattered its styles and IDs across the DOM in ways that made removal impossible. Taking out one dependency broke three others. The page was slow because of the compounding weight of every decision the CMS and page builder had made automatically, with no single person responsible for the result.
After failed attempts at patching the existing build, the team decided to throw it out and hand-code the replacement.
This meant copying the fonts and styles, replicating each layout element by examining the rendered output and rebuilding it as clean HTML. Elementor assigns a different ID to every element, so nothing could be copy-pasted. Each component had to be matched manually to its visual equivalent.
To accelerate the process, a TypeScript parser script was written and run through GitHub Actions. It read the existing page's output, identified structural patterns, and converted them into plain HTML. Elementor's structure was inconsistent; the script handled the repeatable parts and left the irregular sections for manual work.
The WordPress team had split the content across six sub-pages. The first three were on staging without a theme applied and had to be rebuilt from scratch to match the live site's visual design. The next two used different testimonial layouts that required separate conversion logic in the parser. The last three were nearly empty shells that the script could fill in automatically.
The plan was to get page two right, then generate the rest from it. What was supposed to take three days took considerably longer. New testimonials arrived mid-build. Layout changes came in. The WordPress team pushed updates to staging pages that overwrote work already done. A custom tagging system had to be built to track which sections were stable and which had been superseded.
The finished page is a single continuous HTML document at 674 KB. No Elementor. No page builder. No JavaScript for the core layout. Every testimonial block is static markup, using standard browser lazy loading for images and iframes.
On a 1920x1080 screen the page measures 432,406 pixels tall.
It loads fast. The original took 25 seconds before freezing. This version loads in a few seconds and never crashes. The browser stays responsive throughout.
The lesson is not that WordPress is bad or that page builders are wrong. The lesson is that performance problems which come from accumulated automated decisions are rarely fixable by adding more automation. At some point, the only move is to understand exactly what is on the page, take responsibility for every element, and write it by hand.
The page is still live at go away bots.