Oryx: Server-side renderingEdit on GitHub
Differences between server-side and client-side rendering
Speed and performance: With server-side rendering (SSR), the browser receives pre-rendered HTML, reducing the time taken to display meaningful content.
SEO: SSR is typically more favorable for SEO because search engine crawlers find it easier to index pre-rendered HTML content.
Social media integration: SSR significantly improves integration with social providers like Facebook and Twitter and bots like Slack. It enables the generation of link previews, rich snippets, and thumbnails, enhancing the visibility and appeal of shared content on these platforms.
User experience (UX): By delivering pre-rendered content faster, SSR minimizes user waiting time, providing a superior user experience compared to client-side rendering (CSR).
Resource allocation: While SSR enhances performance and user experience, it requires more server resources and processing power. CSR lightens the server load by offloading rendering to the client but at the cost of potentially increased load times and less effective SEO.
Advantages and disadvantages of SSR
|ADVANTAGES OF SSR||DISADVANTAGES of SSR|
|Quicker initial page load time.||Higher server resource usage.|
|Enhanced SEO.||Higher development and deployment complexity.|
|Improved UX.||Infrastructure concerns.|
|Better social media integration.||Potential for stale content.|
Applicability of SSR
While SSR offers numerous benefits, it’s not the best fit for every type of application, like the following:
- B2B shops with restricted access: public-facing SEO and quicker initial page load times offered by SSR may not significantly benefit these types of applications.
- Business apps: applications heavily focused on functionality, like a fulfillment app, might not require the SEO or user experience enhancements provided by SSR.
- Instore apps: used in a controlled environment and designed for specific functions, these types of applications might not necessitate the benefits of SSR.
SSR implementation approaches
The following sections describe the approaches to implementing SSR.
Traditional server-based SSR
Traditional SSR implementation involves rendering the initial HTML content on a server, typically powered by Node.js.
Serverless SSR using Lambda
Serverless SSR employs on-demand serverless platforms such as AWS Lambda for HTML rendering, eliminating the need for a dedicated server.
SSG is a variant of SSR where the server generates static HTML pages at build time. These pages can be directly served from a CDN, reducing server load and accelerating delivery. This approach is particularly effective for sites where content does not change often. SSG improves load times, scalability, and security.
Caching and CDNs
Caching and CDNs are additional layers that can significantly improve the performance of SSR applications by reducing server load and accelerating content delivery.
Caching acts as a layer on top of rendering. Once the HTML content is rendered, it’s cached to serve repeated requests without the need for rerendering. There are various caching solutions, like Varnish and Redis, or even service-specific solutions, like Cloudflare’s caching services.
CDNs distribute cached content across a network of servers located worldwide. This ensures that users receive content from the nearest server, which significantly improves delivery speed and reduces latency.
In the context of serverless platforms like Netlify, you can leverage Netlify’s on-demand builder. It works as a simple wrapper to Oryx SSR Lambda handler and automatically feeds Netlify Edge CDN by building and caching a page when it’s requested, thereby reducing the load on the serverless function and improving performance.
Moreover, Oryx employs a late hydration strategy, delaying the hydration process until the user interacts with a component. This ensures that client-side resources are only utilized when absolutely necessary, fostering an efficient and highly responsive UX.
Developing with SSR
The following sections describe the development of applications with SSR support in the Oryx framework.
When developing with SSR, it’s important to understand how the SSR process works. SSR involves rendering the initial HTML on the server, which is then sent to the client. This provides faster initial page load times and better SEO. However, because this process can differ from traditional client-side rendering, there are specific considerations and potential pitfalls to keep in mind, such as avoiding direct manipulation of the DOM and being mindful of lifecycle hooks.
Oryx integrates seamlessly with server environments, offering support for traditional Node.js SSR and serverless architectures, similar to AWS Lambda or Netlify functions.
For Node.js SSR, Oryx leverages ExpressJS, a minimalist web framework for Node.js. By utilizing the
createServer method, Oryx spins up an ExpressJS server configured for SSR out of the box.
To enable serverless architectures, the
storefrontHandler method enables SSR in AWS Lambda-like environments.
While both approaches offer sensible configuration tailored to most deployment scenarios, it also exposes a lower-level API, allowing advanced customization to fulfill unique project requirements.
Building with SSR support
Designed with SSR at its core, Oryx ensures that all components correctly render server-side. This enables quick initial page load times and boosted SEO out of the box.
Also, Oryx features mechanisms that further improve performance by managing the hydration process intelligently.
Oryx components are built with SSR in mind. They’re designed to render correctly on the server and work with late and partial hydration. However, when building custom components, be aware of the components’ limited lifecycles coverage, which can lead to unexpected behavior during the SSR process.
Oryx provides special decorators to address some SSR-related challenges:
@hydratabledecorator marks a component for late hydration. This allows the component to render on the server but delays its hydration until it’s interacted with on the client. Hydration can be triggered programmatically, or automatically with events.
@ssrShimdecorator shims certain parts of the component API to make it work on the server. Specifically, it adjusts how the
toggleAttribute()function and style property work.
Oryx also provides utilities to assist with SSR:
ssrAwaiter: This utility manages asynchronous operations during SSR. It’s particularly useful when a component depends on asynchronous data. By using
ssrAwaiter, you can ensure that the server waits for the data before rendering the component.
@subscribe: This decorator is used to manage subscriptions during SSR. It solves the problem of missing lifecycle hooks in SSR and ensures that subscriptions are cleaned up properly.
For submitting the form