At 432,406 pixels tall on a 1920×1080 screen, this is the longest functional web page ever assembled by hand. It was not built to break a record. It was built because the alternative — a WordPress page with hundreds of testimonials, running Elementor, loading everything at once — was making the browser crash.
The task was simple in description: make a WordPress page faster. The page held a large number of client testimonials — not a few dozen, a lot — and it had been built with Elementor. On most machines it was slow to load. On some it did not load at all. The browser ran out of memory trying to render everything simultaneously.
The brief was: implement lazy loading. No JavaScript tricks. Three days.
Luca and his team started down the obvious path — stripping scripts, disabling plugins, leaning on Elementor's native options. Each attempt made something else break. Elementor had scattered its own styles and IDs across the DOM in ways that made surgical removal impossible. Taking out one dependency broke three others. The page was not slow because of one problem. It was slow because of the compounding weight of every decision the CMS and page builder had made automatically, over time, without any single person being responsible for the result.
After enough failed attempts at patching the existing build, the decision was made to throw it out entirely and hand-code the replacement.
This meant: copy the fonts. Copy the styles. Replicate every layout element by examining the rendered output and writing equivalent HTML from scratch. Elementor assigns a different ID to every element it generates, so nothing could be copy-pasted directly — each component had to be matched manually to its visual equivalent and rebuilt cleanly.
To accelerate the process, a parser script was written to read the existing page's output, identify structural patterns, and convert as much as possible into plain HTML. Elementor's structure is not consistent enough for full automation — the script handled the repeatable parts and left the irregular ones for manual resolution.
The WordPress team had split the content across six sub-pages for their own editorial reasons. The first three were on a staging environment without a theme applied — they 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 with basic formatting that the script could fill in automatically.
The plan was: get page two right, and generate the rest from it. A clean template, a working script, four pages produced automatically.
What was supposed to take three days took considerably longer. New testimonials arrived mid-build. Last-minute layout changes came in. The WordPress team pushed updates to the staging pages that overwrote work already done. A custom tagging system had to be built just to track which sections were stable and which had been superseded by an upstream change.
The finished page is a single continuous HTML document. No Elementor. No page builder. No JavaScript for the core layout. Every testimonial block is static markup, loaded with standard browser lazy loading for images and iframes.
On a 1920×1080 screen the page measures 432,406 pixels tall.
It loads fast. The browser does not crash. The work it replaced — a plugin-driven CMS page that took a powerful machine to its knees — is gone.
The lesson is not that WordPress is bad or that page builders are always wrong. The lesson is that performance problems which originate from accumulated automated decisions are very rarely fixable by adding more automation on top. 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.