{"id":25,"date":"2021-11-28T06:25:30","date_gmt":"2021-11-28T06:25:30","guid":{"rendered":"https:\/\/techwyns.com\/tech\/blog\/2021\/11\/28\/types-of-ip-address-and-its-requirements\/"},"modified":"2021-12-31T01:05:33","modified_gmt":"2021-12-31T01:05:33","slug":"types-of-ip-address-and-its-requirements","status":"publish","type":"post","link":"https:\/\/techwyns.com\/tech\/blog\/2021\/11\/28\/types-of-ip-address-and-its-requirements\/","title":{"rendered":"client-side-vs-server-side-pre-rendering"},"content":{"rendered":"\r\n\r\n\r\n\r\n\r\n

There’s no question that user experience is impacted by perceived load times. With today’s heavier front ends, client-side rendering doesn’t feel very fast. In this article, TechWyns Freelance Front-end Developer Matthew roberts compares client-side, server-side, and pre-rendering strategies to help you choose the best option for your own app.<\/p>\r\n

 <\/p>\r\n

There is something going on within the\u00a0front-end<\/a>\u00a0community recently. Server-side rendering is getting more and more traction thanks to React and its built-in server-side hydration feature. But it\u2019s not the only solution to deliver a fast experience to the user with a super fast time-to-first-byte (TTFB) score: Pre-rendering is also a pretty good strategy. What\u2019s the difference between these solutions and a fully client-rendered application?<\/p>\r\n

Client-rendered Application<\/h2>\r\n

Since frameworks like Angular, Ember.js, and Backbone exists, front-end developers have tended to render everything client-side. Thanks to Google and its ability to \u201cread\u201d JavaScript, it works pretty well, and it\u2019s even SEO friendly.<\/p>\r\n

With a client-side rendering solution, you redirect the request to a single HTML file and the server will deliver it without any content (or with a loading screen) until you fetch all the JavaScript and let the browser compile everything before rendering the content.<\/p>\r\n

Under a good and reliable internet connection, it\u2019s pretty fast and works well. But it can be a lot better, and it doesn\u2019t have to be difficult to make it that way. That\u2019s what we will see in the following sections.<\/p>\r\n

Server-side Rendering (SSR)<\/h2>\r\n

An SSR solution is something we used to do a lot, many years ago, but tend to forget in favor of a client-side rendering solution.<\/p>\r\n

With\u00a0old<\/strong>\u00a0server-side rendering solutions, you built a web page\u2014with PHP for example\u2014the server compiled everything, included the data, and delivered a fully populated HTML page to the client. It was fast and effective.<\/p>\r\n

But\u2026<\/strong>\u00a0every time you navigated to another route, the server had to do the work all over again: Get the PHP file, compile it, and deliver the HTML, with all the CSS and JS delaying the page load to a few hundred ms or even whole seconds.<\/p>\r\n

What if you could do the first page load with the SSR solution, and then use a framework to do dynamic routing with AJAX, fetching only the necessary data?<\/p>\r\n

This is why SSR is getting more and more traction within the community because React popularized this problem with an easy-to-use solution: The\u00a0RenderToString<\/code><\/a>\u00a0method.<\/p>\r\n

This new kind of web application is called a\u00a0universal app<\/em>\u00a0or an\u00a0isomorphic app<\/em>. There\u2019s still some controversy over the exact meanings of these terms and the relationship between them, but many people use them interchangeably.<\/p>\r\n

Anyway, the advantage of this solution is being able to develop an app server-side and client-side with the same code and deliver a really fast experience to the user with custom data. The disadvantage is that you need to run a server.<\/p>\r\n

SSR is used to fetch data and pre-populate a page with custom content, leveraging the server\u2019s reliable internet connection. That is, the server\u2019s own internet connection is better than that of a user with\u00a0lie-fi<\/a>), so it\u2019s able to prefetch and amalgamate data before delivering it to the user.<\/p>\r\n

With the pre-populated data, using an SSR app can also fix an issue that client-rendered apps have with social sharing and the OpenGraph system. For example, if you have only one\u00a0index.html<\/code>\u00a0file to deliver to the client, they will only have one type of metadata\u2014most likely your homepage metadata. This won\u2019t be contextualized when you want to share a different route, so none of your routes will be shown on other sites with their proper user content (description and preview picture) that users would want to share with the world.<\/p>\r\n

Pre-rendering<\/h2>\r\n

The mandatory server for a universal app can be a deterrent for some and may be overkill for a small application. This is why pre-rendering can be a really nice alternative.<\/p>\r\n

I discovered this solution with\u00a0Preact<\/a>\u00a0and its own CLI that allows you to compile all pre-selected routes so you can store a fully populated HTML file to a\u00a0static<\/em>\u00a0server. This lets you deliver a super-fast experience to the user, thanks to the Preact\/React hydration function, without the need for Node.js.<\/p>\r\n

The catch is, because this isn\u2019t SSR, you don\u2019t have user-specific data to show at this point\u2014it\u2019s just a static (and somewhat generic) file sent directly on the first request, as-is. So if you have user-specific data, here is where you can integrate a beautifully designed skeleton to show the user their data is coming, to avoid some frustration on their part:<\/p>\r\n

 <\/p>\r\n

\"Using<\/figure>\r\n

 <\/p>\r\n

There is another catch: In order for this technique to work, you still need to have a proxy or something to redirect the user to the right file.<\/p>\r\n

Why?<\/h3>\r\n

With a single-page application, you need to redirect all requests to the root file, and then the framework redirects the user with its built-in routing system. So the first page load is always the same root file.<\/p>\r\n

In order for a pre-rendering solution to work, you need to tell your proxy that some routes need specific files and not always the root\u00a0index.html<\/code>\u00a0file.<\/p>\r\n

For example, say you have four routes (\/<\/code>,\u00a0\/about<\/code>,\u00a0\/jobs<\/code>, and\u00a0blog<\/code>) and all of them have different layouts. You need four different HTML files to deliver the skeleton to the user that will then let\u00a0React<\/a>\/Preact\/etc. rehydrate it with data. So if you redirect all those routes to the root\u00a0index.html<\/code>\u00a0file, the page will have an unpleasant, glitchy feel during loading, whereby the user will see the skeleton of the wrong page until it finishes loading and replaces the layout. For example, the user might see a homepage skeleton with only one column, when they had asked for a different page with a Pinterest-like gallery.<\/p>\r\n

The solution is to tell your proxy that each of those four routes needs a specific file:<\/p>\r\n