Case studies
The first four rescues, each with the numbers we captured — and an honest note wherever we did not.
Case study — strongweb.net
100/100 Mobile Performance Without a Page Builder
Rebuilt-site metrics — mobile Google PageSpeed Insights, August 28, 2026
The starting point
strongweb.net was several years old and built with WPBakery. Past redesigns had left builder records, old theme dependencies, and assets that still loaded because something had once needed them. This was not a clean demo built beside the real site. It was the live Strongweb site, rebuilt in place at the same address.
What we did
We replaced the public rendering layer with a standalone WordPress theme called strongweb. The live pages no longer depend on a page builder to render. Existing content was extracted from the builder records into a clean content layer instead of being discarded. We kept WPML for the Serbian and English versions, preserved external links, and added redirects where a URL had to change.
The important point is not that every old site needs the same treatment. Some sites can be cleaned without a rebuild. This one had accumulated enough structural debt that replacing the rendering system was the honest route.
The measured result
Before the reconstruction, the old WPBakery site scored 46/100 on mobile, with Largest Contentful Paint at 9.6 s and a Cumulative Layout Shift of 0.258. A fresh mobile Google PageSpeed Insights test on August 28, 2026 returned 100/100 Performance, 1.4 s Largest Contentful Paint, 0 ms Total Blocking Time, and 0.001 Cumulative Layout Shift on the rebuilt site. Run the mobile test yourself. Live scores can move with hosting, content, and third-party services, which is why the current test matters more than a screenshot selected for this page.
For your site: a slow, builder-heavy WordPress installation may be repairable, but when the foundations are the problem, a controlled rebuild can keep the content and remove the machinery holding it back.
Case study — Kooihaus
A Large Content Library Made Lighter Without Throwing It Away
The starting point
Kooihaus is a content-heavy WordPress magazine with a large existing library. Its mobile PageSpeed Insights baseline was 66/100. The problem was not the amount of published work by itself. The active WoodMart setup, Elementor-era content, duplicated asset behavior, and an inefficient homepage hero path were making the front end carry more than the reader needed.
What we did
We treated the library as an asset to preserve. Article content was converted away from Elementor into WordPress’s native editing path, while the live theme was cleaned and the homepage loading sequence was traced request by request. One specific fault made mobile browsers fetch three versions of the hero image. We aligned the preload and rendered image to one real mobile candidate and removed the duplicate automatic preload.
We also built and tested a separate standalone magazine theme on a sanitized staging clone. That theme has not replaced the live production theme, which remains woodmart-child. Calling Kooihaus a completed standalone-theme launch would be inaccurate; the production proof here is the verified speed work and the reduction of builder dependence without deleting the content library.
The measured result
Immediately before the final hero fix, mobile PSI was 74/100 and the three hero variants transferred about 424 KB. After the fix, three consecutive tests returned 82/100, with 4.0 s LCP, one hero request, and about 67 KB transferred for that image. Six later diagnostic runs again returned 82/100; they showed the optimized image loading early and the remaining delay occurring during rendering. Re-run the mobile test.
For your site: a large library does not have to be sacrificed to make WordPress faster, but every dependency and request has to earn its place.
Case study — a psychotherapy practice
Real-User Core Web Vitals Passed After an Existing-Site Rescue
Real-user field data — 28-day Chrome UX Report, checked August 29, 2026
The starting point
This was a rescue of the practice’s existing website, optimized during 2026. Before that work, the owner-reported mobile Performance baseline was 64-72, never higher.
That range is useful context, not a captured day-zero lab record. We did not formally save the starting test, so we do not turn the owner’s recollection into a more precise number. A number reconstructed afterwards would not become proof.
What we did
We optimized the website that was already serving the practice and measured changes against mobile performance instead of assuming that a familiar technique would help. One test made that rule especially clear: enabling an object cache lowered the site’s mobile PageSpeed score. We left it off.
That is what rescue work looks like in practice. The goal is not to install every optimization available. It is to keep the changes that improve this site and reject the ones that do not.
The measured result
The strongest result is the one measured from real visits. In the 28-day Chrome UX Report mobile field data checked on August 29, 2026, the site passed its Core Web Vitals assessment: 1.5 s LCP, 75 ms INP, and 0 CLS. This is what real visitors experienced, not a lab proxy.
The dated lab records show the trajectory. Method: Google PageSpeed Insights, mobile profile. One captured run on August 9, 2026 returned 90/100 Performance. On August 29, 2026, repeated mobile runs produced 98/100 and 100/100, with 98 the typical result. The retained record confirms at least two runs; we do not inflate that into a formal three-run series.
For your site: the honest proof is the captured lab trajectory and the current field data, not a polished before score created after the work was done.
Case study — a furniture manufacturer
A Full WordPress Rebuild Instead of Another Patch
The starting point
The existing website for a furniture manufacturer was a slow WordPress installation. The rescue question was whether another round of optimization could produce a clean, durable result or whether the existing implementation had become the constraint.
In this case, the honest answer was a rebuild. Describing it as a small speed tune-up would understate the work and give the wrong expectation to anyone comparing it with their own site.
What we did
We rebuilt the WordPress site into a faster system rather than stacking another temporary fix on top of the old one. This was effectively a full rebuild of the slow site, with the performance problem addressed at the implementation level.
The distinction matters for Rescue work. A plugin can help when a site is fundamentally sound. It cannot turn an unsuitable foundation into a clean one. The useful part of diagnosis is deciding where that line sits before money is spent on repeated patches.
The measured result
Method: Google PageSpeed Insights, mobile profile. Before the replacement, the existing slow site measured 56/100 Performance across three runs, with First Contentful Paint at 8.1 s and Largest Contentful Paint at 11.9 s. The rebuilt site, tested the same way, returned 100/100 Performance across three separate runs.
Both ends of that range were measured three times, not selected from a longer list. That is the difference between a measured result and a marketing estimate.
For your site: if the foundation is the bottleneck, the right rescue may be a controlled rebuild — with both the old site and the finished one measured the same way, not estimated.
Case study — an addiction-prevention nonprofit
A Security Alert Led to a 119 KB Rebuild
Google PageSpeed Insights lab measurements, September 4–5, 2026
The starting point
The first warning was not a speed complaint. It was a security alert. Automated requests were probing a known WordPress core weakness through the REST API. The firewall blocked them, and an independent sweep found no webshell or backdoor, but the alert exposed an aging installation: WordPress needed a security update, 10 of 11 installed plugins were outdated, and a compatibility bug had grown the server error log to 135 MB by repeating the same warning on every page view.
What we did
Security came first. We updated WordPress and the plugins, fixed the warning at its source, cleared the damaged log, and verified that the filesystem was clean.
The next day’s first honest performance baseline returned 50/100 on mobile, with Largest Contentful Paint at 21.0 seconds, and 45/100 on desktop, with LCP at 4.7 seconds. The server itself was responding in single-digit milliseconds. The delay was in the front end: WPBakery, Bootstrap, jQuery and its migration shim, four font families, a discontinued analytics tag, and a hero image controlled by JavaScript.
We converted the site to a static build, leaving one small hardened form endpoint as the only server-side code. That removed WordPress, plugins and the database from the public request path and closed the class of weakness the bots had been probing.
The static conversion made the site safer, but the inherited page-builder front end was still slow. A lightweight optimization pass moved the score only modestly, so we rebuilt the pages with semantic HTML, one small CSS file and a few lines of plain JavaScript. The video players now load only after a visitor chooses to watch them.
The measured result
After the rebuild, two desktop PageSpeed Insights runs returned 100/100. Three mobile runs returned 94 to 100, with 0 ms Total Blocking Time on every measured run. The homepage transfer size fell from roughly 3.4 MB to about 119 KB.
These are laboratory scores from PageSpeed Insights, measured on a simulated phone. They are not the same as field data, which Google collects from real visitors over 28 days and which moves slowly. Lab scores tell you the site is built well. Field data tells you what your visitors experienced, and it lags. Where field data is available for this site we state it separately and say how much of it there is.
This site does not have enough traffic for a Chrome UX Report field-data record, so we do not imply that one exists.
For your site: a security warning and a slow page can be symptoms of the same accumulated machinery. Removing WordPress can close the backend risk; removing the builder-shaped front end is what removed the performance ceiling.
How these numbers were taken
The measurements in a case study have to be recorded at the moment they happen. The old site stops existing the day it is replaced, so a page weight or a speed score remembered afterwards is a number invented afterwards. There is no way to go back and take it.
So every project runs with the evidence captured in stages: the state of the old site on the day of the diagnosis, the decisions logged as they are made, the same measurements repeated on go-live day, and separate lab runs in the seven days that follow. Where a starting score was never captured, we say so plainly rather than reconstruct one.
On lab scores and field data
The lab measurements here are scores from PageSpeed Insights, measured on a simulated phone. That is not the same thing as field data, which Google collects from real visitors over 28 days and which moves slowly. Lab scores tell you the site is built well. Field data tells you what your visitors experienced, and it lags behind the work by weeks.
Where field data exists for a site, we state it separately and say how much of it there is — including when there is not enough to report.
What will not appear here
- Projects we did ourselves, start to finish
- Numbers we measured, on dates we recorded
- Screenshots of the actual site, before and after
- Client permission on file, with the option they chose
- The decisions that went badly as well as the ones that went well
- Work done by other people, presented as ours
- Stock screenshots or invented mockups
- Numbers we did not measure ourselves
- Quotes written by us for a client to approve
- Claims about rankings, traffic, leads or revenue
Filling this page on day one is easy. Borrowed screenshots, a portfolio from a previous job, three invented testimonials with stock photographs — it takes an afternoon, and it tells you nothing about who will actually be working on your site. We would rather show you fewer case studies, honestly measured, than fill this page with borrowed proof.
What else you can judge us on
The diagnosis
EUR 190, delivered in two to three days: a written account of what is wrong with your site, what it would take to fix, and whether it is worth doing at all. If you go ahead with a rebuild, the full EUR 190 comes off the price. If we think you should not rebuild, the diagnosis says so.
The process, written down
How a rebuild actually runs, week by week, is published on this site in full — what we need from you, when, and what happens at each stage. You can read the whole method before you pay for anything.
The terms and the guarantee
Prices, timelines, what each package includes, and the guarantee with its exclusions stated plainly: mobile PSI lab score of 85 or better, measured three times within seven days of go-live. If we do not reach it, we keep working at no extra charge until we do. It is not a money-back promise and we do not describe it as one.
This site
renewsite.com is built to the same standard we sell. Run it through PageSpeed Insights yourself, on a phone profile, right now. It is the one piece of our work you can inspect without asking us for anything.
If your project turns out to be written up here, you will be asked afterwards, not now, and you can say no. Named, anonymised, or nothing at all — all three are fine, the text goes to you before it goes live, and it comes down whenever you say so. Your answer changes nothing else between us.
Start with the diagnosis
EUR 190, two to three days, credited in full if you go ahead with a rebuild. You will know what is wrong with your site and what it would cost to fix before you commit to anything. Capacity is a few projects a month.