page loading speeds (and an idea about improving front end load time)

[cccs-ip]

from the front end

Loading the document management system from the front end is slow. Trying to click into the viewer / search interface page from our navigation menu takes forever. Would it speed this up to start with 'null' view (where no files are shown before someone performs a search), as opposed to a 'show all' presentation?

from the back end

• trying to enter into an object record from the backend is extremely slow. The process causes strain on my machine (the fans start going strong), and page elements load in pieces... slowly.. with it taking a long time before I can scroll around and edit a record. How might be speed this up?

[pwhipp]

The front end is a proof of concept. If we want to use this sort of view, the pages I assume you are having trouble with are the root and document_list pages.

These are actually working OK for me on Abadi at the moment. The document lists are paginated so the time to fetch the page should remain fairly constant. But...

The entire categorisation tree is fetched for presentation of the root page. If there are a very large number of categories, this is untenable. There are three broad solutions:

1) Break it down so that the root page only shows top level categories. Clicking on one of these opens the next level down as a page (etc.).

2) Keep the presentation similar to the way it is now but use javascript to load subcategories on demand.

3) Present it differently. Perhaps just have a paginated/sortable/filterable list of documents plus a search facility (which still needs writing anyway).

A view by category page feels appropriate (it is similar to a normal file folder view in a sense) so I'll skip further consideration of (3) for now.

(1) would have been the normal approach a year or two ago but it feels very clunky when viewed against the javascript solution (which needs a framework such as AngularJS). However, the Angular solution is more work. Probably ten times as much initially, although this is mostly for setting the framework and API up.

The reason for the initial overhead is that the javascript requires the implementation of an API to serve the 'raw' data and the implementation of a presentation layer in javascript (using AngularJS). Once the API is built and the framework is in place, it can be used to add interactive capabilities and performance optimizations anywhere on the site.

The backend is not causing any substantial issues for me at the moment. It is not fast but it is quite usable (two or three seconds to open a document).

(2) is probably the best way forwards.

[cccs-ip]

Thanks, Paul. I am happy to invest time in JavaScript if you are willing to work on it. Did any of Cristi's past work take us any further in this regard? Did he establish a full JavaScript framework? Or was he using a 'known' framework like Angular?

[pwhipp]

I'm sorry - it will take me longer to analyse Cristi's work in detail than it will take me to start over using AngularJS. I don't believe he was using AngularJS but he was setting up some elements that it frequently uses (such as bower).

[pwhipp]

We can probably close this issue. The use of AngularJS will emerge from addressing actual issues such as the redesign of the root and document listing pages.