I use third-party JavaScript grid control. The matter is, it renders completely on client side and takes much time for this (creating DOM and corresponding JS objects). It can be normal for PC, but completely bad for mobile browsers like iPad's Safari (for about 1 minute rendering time). I apply many different optimization tricks, but the main problem is grid's rendering time.
So, I wonder, is there any ability to perform rendering of HTML page on server side and return to the client completed page with JS objects?
By another words, I need to launch web page on server side, get the resulted DOM and JS objects and return this to client, like it was performed on client browser.
So, I wonder, is there any ability to perform rendering of HTML page on server side and return to the client completed page with JS objects?
No. You can produce either HTML or JavaScript on server side, but the actual execution of the JavaScript and rendering of the control is not a task you can delegate to the server.
I don't know what is causing the actual performance issue, but you may want to look into paginating your results on server side so the client needs to render only one pageful at a time.
Related
I have been working on a project, where I'm making AJAX call to load 100's of record from database, which would then be rendered on a slider.
To be precise, the data I would be fetching is the 'Image Path' for all the images, and other details such as 'the size of slider thumbnail', 'number of thumbnails to show', etc.
For this list of data, I have 2 options:
1. To generate the HTML on the server-side and send it to client, where it will be applied to the slider.
2. To generate and send json data to client. Parsing this json data and generating the Slides for the Slider.
I'm confused as to which approach to use, for better overall performance for client/server. Google search and reading articles states me that using json data is a faster. However, after performing few initial test to fetch and render HTML shows that generating HTML on server side and sending it to client for rendering is much faster than sending the json data to the client and preparing the HTML for rendering.
It would be great if someone would put a light on this issue, where the server gets about 4k-5k hits per hour.
There's a lot of really great discussion around this topic, however I tend to side with client side rendering. My reasoning is 1. If your server is getting hit very often, server side rendering slows down the response time of your server and can cause really long queue times, and 2. Because you're making the request separately from your markup and styling, you can have a splash page or some waiting animation on the user side as opposed to having them sit at a white screen while your server is compiling everything. This is just my opinion, but I've found client side rendering to provide the best UX as well as offloading computations from your web server is often a good idea
I like the answer on this link.
A Short Description what it is about (Copy-Paste):
I'm a bit on both sides, actually :
When what I need on the javascript side is data, I use JSON
When what I need on the javascript side is presentation on which I will not do any calculation, I generally use HTML
The main advantage of using HTML is when you want to replace a full
portion of your page with what comes back from the Ajax request :
Re-building a portion of page in JS is (quite) hard
You probably already have some templating engine on the server side, that was used to generate the page in the first place... Why not
reuse it ?
I generally don't really take into consideration the "performance"
side of things, at least on the server :
On the server, generating a portion of HTML or some JSON won't probably make that much of a difference
About the size of the stuff that goes through the network : well, you probably don't use hundreds of KB of data/html... Using gzip on
whatever you are transferring is what's going to make the biggest
difference (not choosing between HTML and JSON)
One thing that could be taken into consideration, though, is what resources you'll need on the client to recreate the HTML (or the DOM
structure) from the JSON data... compare that to pushing a portion of
HTML into the page ;-)
I have just learned react recently and intend to use it for my next project. I have come across react server side rendering for a few times, but wonders why do we still need it in "modern age".
In this article, it argues that with server side rendering, user does not have to wait to load those js from CDN or somewhere to see the initial static page, and the page will resume functionality when js arrives.
But after building with webpack production configuration, and gzip, the whole bundle (with react, my code and a lot other stuff) only takes 40kb, and I have aws CDN for it. I don't quite see the reason to use server side rendering for my situation.
So the question is why people still use server side rendering if the resulting javascript bundle is so tiny after gzip?
Load Times
A rendered view of the application can be delivered in the response of the initial HTTP request. In a traditional single page web app, the first request would come back, the browser would parse the HTML, then make subsequent requests for the scripts — which would eventually render the page. Those requests will still happen, but they won't ever get in the way of the user seeing the initial data.
This doesn't make much difference on quick internet connections, but for users on mobiles in low network coverage areas, this initial rendering of data can make apps render 20-30 seconds faster.
Views with static data can also be cached at a network level, meaning that a rendered view of a React application can be served with very little computational overhead
SEO
When a search engine crawler arrives at a web page, the HTML is served and the static content is inspected and indexed. In a purely client side Javascript application, there is no static content. It is all created and injected dynamically once the appropriate scripts load and run.
Unlike React, most frameworks have no way of serialising their component graph to HTML and then reinflating it. They have to use a more convoluted approach, which often involves rendering their page in a headless browser at the server, then serving up that version whenever a crawler requests it.
React can just render the component tree to a HTML string from a server side JS environment such as Node.js, then serve that straight away. No need for headless browsers or extra complications.
Noscript
It also allows you to write applications which gracefully degrade and ultimately, can be used as thin clients. This means that the processing goes on at the server and the application can be used in a browser with Javascript disabled. Whether or not that's an important market to consider is a debate for another time.
All-or-none rendering
This is a UX concern, some designers decide they don't like incremental rendering. The designer wants the page to show up complete and perfect, without the loading spinner, insertion of fetched text here and there, and displacement of layout.
Scroll bar restoration is a difficult issue for client side rendering. See Keep scroll position when navigating back (When navigating forward and then back, the scroll position is lost). Server side rendering does not suffer from this issue.
I think if you're chasing SEO will better rendered on server.
so all contents will read by bot SEO.
In addition to SEO mentioned above, with SSR browser could present the page right away even before all Java Script files are loaded. I have a tutorial explaining this.
Some javascript frameworks like Dust.js claim that they ALSO support server-side rendering (in addition to client side rendering) as well. Can someone explain how does this work? My understanding is that the JS is always executed in the browser runtime.
JavaScript can be run on servers using systems like Node.js.
With regard to Dust.js, a templating engine, it can generate hypertext and HTML on the server and send that content directly to the client's browser. This is typically used to avoid a flash of temporarily empty templates, caused by the browser requiring a split second to populate a view's templates via a framework like Dust.js. The downside is that the page will take slightly longer to load because more work has to be done on the server before sending data to the client.
Check out this question for the pros and cons of server-side rending. One must choose between slow post-processing (requiring the user's browser to do the work) or slow pre-processing (making the server do the work before the user sees anything).
Server side rendering is converting JavaScript into static html and css.
Earlier JS tended to load last to optimise website performance.
But the problem was it affected SEO.
So server side rendering became the solution to resolve this issue.
The 3 main renders methods are:
Client Side Rendering (CSR)
Is the default rendering process of modern frontend frameworks like ReactJS, the server just returns an almost empty index.html file, and then the user browser using Javascript loads and builds everything.
Server Side Rendering (SSR):
Refers to the process of generating in the server, the HTML content, on-demand for each request.
Usually, you’ll accomplish this by setting up a server running something like Express or Next.js (which use NodeJS) that renders your React app with each request — just as with a more traditional PHP or Rails based website.
Static Site Generator (SSG):
Both Server Side Rendering and Static Site Generator involve generating HTML for each of your site’s URLs. The difference is that Static rendering happens once at build time, while server rendering happens on-demand, as the user requests each file.
With static rendering, you need to generate responses for every possible request ahead of time. But what if you’re building something where you can’t predict all possible requests, like a search page? Or what if you have a lot of user generated content, and the response changes on every request? In that case, you’ll need Server Side Rendering.
*** So which should you use? ***
It depends.
if SEO is irrelevant — e.g. an app that lives behind a login screen — then CSR is fine and you just need something like ReactJS
If you need a good SEO:
a) If you can predict the content (to generate it in build time) then you need SSG and should choose something like NextJS
b) If you can’t predict the content/possible request, the server will need to generate the pages on demand, so you need SSR and should choose something like NextJS.
Note: NextJS allows you to selectively mix in the same project the 3 main rendering forms. They are also other good solutions like Gatsby on the market.
Server-Side Rendering (SSR) is executing JavaScript [SPA application] on the server-side.
Opposite to Client-Side Rendering when JavaScript is executed on the client-side.
Server-Side Rendering is a relatively new technology/therm that allows SPA frameworks like React or Angular to become more SEO-friendly.
Technology is rather inefficient, because of additional work put on the server.
Instead, of creating SPA (single-page application) and then executing it on the server, someone should consider creating the multi-page application in the first place.
SSR term is somehow ambiguous and confusing as some people use it referring to traditional multi-page websites like those built on Wordpress, for example, or any PHP or Java backends where HTML pages are generated by the server, and some use it only for SPA rendered on the server.
The latter, IMHO, is "more correct" as it produces less confusion.
I am working on a large web site, and we're moving a lot of functionality to the client side (Require.js, Backbone and Handlebars stack). There are even discussions about possibly moving all rendering to the client side.
But reading some articles, especially ones about Twitter moving away from client side rendering, which mention that server side is faster / more reliable, I begin to have questions. I don't understand how rendering fairly simple HTML widgets in JS from JSON and templates is a contemporary browser on a dual core CPU with 4-8 GB RAM is any slower than making dozens of includes in your server side app. Are there any actual real life benchmarking figures regarding this?
Also, it seems like parsing HTML templates by server side templating engines can't be any faster than rendering same HTML code from a Handlebars template, especially if this is a precomp JS function?
There are many reasons:
JavaScript is interpreted language and is slower than server side
(usually done in compiled language)
DOM manipulation is slow, and if you are manipulating it in JS it
results in poor performance. There are ways to overcome this like
preparing your rendering in text then evaluating it, this might in fact gets you as close to server side rendering.
Some browsers are just too slow, especially old IE
Performance of compiled language versus interpreted javascript
Caching, ie - serving up the exact same page another user has already requested, this removes the need for each client to render it. Great for sites with huge traffic - ie news sites. Micro-caching can even provide near real-time updates, yet serve significant traffic from the cache. No need to wait for client rendering
Less reliance on users with old computers or slow / crippled browsers
Only need to worry about rendering, less reliance on how different browsers manage DOM (reliability)
But for a complex UI, client side rendering of interactions will provide a snappier user experience.
It really depends on what performance you're trying to optimise, and for how many users.
To run code on the client side it first has to be loaded. Server side code is just loaded when the server start, whereas the client code must potentially be loaded every time the page is. In any case the code must be interpreted when loading the page, even if the file is already cached. You might also have caching of JS parse trees in the browser, but I think those are not persisted, so they won't live long.
This means that no matter how fast JavaScript is (and it is quite fast) work has to be performed while the user waits. Many studies have shown that page loading time greatly affects the users perception of the sites quality and relevance.
Bottom line is that you have 500ms at the most to get your page rendered from a clean cache on your typical developer environment. Slower devices and networks will make that lag just barely acceptable to most users.
So you probably have 50-100ms to do things in JavaScript during page load, all of it, grand total, which means that rendering a complex page, well, not easy.
I'm calling a webservice currently from the backend. However, the page is taking a while to load and I'm starting to wonder, will the page load faster (in a perceived way) if I use javascript to load the data instead of the backend?
Basically will using a REST service to load the data on the client side make the page load seem faster than loading the data on the backend with a SOAP call? Does page_load fire first or the javascript calls?
In terms of the difference between calling a SOAP service on the backend vs. calling a REST/JSON service on the front end - your page load times may be percieved as faster if you let the frame of the page load, and display a "spinner" when you load the data from a REST service.
Your question is a bit ambiguous since it's not clear that's what you're asking.
Well, REST vs. SOAP isn't really a comparison anyone can make in terms of speed/performance on a website. REST refers to a conceptual semantic model of how to make calls to a service. SOAP, on the other hand, refers to both the semantics of the call, as well as the data format. REST, by comparison, says nothing about the data format (although JSON is typically assumed - but nothing about REST precludes XML or any other data format).
JSON vs. SOAP, however, is a different story.
JSON responses will be easier / faster to parse on the client side than SOAP messages will (assuming you're using standard javascript stuff which works cross-platform, and no fancy plugins).
Load time? SOAP is a LOT more verbose than JSON, and requires additional characters to transmit the same values... so maybe a small delay due to the relative sizes of the messages being sent.
Processing time on the client side? JSON definitely has the edge.
Ease of use on the client? JSON - hands down.
I see this question not as much as a comparison between REST and SOAP, but rather a question about where the service should be called - backend or frontend. Backend code always executes first, before any frontend code, by definition - it just sits on the server, and runs before the response is returned. The javascript runs after the response is returned and the page is loaded.
Steve gave a very good overview, but it doesn't talk at all about backend v.s frontend. Generally speaking there will be no difference in performance or at least no difference that can be predicted. It all depends on the server condifuration and client computers (where the Javascript executes).
The difference (as Steve also mentioned) is in perceived performance. Here, I would always recommend that you call services from the frontend. There are a couple of reasons:
You can display a visual indicator before you call the service to inform the user of the lengthy operation
You can do a partial update of the UI on each next call to the service. If you call the service in the backend, you would have to essentially do a postback (go through the whole lifecycle of your ASP.NET page). This is slow and not visually appealing.
Actually if you are calling a service from the backend I see no point in having a service at all (assuming it only returns data to bind to the UI). You can just use the old Webforms way to construct the UI and return the response directly in your ASP.NET page.
As a conclusion - many of the benefits of web services come when you call them from client script.
Without looking in your code i cant realy say whats wrong/ why is site loading not fast enough.
REST and SOAP are definied standarts for comuniation between client and server.
I prefer REST over SOAP.
The direct answer for your question is: Page_Load event will load before your Javascript background calls. I recommend using javascript with background loading when your page has several web controls that load too much data, draw elements or doing heavy calculations that take much time and affect the user experience and application performance. You need to give the user the ability to load the page and seeing the progress of each element loading (so that he don't get bored while browsing). REST calls with JSON is recommended for this case.