Rendering strategies for the web: CSR to ESR under core web vitals constraints


Abstract

This survey compares modern web-page rendering techniques: Client-Side Rendering (CSR), Server-Side Rendering (SSR), Static Site Generation (SSG), Incremental Static Regeneration (ISR), and Edge-Side Rendering (ESR), in terms of Google's Core Web Vitals (LCP, INP, CLS). Based on authoritative specs and empirical research published between 2022 and 2025, it quantifies the performance compromises that influence first-load speed, interactivity, SEO, and operational complexity.

The benchmark validates that SSR and SSG provide the quickest Largest Contentful Paint consistently, whereas pure CSR requires aggressive code-splitting and progressive hydration in order to reach today's INP benchmarks. Hybrid approaches like ISR and streaming SSR close the gap by fusing static-like speed with on-demand freshness. ESR closes the network latency by shifting rendering to geographically distributed edge nodes, at the cost of distributed-state and cache-invalidation complexity.

Case studies from the industry (DoorDash, Preply, Shopify, and others) illustrate actual benefits: LCP by up to 65 % after CSR→SSR migration and INP less than 200 ms with selective hydration. The results are consolidated in a decision-making framework that aligns rendering models with content volatility, audience geography, and infrastructure capacity.

Looking ahead, the paper highlights emerging trends: React Server Components, partial hydration, and fine-grained edge compute, that have the potential to decouple interactivity from main-thread bottlenecks and make optimal code placement automatic. Taken together, these advances foretell a future where hybrid, performance-conscious rendering pipelines represent the default route to speedy, resilient, and search-visible web experiences.

Ask to review this manuscript

Notes for potential reviewers

  • Volunteering is not a guarantee that you will be asked to review. There are many reasons: reviewers must be qualified, there should be no conflicts of interest, a minimum of two reviewers have already accepted an invitation, etc.
  • This is NOT OPEN peer review. The review is single-blind, and all recommendations are sent privately to the Academic Editor handling the manuscript. All reviews are published and reviewers can choose to sign their reviews.
  • What happens after volunteering? It may be a few days before you receive an invitation to review with further instructions. You will need to accept the invitation to then become an official referee for the manuscript. If you do not receive an invitation it is for one of many possible reasons as noted above.

  • PeerJ Computer Science does not judge submissions based on subjective measures such as novelty, impact or degree of advance. Effectively, reviewers are asked to comment on whether or not the submission is scientifically and technically sound and therefore deserves to join the scientific literature. Our Peer Review criteria can be found on the "Editorial Criteria" page - reviewers are specifically asked to comment on 3 broad areas: "Basic Reporting", "Experimental Design" and "Validity of the Findings".
  • Reviewers are expected to comment in a timely, professional, and constructive manner.
  • Until the article is published, reviewers must regard all information relating to the submission as strictly confidential.
  • When submitting a review, reviewers are given the option to "sign" their review (i.e. to associate their name with their comments). Otherwise, all review comments remain anonymous.
  • All reviews of published articles are published. This includes manuscript files, peer review comments, author rebuttals and revised materials.
  • Each time a decision is made by the Academic Editor, each reviewer will receive a copy of the Decision Letter (which will include the comments of all reviewers).

If you have any questions about submitting your review, please email us at [email protected].