Etalon Translation is a Slovak translation agency serving three language markets — Slovak, Czech, and English. When they came to me, their site was a WordPress build from 2019: shared hosting, Elementor, WooCommerce cart for quote requests (yes, really). It worked well enough until it didn't.
This is the full story of a 6-week rebuild that lifted conversion by 34% and got Lighthouse to 98.
What was broken
Three things were bleeding money:
Speed. Average page load was 4.2 seconds. WordPress + Elementor + 14 plugins on shared hosting. Every page loaded the entire jQuery stack, a carousel library nobody used, and three analytics scripts. Mobile was worse — 6s+ on 3G.
Content management. The agency wanted to publish blog posts in all three languages. WordPress with WPML made that possible but painful: each translation was a separate post with a manual language link. The team could write in Slovak, but publishing required a developer to wire up the hreflang tags, fix the slug, and clear the cache. They stopped publishing.
Conversion. The contact form was a WooCommerce "add to cart" flow repurposed for quote requests. Users literally added "Translation Service" to a cart, filled in details at checkout, and submitted. The funnel confused everyone — 88% drop-off between the service page and submitted quote.
Constraints
The agency had a working brand identity (colors, typography, logo) and existing content in three languages. We weren't redesigning the brand — we were rebuilding the delivery vehicle.
Budget was fixed. Timeline was 6 weeks from kickoff to production, with a hard deadline: the agency had a conference in Bratislava where they wanted to hand out cards pointing to the new site.
What we shipped
Stack decisions
Next.js 15 with SSG. Every page pre-rendered at build time. No server-side rendering needed — the content changes weekly at most. SSG gives us sub-second TTFB from Vercel's CDN edge, and the build rebuilds in under 30 seconds for the entire 3-locale site.
SCSS Modules over Tailwind. The agency's existing brand guide was detailed — specific spacing scale, color tokens, typography rules. SCSS Modules let me match the brand 1:1 with design tokens in variables, while keeping styles co-located with components. Tailwind would have worked, but the brand fidelity was easier with custom SCSS.
next-intl for i18n. Three locales (sk, cs, en) with locale-prefixed routes, automatic hreflang tags, and translated slugs. The routing just works — etalon.sk/en/services, etalon.sk/cs/sluzby, etalon.sk/sk/sluzby. Each locale gets its own sitemap entry. I wrote about the i18n gotchas separately.
MDX for the blog. The team writes Markdown in a simple editor, drops the file into the repo, and the site rebuilds automatically on push. No CMS login, no database, no cache to bust. Each post is a .mdx file with frontmatter for title, description, date, and locale. Translations are separate files with matching slugs.
The contact flow
This was the biggest conversion lever. We replaced the WooCommerce cart monstrosity with a single-page contact form:
- User picks a service category (translation, interpreting, localization)
- Form fields adapt — translation shows source/target language and word count, interpreting shows date/location
- Submit fires a Telegram notification to the agency owner and a confirmation email to the user
No cart. No checkout. No "add to basket." Three fields to a submitted quote. Time from landing to submission dropped from 4+ minutes to under 40 seconds.
Performance work
The Lighthouse 98 post covers the technical details. The short version:
- Fonts: Self-hosted subset of the brand font,
font-display: swap, preloaded in<head>. Eliminated the FOIT that was adding 800ms to perceived load. - Images: All product/team photos converted to WebP with
next/image. The homepage hero went from a 1.2MB JPEG to a 90KB WebP. - JavaScript: Audited every client-side dependency. Removed jQuery (not needed with React), the carousel library (replaced with CSS scroll-snap), and two of three analytics scripts (kept only Plausible — privacy-friendly, 1KB script).
- Build-time i18n: All translations resolved at build time, not runtime. No client-side translation bundles for unused locales.
Result: 0.8s average load across all pages. Lighthouse 98 on mobile.
The numbers
Six weeks after launch, comparing the same traffic period:
| Metric | Before | After | Change |
|---|---|---|---|
| Avg. page load | 4.2s | 0.8s | -81% |
| Lighthouse (mobile) | 42 | 98 | +56 pts |
| Quote form completion | 12% | 46% | +34 pts |
| Blog posts published | 0/month | 4/month | ∞ |
| Monthly hosting cost | €45 | €0 | -100% |
The hosting cost deserves a footnote: Vercel's free tier handles this site comfortably. The agency was paying €45/month for shared hosting that was actively making their site slower.
The +34% conversion is the headline number, but the blog velocity matters more long-term. The team went from publishing nothing (because it required a dev) to 4 posts per month across three languages. That's compounding SEO value that didn't exist before.
What surprised us
The old site had no analytics. The "before" metrics above are reconstructed from Google Search Console data and server access logs. The agency had Google Analytics installed but misconfigured — it was tracking page views on the admin dashboard, not the public site. We only discovered this during migration. Lesson: verify analytics before you start — you need the "before" numbers to prove the "after."
Content migration was the longest single task. Copying text between systems sounds trivial. It took 8 working days of the 6-week timeline. Every page had inline styles from Elementor, broken HTML entities, and inconsistent formatting across languages. I wrote a Node script to extract clean text from the WordPress export, but the Czech and English translations still needed manual review for accuracy.
The agency didn't need a CMS. My initial proposal included Sanity as a headless CMS. During discovery, I realized the team's actual workflow was: write in Google Docs → send to developer → developer publishes. MDX preserved that flow minus the developer bottleneck. They write in Docs, export to Markdown, commit to the repo. Simpler, cheaper, and one fewer service to maintain.
What I'd do differently
I'd skip the custom SCSS system. It was the right call for brand fidelity, but it added ~10 hours of setup and ongoing maintenance overhead compared to Tailwind with a proper config. For the next corporate rebuild, I'd start with Tailwind and a design token config — the brand fidelity is achievable, and the DX is better.
I'd add Sentry from day one, not week four. We added Sentry in the final sprint for production monitoring. Would have caught two CSS rendering bugs in staging that we found manually. The cost of adding it early is near-zero.
I'd push harder on WebP conversion during migration. We converted hero images but left some interior page photos as optimized JPEGs. They're fine — but "fine" isn't "98 across every page." Going back to convert them now is trivial but feels like cleanup I should have done the first time.
The business result
Etalon's site now loads in under a second, publishes content without developer involvement, and converts visitors to quote requests at 3.8× the old rate. The agency's next conference happened 6 weeks after launch — they handed out cards, people visited the site, and the quote form worked.
Six months later, the site still runs on the free tier. No maintenance incidents. No emergency calls. The agency publishes weekly and their organic search traffic has grown 2.1× from the pre-rebuild baseline.
For a 6-week, fixed-scope engagement, that's the outcome I aim for: a site that works, performs, and gets out of the client's way.
If you're sitting on a WordPress site that's slow, hard to update, and bleeding conversions — the rebuild math usually works out. Book a 20-min call and I'll tell you honestly whether yours is a candidate or whether a lighter fix makes more sense.