Lashstudio.ro — a beauty website built as a product.

Bucharest and Ilfov have a few thousand active beauty salons. They all offer roughly the same things: lash extensions, micropigmentation, lamination, facials. Offline differentiation only goes so far. For a new customer, the first contact is almost always a Google search or an Instagram scroll.

That's where the problem starts. Most salons have slow websites, no SEO, no structured data. WordPress with generic themes and 20+ plugins that load the second image after 5 seconds. The technical bar is low. Anyone who shows up with a clean, fast site walks right over them.

I ruled out WordPress from the start. Not because WordPress is bad — it's a mature platform. But the multiple plugins, overloaded database, and overhead from Romanian beauty themes make performance nearly impossible without ongoing tuning work. For a presentation site with simple booking, there are cleaner options.

The stack I picked:

• Next.js 16 with App Router: server-side components, built-in image optimization, ISR for frequently updated pages
• Tailwind CSS 4: no config file, palette directly in globals.css, zero runtime overhead
• Neon Postgres: bookings and client database
• Vercel: hosting and global CDN
• NameHero: email on a custom domain ([email protected])
• NextAuth: admin authentication

With this stack, Best Practices and SEO hit 100 on the first deploy. Performance and Accessibility took extra work.

Structured data

Schema.org JSON-LD is how Google and the new AI engines (ChatGPT Search, Perplexity, AI Overviews) understand what your site does. Without it, you're silent to these systems — you might show up, but no one cites you in AI answers.

Lashstudio has several schema layers:

• BeautySalon schema globally in the root layout: full address, phone, email, hours, social media, geo coordinates
• Service schema on each service page: price, duration, description, offers
• FAQPage schema: 9–10 questions per service with answers formatted properly
• BreadcrumbList for hierarchical navigation

Long-tail keywords

On "micropigmentation" alone, you can't win. There you compete with every aesthetic clinic in the country plus portals like Treatwell and Booksy. I went after queries with specific intent:

• "how to take care of lash extensions"
• "lip micropigmentation contraindications"
• "how long does carbon peel take to heal"
• "can I get brow shaping after botox"

For each service I identified 10–15 such questions — partly from People Also Ask, partly from what Andreea hears from clients at every appointment. The answers show up in two places: on the page as info boxes ("Care rules", "Contraindications", "Pre-procedure prep"). And in FAQ schema, so they can be cited in featured snippets or AI answers.

NAP consistency

Name, address, phone must be identical everywhere. On the site, in JSON-LD schema, on Google Business Profile, in local directories. Google uses this as a trust signal. A comma added, a digit flipped, or an address shortened in one spot weakens local ranking. I centralized the data in one place in code and check manually wherever it appears.

Dynamic sitemap

app/sitemap.ts automatically generates sitemap.xml with all URLs, priorities, and changeFrequency per page type. Adding a new page lands in the sitemap with no extra code.

A few practical details:

• The closed mobile menu gets the inert attribute via useEffect. Links disappear from tab order, and keyboard users don't hit invisible elements.
• Skip link "Skip to content" — focusable, visually hidden, appears only on Tab.
• All text meets 4.5:1 contrast minimum. The /60 or /50 opacities on text I replaced with solid colors from the palette.
• Explicit focus visible on all buttons and links, with a colored ring.
• ARIA labels on icons, aria-hidden on decorative elements.

Final score: 96. To hit 100, a few small accent-colored texts would need revisiting. Below I explain why I chose to stay at 96.

After the first week live, I came back for a round of targeted optimizations. PageSpeed Insights flagged a few issues: render blocking 900ms, forced reflow 348ms, unused JS 29 KiB.

I tried 6 things. Three worked, three didn't. I'm sharing all of them, because "what doesn't work" is as useful as "what works."

What worked

1. Resize logo from 5000×2092 to 600×251 — the logo delivered by the client was 5000px wide, 306 KB. On the site it displayed at max 80 CSS pixels. So I was shipping an image 13× larger than needed. Resize with sharp to 600×251, quality 90, output WebP: down to 26 KB. Direct win: −280 KB on every first load, no visible difference at all.

2. Scroll listener with requestAnimationFrame — the nav shortened in height when the user scrolled past 40px. The handler read window.scrollY and set state directly. PSI flagged "forced reflow 348ms". The fix: throttle with requestAnimationFrame and setState only when the value actually changes. Plus I shortened the CSS transition from 500ms to 300ms. Forced reflow turned green.

3. Hero image with blur placeholder — Next.js <Image> supports placeholder="blur" with blurDataURL. I generated a tiny base64 (10×10px blurred) for the hero. The user sees something painted on screen instantly, before the real image downloads. Perceived performance ↑ even without a real LCP improvement.

What didn't work

4. experimental.optimizeCss: true — on paper sounds perfect: extract critical CSS, inline it, defer the rest. Real result: Performance dropped from 91 to 89. Forced reflow came back. The experimental flag really is experimental. Rollback in 2 seconds. Lesson: test experimental flags in isolation, not in production on real traffic.

5. Dynamic import for CookieConsent and GoogleAnalytics — I wanted to pull both client-side components out of the initial bundle via next/dynamic. Logically, they're non-critical. Result: Performance dropped from 91 to 87. For components this small (under 3 KB each), the overhead of a separate runtime fetch is bigger than the bundle-splitting win. Lesson: code splitting makes sense for large or rarely-used components, not for things that show up on first paint.

6. Changing the accent color for Accessibility 100 — the most painful decision. PSI flagged contrast fail on #e8967e (pink-coral) used as text on cream background. For a perfect 100, it'd need to switch to a darker variant (#a4502f, rust). 115 replacements across 19 files. I made the change, then reverted it. The accent went rusty, the palette lost its "warm coral" feel that was part of the salon's visual identity. The 4-point Accessibility gain didn't justify the palette change on visible text. The salon chose to stay at 96 with the original palette. 96 is still industry-leading.

What I learned from this round

Two practical things that stick with me:

First: not every "best practice" recommended by PSI applies universally. Experimental flags and dynamic imports for small chunks can have the opposite effect. Measure after each change. Don't assume the direction is right just because the docs say so.

Second: there's a point beyond which technical optimizations stop bringing real user gain. The difference between 91 and 95 on PSI doesn't show in actual behavior. The next gains come from new content, backlinks, conversion — not from one more kilobyte cut from a shared chunk.

1. WordPress isn't the best choice for small salons if you want real performance. Cost-benefit is weak vs modern alternatives.
2. JSON-LD schema is the most underrated SEO optimization. Two hours of work, measurable benefits for months.
3. Extended FAQ on the service page works better than a separate blog for long-tail searches. Plus Google cites it more often in featured snippets.
4. JPEG → WebP saves 50–80% on image size with no visible loss. For a beauty site with dozens of photos, that's megabytes per load.
5. Don't add libraries for simple things. A working lightbox in React is 50 lines with Context. A 30KB library for the same result is overkill.