How Live Preview works

What is your website Architecture?

When deciding between Client-Side Rendering (CSR) and Server-Side Rendering (SSR) for implementing Contentstack live preview, it's essential to consider the specific needs and constraints of your project.

Contentstack supports both SSR and CSR, and the choice might also depend on the specific framework you are using (e.g., Next.js for SSR, React for CSR). Contentstack provides SDKs and APIs that are compatible with both approaches.

Here are some key factors to help you decide:

Client-Side Rendering (CSR)

• Interactivity: CSR allows for highly interactive applications as JavaScript is executed on the client side.
• Initial Load Time: The initial load time can be longer because the browser has to download and execute JavaScript before rendering the content.
• Complexity: Implementing live previews might be more complex as you need to ensure that the client-side app can handle real-time updates and rendering.

Server-Side Rendering (SSR)

• Initial Load Time: The initial load time can be faster because the server sends a fully rendered page to the client.
• Complexity: Implementing live previews can be easier and more seamless since the server renders the updated content.
• Performance on the Server: SSR can be more demanding on the server, especially with a high number of concurrent users.
• Interactivity: SSR might not be as interactive out of the box as CSR, although hybrid approaches can mitigate this.

Hybrid Approach

In many cases, a hybrid approach, using both CSR and SSR, might be the best solution. For example, you can use SSR for the initial load to benefit from SEO and faster initial load times, and then switch to CSR for subsequent interactions to enhance interactivity.

Live Preview in CSR

Client-side rendering (CSR) involves a process where all rendered HTML client pages are generated on the browser side. Consequently all the data fetching is also done on the client side. This guide explains in detail how to set up Live Preview for an CSR Application.

How CSR Works:

1. Initial HTML and JavaScript Load:
   • When a user visits a CSR-based web application, the server sends an initial HTML document that often includes references to JavaScript frameworks like React, Angular, or Vue.js.
   • This initial HTML might include placeholders or loading indicators where content will be rendered dynamically.
2. Data Fetching and Rendering:
   • Once the browser loads the initial HTML and JavaScript, the client-side code makes requests to APIs or other data sources to fetch necessary data.
   • This data is then used by the JavaScript frameworks to dynamically render the actual content on the page.
   • This process allows for highly interactive and responsive user interfaces, as changes can be made to the UI without requiring full page reloads.
3. Benefits:
   • Speed and Responsiveness: CSR can provide a faster initial load time because only minimal HTML is initially transferred.
   • Interactivity: Applications can feel more responsive since data fetching and rendering happen on the client side without waiting for server responses for every interaction.
   • Flexibility: Developers have more control over how content is displayed and can create highly dynamic user interfaces.

When a website is opened in the Live Preview pane, data is fetched live from the current entry using a GET call over preview service url. If changes are made to the entry, with those changes Contentstack sends a PATCH call. The onEntryChange() function then triggers another GET call to fetch the updated data, which is re-rendered on the webpage in Live Preview pane.

Live Preview in SSR

Server-side rendering (SSR) involves a process where an application generates rendered HTML client pages on the server rather than in the browser. Consequently, data fetching is also done on the server side, with HTML pages created and sent to the browser. This guide explains in detail how to set up Live Preview for an SSR Application.

Server-Side Rendering (SSR)

1. Request Handling:
   • When a user requests a page from a SSR-based application, the server processes the request and generates the complete HTML for that page.
   • This includes the content of the page, data fetched from databases or APIs, and the initial state of any client-side frameworks (if used).
2. HTML Generation:
   • Server-side frameworks like Next.js (for React), Nuxt.js (for Vue.js), or server-side template engines (e.g., EJS, Pug) are commonly used to facilitate SSR.
   • These frameworks or engines render components or templates with the data provided by the server into a complete HTML document.
3. Sending HTML to Client:
   • Once the HTML is generated on the server, it is sent to the client's browser as a fully formed document.
   • This HTML can include all the content necessary for the initial view of the page, reducing the need for subsequent data fetching before the page can be fully rendered.
4. Client Interaction:
   • Once the initial HTML is rendered on the client's browser, any further interactivity can be enhanced with client-side JavaScript.
   • This includes handling user events, making API calls for dynamic updates, and managing client-side state using frameworks like React, Vue.js, or Angular.
     

Working of Live Preview in SSR

When a website is opened in the Live Preview pane, the server builds HTML pages with data fetched live from the current entry using a GET call over the preview-service URL. These pages are then sent to the client and rendered in the Live Preview pane. If changes are made to the entry, Contentstack sends a PATCH call with those changes. The webpage in the Live Preview pane is then refreshed, and the server builds HTML pages with the updated data fetched from another GET call. These updated pages are sent to the client and rendered in the Live Preview pane.