November 17, 2023
Kevin Montgomery
|
How is website content stored and where does it get rendered?
In the early days of the internet, website content was delivered to users in HyperText Markup Language (HTML) format from static files that were stored on a web server. Typically web masters would edit these files directly and then upload them to their web server (along with other assets such as images, audio, and video files) to be made available to the wider internet.
Browsers, search engines, bots, and other user agents could request those static files by sending a URL request for that specific item and the web server would send the appropriate HTML for the browser to render or for search engines to index.
Since then, things have changed. While HTML is still the preferred method for delivering content and the markup needed to render it, managing content and rendering it into a complete web page has become much more complex.
Content management systems (CMS) superseded direct editing of HTML and multimedia files on a web server. A typical CMS would handle access, editing, and assembling pieces of content and code into full HTML files for distribution to users. Now content management systems have become one of the components in the larger technology stack used to manage, deliver, and render content for users.
Many content management systems (CMS) are designed to replace basic web servers that hosted and delivered static files including HTML, images, and other multimedia files. A typical CMS is usually paired with a database that stores text content and the general configuration of the website as well as a file server that contains larger multimedia content.
Instead of serving static HTML files when a user requests a page, the CMS will render the HTML for the requested page using templates that are populated with content pulled from the database. Constructing the HTML is typically handled by the “presentation layer” of the CMS before getting sent to the user for display in their browser.
While monolithic content management systems can make setup and deployment of your website easier, there are some drawbacks with managing authentication, content storage, and presenting or rendering a webpage at scale, across different devices, while interfacing with various third-party systems.
Headless content management systems, such as Jamstack sites or Strapi as well as traditional digital experience platforms like Sitecore or Adobe Experience Manager with headless extensions, typically retain the authentication and editing features along with the content storage while a separate front end is used to display the final rendered content to end users. Headless CMSs typically use a REST or GraphQL API to deliver content and data to the front end to assemble and render the final web page and user experience within the browser itself.
Different presentation layers can be used to combine, render, and respond to user behavior without adding complexity to the CMS itself. Headless CMSs may also enable content caching, scalability, and tighter deployment cycles for microservices as opposed to longer-running releases for large monolithic projects.
Shifting to a headless CMS model means that site content and visual assets have to be rendered somewhere that isn’t within the CMS itself. Typically this means that the client side (e.g. a user’s browser) will handle content rendering instead of the server – but there are some configurations where content is still partially or fully rendered server-side before getting delivered to the client.
One of the more common rendering options for headless CMSs is a client-side single page app (SPA). SPAs typically use JavaScript to maintain front end state, request content from the headless CMS, and render it within the browser. Instead of requesting and reloading an entire page the SPA will only update parts of the interface that have changed based on a user’s action or request.
Front end libraries like React, Vue, and others make it much easier to design, manage, and deploy single page apps for a more-consistent and scalable front end. They can keep track of the state of the web app and only request more content from a server when it’s needed.
Another option for separating the presentation/rendering layer from a headless CMS is to use server-side rendering to create static HTML files that are then stored and cached for delivery to the client. Rendering content server side and exporting the static source code can help cut down on client request and client-side rendering times without managing client-side state and SPA functions.
Typically static HTML “snapshots” are only updated when content has changed or as-needed when a visitor requests a page that hasn’t been rendered to static HTML yet.
While not as common as server-side or client-side rendering – edge side rendering composes and renders a webpage on a server that’s close to the user. Edge rendering can connect directly to a headless CMS or intercept and update HTML before delivering it to the client. This allows sites to deliver a customized or personalized experience without having to render the entire document – the edge server only fills in the dynamic content or code that’s needed for the user making the request.
While headless CMSs and different rendering flows might not work for every application it can help reduce server costs and speed up web page response times when done correctly.
While headless CMSs might not make sense for every website they can provide flexibility and scalability that a single content management system may not be able to deliver. In many cases it’s possible to gradually transition to headless rendering with most content management systems that have content APIs. New features and pages can progressively add headless or client-side rendering features while still retaining legacy server-side rendered content from the CMS.
In a separate post, we’ll discuss options for deploying site search within a headless architecture. For the time being, check out our post on the Search UI Kit for SearchStax Studio – we developed specifically to support front-end frameworks within a headless environment.
Copyrights © SearchStax Inc.2014-2024. All Rights Reserved.
SearchStax Site Search solution is engineered to give marketers the agility they need to optimize site search outcomes. Get full visibility into search analytics and make real-time changes with one click.
close
SearchStax Managed Search service automates, manages and scales hosted Solr infrastructure in public or private clouds. Free up developers for value-added tasks and reduce costs with fewer incidents.
close
close