Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
In Piyush Chauhan’s hotel-and-editorial site, Razor Pages owns the public pages and React handles selected interactions. A separate Node worker uses Playwright to mount those React islands in Chromium, capture the completed document, and save it in PostgreSQL before visitors request it. The public gateway then serves the stored HTML, so Chromium is not part of the visitor request.
Chauhan describes the arrangement as browser rendering at publication time—not React server-side rendering in .NET. It is one implementation, not a benchmark or a guarantee of better SEO or performance. Read Chauhan’s account on DEV Community; the article links its project repository.
What the architecture assigns to Razor, React, and the worker
The site combines catalog and journal pages with search and a stay-inquiry flow. It is not described as a reservation or payment system. Its public HTML has a clear owner: ASP.NET Core Razor Pages supplies routes, content, page shell, metadata, structured data, and useful no-JavaScript output. React islands add selected interactive controls rather than taking over the whole document.
| Part | Responsibility in Chauhan’s implementation |
|---|---|
| Razor Pages | Public routes, catalog and article content, HTML shell, SEO metadata, structured data, and baseline output that works without JavaScript. |
| React islands | Search and date controls, gallery, mobile navigation, and inquiry-form interaction. |
| PostgreSQL | Catalog content, snapshot jobs, and published HTML. |
| Node/Playwright worker | Requests eligible source pages, runs browser capture and validation, and conditionally publishes completed HTML. |
| Public gateway | Looks up and serves the stored document for a canonical path. |
The admin interface is a separate protected React Router single-page application. That separation matters: the stored public document is meant to be a shared page, not a personalized response containing an editor session, user input, or authentication state.
#1 Best Overall
How a page becomes a published snapshot
Capture is part of the publishing pipeline. The worker renders a source page after an edit or release, rather than waiting for a visitor to trigger a refresh.
- Razor emits the source page. It includes island markers and serialized props. A hotel page, for example, can provide gallery data through a marker.
- A content change queues affected routes. The publishing system associates work with canonical paths, including related pages that may display the changed content.
- The worker requests an internal source route. It sends a token-protected request for an allowed canonical route. The source runtime eagerly mounts islands for capture even if the visitor-facing experience would normally defer a visible island.
- Playwright waits for readiness and serializes the document. The browser runs the page, waits for its readiness signal, and returns the rendered HTML.
- The worker validates the result and its version. It checks document invariants and confirms that the queued job is still current. If a newer edit has superseded the job, the worker discards the stale capture.
- Completed HTML is saved atomically. A successful capture is stored with job completion; partial or obsolete output is not published.
- The gateway serves the stored page. React hydrates populated markers in the visitor’s browser. In a live development context, empty markers can instead be rendered from scratch.
Chauhan also describes runtime adjustments for the captured document: it removes Chromium-added Vite module-preload hints and inserts separators between adjacent island text nodes so the saved HTML can hydrate correctly. On visitor requests, visible islands can be deferred with an IntersectionObserver, even though capture mounts all islands eagerly.
Which routes belong in snapshots—and which stay live
The design snapshots canonical public GET or HEAD requests. It does not use arbitrary query strings, cookies, authentication state, or POST bodies as public cache keys. This is a boundary for shared output, not simply a performance choice.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Rank #2
- HTML CSS Design and Build Web Sites
- Comes with secure packaging
- It can be a gift option
- Snapshot candidates: canonical catalog and editorial routes, including a bare
/searchpage. - Live and private: filtered search results, inquiry pages and submissions, admin documents, and APIs. The article describes filtered search responses as
private, no-storeandnoindex,follow. - Excluded from indexing: query-specific search result URLs, while the bare search route can have a canonical snapshot.
The reported public cache configuration is max-age=60, stale-while-revalidate=300. Those are settings in this implementation, not a general recommendation or measured performance result. They also mean a saved edit may not appear immediately to every visitor. When a route is unpublished or renamed, its stored document is removed, but copies already held in caches can remain for the declared cache period.
How the worker handles edits, retries, and first publication
A snapshot system needs a consistency rule: an older browser capture must not overwrite a page after a newer edit. In Chauhan’s implementation, the admin publication and invalidation of affected paths share a database transaction. A hotel edit may affect its own route, destination pages, the bare search page, home, offer pages, and articles that embed catalog records. A rename also queues the old paths.
The worker leases due jobs using PostgreSQL FOR UPDATE SKIP LOCKED, then checks the desired version under a row lock before saving HTML and deleting the job. If the desired version changed while Chromium was rendering, that output is discarded. Errors release the job for exponential-backoff retry; a partial document is not made public.
Rank #3
A prior complete snapshot can remain available during regeneration. A new canonical route with no completed capture can instead return 503 with Retry-After: 5 until its first successful capture. Chauhan’s practical implication is to complete publication before directing production traffic or crawlers to a new path. If a route remains pending, the worker logs and job table are the operational places to investigate.
Why this is not ordinary SSR, SSG, ISR, or PPR
These labels describe different choices about when HTML is generated and what work happens on a visitor request. The distinctions below are Chauhan’s conceptual comparison, not an independent survey of current framework capabilities.
| Approach | When HTML is generated | What the visitor request involves | Trade-off highlighted in the article |
|---|---|---|---|
| SSR | Per request, potentially with caching. | Rendering and possibly data access, unless cached. | Can naturally fit request-specific data; uncached work adds request-path cost, and caching needs careful boundaries. |
| SSG | At build time. | Can serve generated pages simply. | Edits or new catalog pages may require a rebuild and redeploy unless another regeneration mechanism exists. |
| ISR | After revalidation. | Often serves a stale copy while regeneration happens. | Refresh rules and stale windows need management. |
| PPR | A static shell is prepared, with dynamic regions rendered or streamed at request time. | Dynamic regions still render or stream as part of the request. | Unlike this implementation, it does not publish one complete shared document for the route. |
| Chauhan’s snapshot worker | In the background after queued edits or releases. | Serves the saved HTML; Chromium is not run on the visitor request. | Avoids browser rendering on the public request path, but introduces publication delay, possible first-capture 503s, and a database and browser-worker operation. |
What this design does—and does not—establish for SEO
For a successfully published hotel URL, the first HTML response can contain its heading, description, links, gallery markup, and metadata without waiting for React to execute. Chauhan describes canonical URLs, page-specific titles and descriptions, Hotel JSON-LD, a sitemap of published canonical routes, and noindex,follow for filtered search URLs.
Rank #4
- Brand: Wiley
- Set of 2 Volumes
- A handy two-book set that uniquely combines related technologies Highly visual format and accessible language makes these books highly effective learning tools Perfect for beginning web designers and front-end developers
That makes the page’s content and metadata available in the initial response; it does not establish that a search engine will index or rank it. A sitemap is a discovery hint, structured data does not guarantee a rich result, and a newly queued URL can initially return 503. Canonical URLs are embedded at capture time, so changing PUBLIC_ORIGIN requires republishing. Old cached pages and assets also need to be considered when changing publication settings.
The article reports no Lighthouse score, controlled performance comparison, or named performance study. A Lighthouse result measures a loaded page and is not a direct test of what a no-JavaScript crawler receives. To assess this kind of system, inspect the published HTML and its canonical and robots directives, verify the sitemap, and repeat performance audits under consistent conditions. Chunks, CSS, images, fonts, cache and server behavior, hydration, and audit settings can all affect those results.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Security and deployment boundaries to plan for
The internal source endpoint is described as requiring a sufficiently long token, accepting only recognized canonical routes, and returning private/no-store and noindex headers. Chauhan says it should also be blocked from public ingress: a robots directive is not a security boundary. The worker restricts fetched resources to its configured API origin.
Capture checks in the implementation reject pages with missing canonical metadata, unrendered islands, unexpected executable scripts, browser errors, password or antiforgery inputs, or token strings. These are publishing checks, not proof that arbitrary application data is safe to cache. The underlying safeguard is to allowlist canonical public routes and keep user-specific content on a separate live/private path.
The setup distinguishes live Razor/Vite development from snapshot development. The article gives pnpm dev for live Razor pages and Vite HMR, and pnpm dev:snapshots for the Vite manifest, .NET process, and continuous worker; these are repository-specific commands, so verify them against the project version you are using. Snapshot development needs the Vite manifest and a continuously running worker. The production-like flow also needs PostgreSQL, an internal token, and Playwright Chromium.
- The worker’s asset fingerprint includes the Vite manifest, relevant source files, and
PUBLIC_ORIGIN; a changed fingerprint requeues stored pages. - Keep old hashed assets available while published snapshots still reference them.
- In snapshot mode, restart the API after rebuilding its manifest.
- Account for worker health, route allowlists, token handling, PostgreSQL job state, and asset retention as ongoing operational responsibilities.
When this pattern fits
This approach is most plausible when a site has many public pages with largely shared content, wants complete initial HTML, and can tolerate edits becoming public after a background publishing step. It is less attractive when most pages depend on user-specific or rapidly changing request data, or when operating Chromium and a job pipeline would outweigh the value of removing browser rendering from visitor requests.
Chauhan’s own concise description is: “Razor owns the pages. React owns a few interactions. A separate browser publishes the finished HTML before anyone visits.” That is a useful summary of this particular division of responsibility, not a universal rule for .NET and React applications.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
