# Faster corporate websites at the edge | Muscle Industry > Design principles, the technical stack, cache policies, and quality checks used to improve loading and search compatibility. Canonical: https://muscleindustry.work/en/blog/first-post Language: en May 15, 2026 # Faster corporate websites at the edge Design principles, the technical stack, cache policies, and quality checks used to improve loading and search compatibility. [#performance](https://muscleindustry.work/en/blog/tags/performance)[#cloudflare](https://muscleindustry.work/en/blog/tags/cloudflare)[#seo](https://muscleindustry.work/en/blog/tags/seo)[#typescript](https://muscleindustry.work/en/blog/tags/typescript) ## Design targets, not universal guarantees The goal is a fast first view and responsive browsing without sacrificing usability. Our targets are Lighthouse Performance of at least 95, SEO 100, TBT close to 0ms, and CLS below 0.1, ideally zero. These are diagnostic and design targets, not guarantees for every device or network. Lighthouse and TBT are not interchangeable with [Core Web Vitals](https://developers.google.com/search/docs/appearance/core-web-vitals). LCP and CLS can be measured in the lab, while real-user measurements matter for assessing field experience. ## Fonts and images Japanese uses operating-system fonts. A lightweight Latin subset is self-hosted for display text. This avoids external Japanese font downloads without pretending that all external communication has been removed: consent-based analytics and security verification still have specific roles. Images use appropriate formats and dimensions. The main image is not lazy-loaded; images below the initial view can be. Explicit width and height reduce layout shifts, rather than guaranteeing that CLS will always be zero. ## Static generation and Worker execution are different questions Hono JSX generates HTML at build time. The delivered site does not depend on a client-side SPA constructing its initial article and metadata. Ordinary HTML requests nevertheless pass through a site-specific Worker for response handling and Markdown negotiation. General images, CSS, and JavaScript under `/assets/*` use Assets directly. On the main site, `/assets/ffmpeg-core/*` is an exception served through the Worker from R2. Each official site has its own Worker, configuration, canonical host, and `dist/sites/` output. ## Cache and response policies - Content-hashed CSS and JavaScript can use long-lived immutable caching. - Fixed-name assets require revalidation rather than a blanket immutable policy. - HTML combines browser revalidation with edge-cache directives. - Negotiated Markdown and public API responses use `no-store`; content negotiation preserves `Vary: Accept`. - Security headers are enforced at the appropriate Assets and Worker boundaries. A cache directive describes the policy. It is not a promise that every edge location retains a response for the same duration. ## Search metadata in the initial HTML Generated pages include canonical URLs, language alternates where applicable, descriptions, Open Graph and Twitter metadata, and JSON-LD. The main homepage uses WebSite and ProfessionalService, blog posts use BlogPosting, and service pages use Service. Sitemaps and robots.txt are separate generated files, not tags embedded in HTML. These measures help machines interpret pages; they do not guarantee rankings or rich results. See [Google's people-first content guidance](https://developers.google.com/search/docs/fundamentals/creating-helpful-content). ## URL consistency The main site uses Cloudflare Assets' `drop-trailing-slash` behavior, with canonical URLs, hreflang, and sitemap entries kept consistent. App sites may have different URL conventions and are not forcibly rewritten to match the main site. ## Implementation choices The stack combines TypeScript, Node.js, pnpm, Hono JSX, Cloudflare Workers and Assets, Wrangler, Tailwind CSS v4, Markdown, gray-matter, marked, Zod, esbuild, Vitest, Biome, and Lighthouse CI. Zod checks frontmatter structure and field formats. It does not determine whether an article is factually correct or ready to publish. Client-side JavaScript is reserved for interactions such as consent controls, contact forms, and tools. ## Verification and explicit publication Changes to code and published content run through `quality:ci` (audit, formatting, types, unit tests, build, and Worker tests), `security:osv`, and `git diff --check`. Display and SEO changes also require browser inspection and Lighthouse. An ordinary push or pull request does not automatically publish this repository. A verified commit is explicitly released, followed by production checks. The repeatable process is to clarify the delivery boundary, reduce unnecessary dependencies, separate cache policies, validate metadata and links, check rendering, and deploy the same verified commit. No single setting provides all of these outcomes.