Single-page Apps (SPAs) are named this way because there is only one single HTML document that is served to a client via the browser. While you may be navigating away from a particular page and the link in the address bar is updated accordingly, you are still on the same root page (index.html). The browser doesn't refresh the page and there's no actual new page that gets loaded.

When a user navigates to a new page in a Single-page App, the DOM is used to update portions of the current page, as specified by the JavaScript code of the SPA. SPAs do not require page reloading during use. Examples of SPAs are Gmail, Google Maps, Facebook, Twitter, or GitHub.

SPAs request a page's markup and data independently and render the page directly to the browser. JavaScript frameworks such as Angular, and JavaScript libraries such as React and Vue allow us to easily build a SPA.

SPAs are different from Multi-page applications (MPAs) which use a client-server architecture. With MPAs, a server needs to re-serve a page's resources (Ex: HTML, CSS, scripts, data) with every page refresh or page navigation. When loading a new page, the browser will need to download all resources for that page from the server, even if the page contains components that are repeated on several pages (Ex" header, footer). This can decrease a website's speed and performance.

Pros of SPAs

• Since SPAs don't update the entire page, but only specific sections of a page, they improve a website's speed.
• They are fast. Most resources (HTML, CSS, Scripts) are typically only loaded once during the user's session.
• Development is simpler because you don't need to use a server or write server-side code in the front-end application.
• They are easy to debug with modern browsers like Chrome. Network operations can be monitored for data retrieval, and web components injected in the DOM can be inspected.
• A SPA serves as a good base for future mobile app development. Example: If you build a SPA in React, you can easily transition it over to React Native for a mobile app.

Cons of SPAs

• The first launch of a SPA takes a bit longer to load compared to traditional multi-page applications (MPAs). The SPA typically downloads all the HTML, CSS and JavaScript files on first page load. After this initial load, the following actions occur almost instantly.
• Dealing with browser history in a SPA can be difficult due to soft navigation, where a URL changes in the browser but it doesn't actually re-load an entire page. The History API in HTML 5 (ex: pushState) helps to solve this.
• SPAs aren't search engine friendly by nature. Most search engines don't like JavaScript.

SPAs and Search Engines

Googlebot, Google's crawler has gotten better at indexing JavaScript-based websites and SPAs. Search engine crawlers typically visit a URL and parse the HTML response, expecting it to contain all the content of a page. With SPAs, the initial HTML does not contain the actual content. Googlebot needs to execute JavaScript before being able to see the actual page content that JavaScript generates.

With Server-Side rendering (SSR), all of the HTML content of a page is present in its source code. This means that the search engine can request, crawl, and index it immediately. SSR can be achieved with Next.js, Angular Universal, and others.

Keep in mind that not all search engine bots today can run JavaScript effectively to properly index a SPA without Server-Side rendering (SSR).

Let's take a brief look at the traditional rendering approach of SPAs called Client-Side > Rendering (CSR) and then compare it with Server-Side Rendering (SSR).

Client-Side Rendering (CSR) steps

Here are the steps taken when a SPA is rendered on the Client-Side.

1. User's browser sends a request to a URL.
2. Browser receives the index.html file from the server as a response.
3. Browser sends requests to download any remote links or scripts.
4. Browser waits for any scripts to be downloaded.
5. Browser makes any API requests via AJAX to fetch a site's dynamic content and processes it.
6. SPA library/framework renders the component passed to it and its content in the client's browser.

Because of the fetching and processing data on the Client-Side, this form of rendering is called Client-Side Rendering. Until the above piece of code executes, the user will just see a blank screen. This is not a problem but can be frustrating when a web server is experiencing latency or for users with a slower internet connection.

Server-Side Rendering (SSR) steps

Here are the steps taken when a SPA is rendered on the Server-Side.

1. User's browser sends a request to a URL.
2. A node server responds by running code that rendering the requested component into a string.
3. The rendered component is injected into index.html.
4. The index.html file is sent back to the browser.
5. The browser renders the index.html file and downloads all the site's dependencies.
6. Once all the site's scripts are loaded, the component is rendered to the DOM of the client's browser and any needed event handlers are added.

This type of rendering is called Server-Side because all the work of getting dynamic content, converting it to HTML, and sending it to the browser is done on the server. SSR renders the complete HTML in advance. This uses memory and processing power on the server. This can increases page load times compared to Client-Side Rendering.