A pleasant user experience requires a page to load very fast. This can be difficult when there is a large query taking place or when a web service is being used.
I deally, the entire page should be loaded first with loading images everywhere a cumbersome task takes place.
In ASP.NET, this can be accomplished using update panels and a 1 second trigger. The trigger would load some data and then the updatepanel will the update. This approach may be less popular if you do not require entire asp.net page life cycle events to fire. With this approach, allot of methods will fire consuming more resources and time. What if you simply want to display data?
Another aproach would be to create an .ashx httphandler that returns a representation of data in html format. A timer would go off one second after the page loads which triggers a div panel to be populated with the html returned from the .ashx handler. This would bring high performance but you would lose postbacks and viewstate. I suppose that is expected when losing the asp.net page-life cycle.
How would you go about creating a delayed task that uses viewstate and postback if possible that brings great performance?
Maybe creating an http handler to a custom extension, and in the implementation of the handler return the data (or pre-formatted html, json, or xml) that you then insert into an html element of the container page with a javascript ajax call.
Hugo
Related
I have a JSF page with PrimeFaces 5.1 and I'm experiencing performance issues in a complex page. The page has a common design: a paginated datatable, a tree for filtering, a panel with the selected item details and a menu with some actions on that item. The majority of these components are provided by PrimeFaces.
Profiling the application, I concluded that the DB queries are not the bottleneck but rather the restore view and render response phases. Moreover, the major factor in the delay seems to be the number of JSF components as opposed to the amount of data stored in the backing bean. Even AJAX requests with partial processing and rendering will take time in those phases.
How can I reduce the processing time, specially in the AJAX requests?
My 'short list':
Use a recent version of your JSF library (especialy Mojarra > 2.1.21)
Use partial processing (process="#this") (already mentioned by you)
Don't use validation on ajax requests (immediate=true)
Use partial submission (partial-submit="true")
Be selective in what you update (Not an #form)
Don't do any amount of work in a getter (and if you do, do it lazy)
Don't use inline editing in the datatable
Use native components in the datatable if you do cannot do 7
Don't use loooooooooong select lists
Use lazy loading for filtering, sorting and paging in datatables and use a page size value that is moderate (tnx #Vrushank, I forgot this)
Don't use partial state saving in Mojarra with complex pages
I'm creating a pager for grid data. Basically, I can do it in two ways: when user clicks on a page number, load grid data by using ajax call, or, post back to server (GET or POST) and use query string parameters (or POST variables) to know which page to display. With both methods, sorting of grid items must be persisted.
What is better considering performance and SEO and why?
-- UPDATE --
I need pros and cons for both approaches. I know this is somewhat discussion rather than question, but I need your experiences.
Also, when using ajax, it is not only SEO that I'm wondering about. Will browser's back button behave as expected?
Why not do both.
Have the grid load with SEO friendly anchor GET links then implement some JavaScript to convert them to AJAX calls.
People without JavaScipt (like spiders) can then still navigate around while fancy people will get the enhanced AJAX experience.
With AJAX you can alter history and make the back button work as expected.
Your grids are loaded via AJAX? and you are worried that SEs won't pick them up?
What you can do to get your content indexed is to:
use segmented URLS like CodeIgniter and WordPress instead of query strings. SEs will (supposedly) see them as subfolders.
Instead of loading everything in AJAX, grid data can also be represented as tabular data. What you can do is to load the tabular format for the static page, then with JS, you can replace the table with your grid.
say for example i want to load sports stats, mysite.com/sports/stats should give me tabular data when JS is off, and if i had JS, that data is replaced with the grid.
I have a dropdown, that contains some list of StudentCode...
when user select any studentcode student data should be displayed in form with student's Image...
for displaying Student Image, Im putting student image in cache memory... and I have one Iframe that gets the byte data from cache memory and render that image on my page... problem is... this thing need at least 1 postback...
can I make some partial postback to render this image?
I see couple problems with the implementation.
1) You should avoid using IFrames in general as there are better ways of handling rendering parts of the webpage.
2) Storing images in cache means that you actually downloaded all of them for each Student in the dropdown list and placed them in the cache. What if there are 100 students? Getting images for all of them and storing them might take a lot of resources.
I suggest you to do the autopostback on dropdown selected value change (via ajax call) which calls a method that will return a partial view with all the information you need for the particular student, including the image.
I found using Ajaxify library (http://max.jsrhost.com/ajaxify/) very easy and convenient for ajax calls.
You can do the same thing without ajax at all in which case the whole page will reload with the same result.
If we have a page which executes Javascript upon loading, and this Javascript inserts new elements via AJAX, will this delay the time it takes for the DOM to be considered loaded?
Some of our UI only functions after the DOM is loaded (using jQuery's "ready" function), and we thought inserting page elements asynchronously via AJAX would load the DOM faster, increase perceived responsiveness, and allow users to interact with the page sooner. If this is right, we are doing something wrong.
Any thoughts?
Thanks!
If I understand what you're trying to do, you want to load the page and then load the content asynchronously. If you want to do this to improve perceived load speeds, run your ajax code from your $(function(){}); call, not before. This fires when the DOM has loaded, which means all the rest of your page (except what you're trying to load asynchronously) has loaded.
The effect the user will perceive is that the whole page except the content loads (I assume you'll have some sort of spinning image or something where your content is going to be loaded), then you make the call, then you remove the loading icon and insert your content.
I have a html table in my application that shows the state of various jobs running in the system. Each job has a state associated with it e.g a swirly gif for running jobs. New jobs have a checkbox next to them that allows the user to select and kick off the associated job.
The table is a struts2 auto refreshing div (sx:div), it refreshes every few seconds to reflect what is currently happening with the jobs.
The problem is that when the div refreshes I lose that state of the checkboxes.
Is there an elegant way of maintaining their state? I have the option of calling some javascript upon completion of the ajax refresh using the dojo topic system built into the tag but i'm not sure what is the best way to approach it.
I'm not very familiar with struts so take me advice for what it's worth.
There are two ways to approach this that I see.
The first (and probably simplest) is to add an event to the checkboxes which stores the checked state in an array or object onchange. Then, on callback from the ajax refresh, restore those states.
The second approach would require that the ajax refresh either be executed as a post so that the checkboxes are submitted to the server, or having a separate ajax action which fires off when a checkbox is checked. With either of these options, the ajax refresh could "know" at render which checkboxes to render as checked.
If you decide to go with number one, the javascript is not very difficult, especially if you happen to be using a good library (jquery, etc.).