技术控

    今日:67| 主题:49157
收藏本版 (1)
最新软件应用技术尽在掌握

[其他] React.Js: Achieving 20ms server response time with Server Side Rendering

[复制链接]
梦&冰蝴蝶 发表于 2016-10-18 13:32:07
111 0

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
We all love ReactJs for it’s rendering performance, modularity and the freedom it gives to choose your stack. But there is one thing that makes it stand out. Server side rendering . Before React, most of the javascript frameworks focused on building Single Page Applications and did a pretty great job at it. But now it’s 2016, the era of Hybrid Apps! Apps that can run beyond browser environment . React has started a trend by supporting server side rendering, which enables us to build end-to-end javascript apps.
   Little Background

         
React.Js: Achieving 20ms server response time with Server Side Rendering-1 (javascript,supporting,currently,anything,blogging)
        I am currently working on Practo’s Healthfeed , a place where doctors and health specialists write health articles and share their expertise. If not anything else, any blogging platform needs to be good at ONE thing the most: the SEO . Any blog with good SEO is destined to get more readers than anyone else. And more readers means more SEO !
  To get better SEO you have to do a lot of things right. But here we’ll only talk the most important two, the most fundamentals for good SEO:
  
       
  • Making your site crawlable for bots .   
  • Make it FAST . Like Millennium Falcon fast !  
   Enters React !

   When React came out, one of it’s selling point was that it supported Server Side Rendering (SSR). To make your app support SSR, All you need is a node server and an API . The modern architecture looks something like this:

React.Js: Achieving 20ms server response time with Server Side Rendering-2 (javascript,supporting,currently,anything,blogging)
       Notice ! The node server acts as a mediate person between the user and the API server. So the Flow goes like this:
  
       
  • User hits the URL, Request goes to the Node Server .   
  • Node Server makes request to the API Server and takes the data from the API server.   
  • Pushes the data to the APP , which in return creates the final HTML for the user.   
  • Returns the HTML string back to the user.  
   Now the whole setup is done ! Server is taking requests, API is giving response and finally user/bots are getting a fully rendered HTML page. But this can turn out to be a user’s nightmare .
   Issues !

  
       
  • What is API server is slow ! Like 500ms response time.  
  One problem with the server side rendering is that it’s response time relies heavily on the API server’s response time. That means, no matter how efficient and fast app you’ve made, the user will see the white screen for atleast 500ms, provided your node server has 0 ms response time. Which is practically impossible (for now).
  So let’s see the breakdown here:
  
       
  • 500 ms response time from API   
  • 150 ms for server side rendering (yes, it takes that much)   
  • 10 ms for node server   
  • 150 ms network latency  
   So a user will get response after almost 810ms ! Now, of course these are just average numbers, but in real world, it can be lot worse. Since we don’t have much control over the network latency, we’ll keep that out. So the server response time is currently at 660 ms .
  To improve the situation, we’ll first catch the biggest fish: API response time.
   Enters Redis !

   Redis is one of the most powerful data-structure store, which is super fast and efficient. You can store anything in there as key value pairs. Integrating redis to store the node environment is super easy. If we store the API result in the redis , we can save our network trip to the API server.
  So now, whenever the user makes some request, the node server will query the Redis if it already has the response. If it has, it’ll directly pass it to the app for rendering and finally return the HTML string. If it doesn’t have the response, we’ll go ahead and call the API and now store this result in the redis before passing it to the app.
  The new breakdown will be:
  
       
  • 150 ms for server side rendering   
  • 5ms for the redis server (NOTE: The rendering time might be less or very high, depending upon your application size.)   
  • 10 ms for node server  
   With just caching our API responses, we have dropped down from 660 ms to 160 ms .
   Squeeze More !

  Although 160 ms is good, we can get more by just a small trick.
  Instead of storing the API response in redis, why not store the whole HTML string itself ?

  and this was the result !
12下一页
友荐云推荐




上一篇:Week of Celebration as Scrum Turns 21
下一篇:RecyclerView 加载更多与 CoordinatorLayout
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表