If your web apps are slow, nobody will want to use them. It is as simple as that.
Capabilities such as adaptive filtering, lazy rendering, and of course the architecture of SmartClient mean that if you have selected our platform, you’ve already put your best foot forward. But, of course, taking a wrong turn during development can still quickly degrade performance.
I asked a few of our developers here at Isomorphic to tell us about pitfalls they’ve seen customers hit, how best to avoid them, and to give us any helpful performance tips. Here’s what they said:
Mae: Using load on demand for a large data set makes a huge difference. This is enabled by default on the ListGrid (set dataPageSize: “paged”) and the “page” (number of rows fetched at a time) size can be customized using the dataPageSize property.
Charles: Use the FileLoader to start loading the core SmartClient runtime in the background while your users are interacting with a non-SmartGWT login page or landing page, to reduce application load time for first-time users who have not yet cached these files. To do this, load the ISC_FileLoader.js file in your plain HTML login or landing page, and call isc.FileLoader.cacheISC(). Refer to the SmartClient Reference for FileLoader for details of how to get this right (setting path to the files to load, etc), and also to learn about other features of the FileLoader that can help you cache other resources.
deferattribute to load all the files of the SmartClient runtime into the current page, without blocking rendering of plain HTML content such as a login form.
For an even better experience, identify multiple pages that an end user may visit before they first launch your application, and use the FileLoader to start caching on each of those pages.
Dave: One I’ve run into a few times is aggregating data on the client. It is easy to put together simple DataSources for CRUD data access but there are times where aggregation or computed results are needed. Using the CRUD DataSources works fine for small amounts of data but when the data gets larger the delay becomes a UX failure. Using advanced DataSource joins and possibly creating a read-only DataSource is one way to go. For more complex cases I have created custom SQLDataSource classes that perform the operations server-side and therefore has quick access to related data and can return only the data needed by the client for display.
Greg: Customers sometimes redraw nested widget hierarchies too much, and we tell them to use markForRedraw() to batch those. We also recommend making the DataBoundComponent page size large enough to cover the visible rows.
Jay: A couple of pieces of advice spring to mind:
1) don’t fiddle with data defaults unless you know what you’re doing – the defaults already provide efficiency and scalability in data round-tripping/UI, the bulk of most systems
2) when coding, avoid using Array methods like contains() and find() where possible, particularly in loops – they’re costly methods and become more so with array size
Alex: Two tips I find make a big difference are:
We hope this gives you some useful pointers.
How about you?
Have you got a top tip you’d like to share? If so, please email us and we’ll feature on a future blog.
Thanks for reading!
The Isomorphic Team