Most modern websites are now "single page application" (SPA). That means they are "rendered" once by the client and then only updated when something is modified.
The biggest impact of performance when loading a website is the static data that is delivered with each website: html, css, images, fonts. In the SPA model, these static resources are only sent once and then, with each new information the client gets from the server, it adjusts the html accordingly.

Server side rendering
This concept has lost traction in the past 5-6 years, but technology tends to repeat itself (React SSR). Server side rendering means that the whole information is generated on the server and sent to the client "as is". The client will not have to run any kind of scripts, it will just "show" the information from the server as it received it.
By definition an "application" is a piece of software that has an interface that someone can interact with. In the case of server side rendered you can think as the "application" lives only on the server and the client (usually a browser) is only used to display the interface.
Server side rendering has a great advantage SEO-wise. Crawlers will be able to get more information from server side rendered websites due to the fact that all data is provided by the server, thus not being dependent on actions performed by a user.
Let's take an example to better understand this. Imagine we have a list of Frequently Asked Questions. When the user clicks one of those questions a section will appear below the question with the answer to the question.

In the example above the server will return the whole web page in the case of server side rendering. That includes: questions header, question 1, question 2, question 3, section of question 1, css, javascript, fonts. Due to browser caching some of these resources will not actually be retrieved again from the server, thus saving some load time and some web traffic.
Single page applications
You may have noticed I'm putting these two concepts on the opposite site of the spectrum. Yet only one has the word "application" in it. I mentioned before that the application "lives" on the server in the case of server side rendered. Single page applications use a different approach: the application lives both on the client and on the server.
When first loading the application the server will provide more than just an html that needs to be displayed. It will also provide an "application" that will be run on the browser. This makes the initial load a lot heavier but the following actions are optimised to use as little resources as possible. The most common way of accomplishing this in complex applications (that need a backend service) is through REST APIs: client submits a request and the server responds with a thin data structure (usually json). No html, css, javascript files are exchanged in the request, thus making things smoother.
Going back at the above example, after the client submits the request (clicks the first question) the server will only respond with the answer to the request, something like:
{ "question":{ "title":"How to do something", "id":1, "article":"just start doing it Lorem ipsum dolor sit amet" } }
The application will then parse the response and include it in the current page dynamically.
Implications
- Search engine optimisation (SEO)
- Load times
- Development knowledge (frontend/backend)
- Infrastructure
- And more :)
Anything else?
There are actually a lot of other subjects that derive from this: dynamic content (different based on client - like facebook), static content (same for everyone, like a landing page or this blog), lazy loading for resources (pulling dependencies only when they are needed thus minimizing initial load time for SPAs), server caching (all kinds of headers that tell the browser what to cache and for how long) etc.
Article Series
- Tech in Layman's terms
- Client Server Model
- Server sider rendered vs Single Page Application