Create the page during the build

This note records a November 4, 2026 review of build.js and src/site.js in the RAONIZ repository. The build writes HTML files for Hosting instead of rendering them on a server for every visitor request.

That is a straightforward fit for company and product information that many people read unchanged. The tradeoff is that an edit does not immediately update the public page: source editing, building, and deployment are separate steps. The static website does not thereby handle app features or personalized app data.

One article, two languages, and older addresses

createSitePages() creates home, product, policy, and article pages for each locale, recording their URLs and output files. Korean articles use /ko/insights/…/ and English articles use /en/insights/…/. Older .html addresses are also written with the corresponding content.

Preserving older addresses helps readers arriving through old links. Since content can be reached at several addresses, canonical URLs and language alternates must identify the intended equivalents. Translating folder names is only one part of that work.

Why asset filenames change

The script builder hashes the combined script with SHA-256 and uses part of that hash in its filename. HTML references the matching main.[hash].js. Styles follow the same approach.

A code change produces a new asset URL, allowing new HTML to request a new file even when an older one remains cached. The hash identifies content; it is not a quality or security certification. Other assets, including images with unchanged names, need their own cache review.

Checks after editing

Run these commands in the repository to examine generation and basic checks. The build recreates its dedicated dist output folder and copies original assets from public. Direct edits to generated files disappear on the next build.

npm run build
npm test
npm run verify

The audit checks internal links, anchors, local assets, locale metadata, and source/output consistency. verify reads the existing output without regenerating it. When a check reports a missing route or anchor, correct the source and build again rather than patching the generated file.

What a successful build does not establish

Reading on a phone, opening the actual installation destination, and operating the audio controls still need direct checks. Longer English and Korean text must fit buttons and the table of contents without page overflow.

This build process alone does not establish an improvement in Core Web Vitals. A performance claim needs comparable pages and conditions, with field data distinguished from lab results. See the Core Web Vitals guide; the cache note covers update behavior after deployment.