.svg)
Almost every site you see on the modern web uses Javascript. Javascript makes sites interactive, personalizable, and provides a much richer user experience than just plain HTML. However, Javascript tends to make pages slower, because of extra code and resources it requires to load. As your website grows in size, the amount of Javascript code, its complexity and dependencies grow as well. This can result in poor performance, a sluggish website, and a poor user experience.
By default, web pages load and execute Javascript in your browser. This is called client-side rendering. An alternative to that is server-side rendering (SSR), which executes Javascript on the server and then sends a flat HTML response to the browser.
SSR removes the need to load and process Javascript in the browser, and improves certain performance metrics, such as First Paint and First Contentful Paint. However, it does not magically make pages lighting fast: generating pages on the server takes time, which can often result in a slower Time to First Byte (TTFB).
How Do I Know If My Site Should Use SSR or Client-Side Rendering?
Most Javascript frameworks (Angular, Vue, React, etc.) support SSR. However, just because SSR is available doesn't mean that it is best for your website.
For small to medium sites or sites that focus primarily on content, adopting and using an SSR solution is fairly easy. On the other hand, large enterprise applications struggle with figuring out how to execute SSR in a cost-effective way.
The biggest hurdles developers face with SSR revolve around complexity. Some common issues include:
- Lots of moving parts: large websites tend to use complex codebases that were cobbled together and evolved over time. That's why rolling out SSR can be almost as difficult as completely rebuilding from scratch.
- Resource allocation: adding SSR to a site takes months and requires significant investment from engineering teams. This could mean that they won't be able to focus on adding features, or work on existing technical debt, or push out any new projects.
- Lack of documentation and unified approach: large companies like AirBnB with a massive pool of engineering resources can afford to invest in building their own SSR solutions. Lean teams or teams working with lots of legacy code will find it much harder.
- Ongoing support: even if you build and launch your SSR application, you are not done. With new site updates, you would have to make sure SSR is still working as intended and fix any potential issues introduced with new releases.
- Measuring impact: is it worth investing in this? How will I measure differences in performance and tie them to impact on business, visits, and revenue? It's hard to get buy-in for building an SSR solution without knowing whether it will pay off.
For a lot of companies and engineering teams SSR is still a massive undertaking, and it's hard to decide whether it is worth doing.
We at Botify built a solution that addresses SEO performance issues, using dynamic rendering, quality control and caching. It's called Speedworkers.
Dynamic Rendering: Taking care of bots
Similar to server-side rendering, dynamic rendering will pre-render and serve flat HTML content only to search bots.
This is an enormous benefit for SEO for many reasons:
- Bots can crawl your content faster, so your crawl budget increases
- They can get to pages they have not seen before, improving indexation
- They can crawl your content more efficiently and more often, resulting in fresher content in the index
- All of your important content is visible to bots, including content that is usually rendered via Javascript.
At the same time, nothing changes for your end users: they are getting the same content with Javascript enabled in the browser. Of course, it's best to optimize load time for users as well, but it's a much easier task than balancing SSR and CSR.
Using dynamic rendering and SpeedWorkers, we remove all the complexity and need for SSR. This is because our solution involves:
- No moving parts: we set up SpeedWorkers on a CDN level without even touching your website
- No worrying about allocating resources: let your technical teams focus on important projects
- No need to read documentation: we know dynamic rendering is approved and recommended by Google and Bing
- No additional support: it's a fairly turnkey solution, we run and maintain it
- We measure impact via SiteAnalytics, monitor performance via SpeedWorkers dashboard and provide you with reports.
SpeedWorkers also saves you on infrastructure costs, because a huge chunk of bot traffic is now taken on by SpeedWorkers, instead of your servers.
Results you can expect
SpeedWorkers' target delivery time for bots is under 300ms. On top of that, our cache efficiency usually results in even higher speed gains.
Right after launching SpeedWorkers, you can expect an increase in page delivery speed. As pages get faster, bots start crawling your site more efficiently, getting to more content.
Crawl rate of strategic pages will also increase, because search bots will get deeper and wider into your site structure. If you're an E-Commerce site, and improve crawl ratio of product detail pages, there's a great chance these pages will get indexed and ranked. As a result, more of your product inventory will be visible to users.
Another benefit of improved speed will be an increase in active pages that drive organic traffic.
Finally, the more pages get indexed, ranked and receive clicks, the more incremental revenue they can produce.
These are pure SEO benefits. We also know that SpeedWorkers eliminates the need to invest in engineering resources, and saves in infrastructure costs, because all of the traffic from bots is going to SpeedWorkers, instead of your servers. We host and maintain it, so you don't have to worry.
SSR has definite benefits over CSR. However, SSR can be complex, confusing and costly. Dynamic rendering is a great alternative for SEO - get in touch for a free custom demo of SpeedWorkers, and visualize the benefits for your website.
-------
Resources:
https://developers.google.com/web/updates/2019/02/rendering-on-the-web
https://github.com/airbnb/hypernova
https://www.moovweb.com/post/server-side-rendering-ecommerce-react-website
.svg)
.svg)
.svg)
