a key element of the site that requires special attention
Today we’ll talk about SSR – what it is, why use it, how to work with it so that everything works out.
What is SSR?
SSR is Server Side Rendering, that is, page generation on the server side, and not in the browser, when the server sends already generated HTML.
Any website page or the simplest web version of an application is HTML code that is displayed in the browser as a set of visual elements – text blocks, images, links and buttons. Rendering is the assembly of html code for the user’s browser, from code blocks of the source vue file. This happens when we go to the site – that is, we send a request to the server, and from it we receive the js code of the vue application, html with empty spaces into which the content will be rendered on the user’s side. And, of course, we would like this to happen instantly.
Displaying a site in a browser with HTML already generated takes less time than when the code is generated in the browser, expending additional user resources. This is especially noticeable on slow Internet or on devices with full memory.
That's what SSR is for. With this method, the entire HTML code of the page is generated on the server and sent to the user's browser.
What kind of pain does the SSR method solve?
Firstly, the performance of this method is much higher – the server’s power greatly exceeds that of the receiving side, which means there will be no need to render the page on the client side before displaying it.
Secondly, such content has better SEO optimization. The page generated on the server already contains all the text, and search engines can immediately index it correctly and raise it to the top of relevant results. If the site is generated on the user's side, the search robot will not see this content.
What potential problems may arise when working with SSR?
The frontender writes code using the Vue framework; its files contain HTML markup, JS – site functions and styles. These blocks are used to assemble the appearance of website elements or entire pages. When deploying a site’s code to production or on stage, it is built automatically, and if you make an error in the Vue file, the code generation will be disrupted – during deployment, site elements may “fall off,” the entire layout may be damaged, and the structure of how buttons and links will work. This will not only prevent the user from seeing the desired content, but will also make the site inaccessible to search robots.
It is also important to consider which script in Vue.js functions on the user side (i.e. browser) and which functions on the server side. There are certain methods that can only be called on the user side. If we try to call them on the server side, this can also lead to an error – and on the deployment, everything will also go awry, and the build will not be built.
The difference in how scripts work on the server side and on the browser side is important to consider when designing architectural solutions. At each stage of the code life cycle, you need to monitor the correct execution; you should pay especially close attention to this at the stages:
beforeCreate
created
beforeMount
mounted
beforeUpdate
updated
activated
deactivated
beforeDestroy
destroyed
It is necessary to think through the code structure in advance so that scripts that are called only on the front (in the browser) are not called on the backend. This must be taken into account not only at the development stage, but also at the stage of review and implementation of improvements – even if visually the code looks working, if the logic for separating scripts is not followed, errors may appear. For example, if you mistakenly access the window object in a hook in which it is not available, for example mounted, this will lead to the collapse of the application's vue file, which will ultimately destroy the entire SSR.
There is another potential problem – it can arise when we receive any data from the back to the front. If some kind of error has crept into the backend, then the SSR will not work correctly. In this case, the page may be displayed normally and seem the same, but rendering will not occur on the server – everything will be taken over by the browser.
Basic principles of working with SSR so that everything goes well
Considering the fatality of a possible mistake made in the logic of the Vue file or in the data from the back, working with SSR requires meticulous testing at all stages – code review, check-ups after any modifications, stage testing and even regression testing.
It is very important after each deployment to check how correctly the SSR works. This can be done using an autotest, or you can disable the execution of js code on the page and try to open it. With this solution, the result should be to see only those parts of the front that were planned, and not the entire site. If this does not happen, then the SSR is not working. It is very important to catch this after release – if you make a mistake, even though the page seems to work correctly, search engines will not find it, since the page will be rendered on the user’s side.
Another important point is experienced developers. Not all front-end developers have experience working with SSR, and this must also be taken into account – the more experience a developer has working with rendering on a server, the more correctly he will create a Vue file. We definitely pay attention to the presence of such a skill when hiring new employees; this is super important for us.
