The target

For this site, the goal was to keep the visual direction strong without making the first load heavy.

The target was straightforward:

  • Lighthouse Performance above 95
  • SEO 100
  • TBT close to 0ms
  • CLS below 0.1
  • Clear contact and consulting paths from the first screen

At implementation check time, the main pages reached roughly Performance 99-100, SEO 100, TBT near 0ms, and CLS below 0.1.

The biggest win: fewer external dependencies

The first meaningful improvement was removing Google Fonts.

Japanese web fonts can improve visual tone, but they often slow down corporate sites. This site uses system fonts for Japanese and self-hosts only a lightweight Latin subset for display text.

That removes extra connection setup, stylesheet fetching, and font loading from an external domain.

Pre-render HTML and let Cloudflare serve it

Pages are generated at build time instead of being assembled on every request.

That keeps normal page views close to static delivery through Cloudflare. Worker logic stays focused on the few dynamic needs, such as contact handling.

Headers are also generated for the static side:

  • /assets/* uses public, max-age=31536000, immutable
  • HTML uses edge caching with s-maxage and stale-while-revalidate
  • XML and TXT assets get suitable cache headers
  • Security headers are applied through _headers

Because asset filenames are hashed, CSS and JS can be cached for a long time without update conflicts.

SEO belongs in the generated HTML

Speed is not useful if the HTML becomes too thin for search engines and social previews. SEO fields are rendered into the first HTML response for every page.

This includes:

  • canonical URLs
  • ja / en / x-default hreflang
  • meta descriptions
  • Open Graph and Twitter Card metadata
  • JSON-LD
  • sitemap.xml
  • robots.txt

Home renders WebSite and ProfessionalService, blog articles render BlogPosting, and product detail pages render Service.

This keeps performance and SEO aligned instead of making SEO depend on client-side JavaScript.

Use strong images only where they matter

The redesign uses key visuals and character art for the original product section. More images can hurt LCP, so the rule was to keep imagery deliberate.

The implementation does this:

  • Prioritize only the image needed in the first view
  • Lazy-load images outside the initial view
  • Convert images to WebP
  • Set width and height to prevent layout shift
  • Avoid decorative image bloat

That keeps the product presentation rich without turning the corporate site into a heavy page.

URL consistency affects both cache and SEO

Trailing slash behavior can split real URLs from canonical URLs. Cloudflare Assets is configured to drop trailing slashes, keeping /ja, canonical URLs, hreflang, and sitemap entries aligned.

It is a small setting, but it helps cache consistency and avoids SEO ambiguity.

The tech stack behind this site

The technical choices prioritize static delivery, complete HTML, and a clean fit with Cloudflare.

The main stack is:

  • TypeScript
  • Hono / Hono JSX
  • Cloudflare Workers
  • Cloudflare Assets
  • Wrangler
  • Tailwind CSS v4
  • Markdown
  • gray-matter
  • marked
  • Zod
  • esbuild
  • Vitest
  • Biome
  • Lighthouse CI
  • pnpm

HTML is composed with Hono JSX, but the pages delivered to users are static HTML generated at build time. The site is not a client-side SPA. The initial response already includes the HTML, metadata, and JSON-LD needed for rendering and SEO.

Markdown is used for blog posts and productized service pages. gray-matter reads frontmatter, marked converts body content into HTML, and Zod validates required fields and date formats. That catches broken content during the build instead of after deployment.

Tailwind CSS v4 generates the stylesheet, which is served as normal CSS. Client-side JavaScript is kept small. Only necessary behavior, such as the consent banner, is bundled with esbuild.

On Cloudflare, Workers handle dynamic behavior such as the contact API, while normal pages are served statically through Assets. _headers defines cache and security headers, and wrangler.toml keeps URL handling consistent.

Quality checks are based on Vitest, TypeScript, Biome, and the static build. Lighthouse CI is used when a change affects delivery, rendering, or performance.

The point is not to use the largest framework possible. The point is to combine only what a corporate site needs: SEO, speed, contact flow, content updates, and stable deployment.

What gets checked after changes

Lighthouse is not run after every small content change. The check scope depends on the type of change.

For normal content and UI updates, the routine is:

  • pnpm run build:assets
  • pnpm run typecheck
  • pnpm test
  • Browser check on the affected page
  • Console error check

Lighthouse is reserved for changes that touch performance, delivery, assets, or rendering strategy.

That keeps iteration fast while preserving quality.

The repeatable order

For a similar fast corporate site, the order is:

  1. Question external fonts first
  2. Pre-render every page that can be static
  3. Give CSS, JS, and images long-lived cache headers
  4. Cache HTML at the edge
  5. Put SEO metadata into the initial HTML
  6. Use WebP images with explicit dimensions
  7. Align URLs, canonicals, hreflang, and sitemap entries
  8. Keep the stack aligned with static delivery
  9. Run Lighthouse at meaningful checkpoints

The core idea is simple: remove heavy dependencies, serve static output whenever possible, and keep the generated HTML complete.

That is how this site stays fast while still supporting consulting funnels, SEO, and original product presentation.