Tips & trick to decrease startup loading time in perspective

Ignition Early Access
1

Hello

Is there any tips & trick to decrease startup loading time in perspective?

2

Hi Chris,

I’ve got good news and bad news.

Bad news first:

Unfortunately there isn’t a lot you can do to speed loading times right now, but it depends on the nature of slowness you’re experiencing. There are project decisions that may influence load times.

Specifically: some components require rather large libraries to function. These libraries are not included in your project dependencies if the components which require them are not used. For example, I know the following components all have dependencies that are relatively large:

  • Datetime Components
  • Map Component
  • PDF Viewer
  • Charts
  • Markdown Component

Large dependencies mean an increased number and size of network requests (and corresponding loading time), which can really impact load times on slower networks/devices. These larger dependencies aren’t inherently bad, they’re just a byproduct of the component’s functionality - larger/more complex functionality needs more resource support.

So as a matter of ‘building for performance’, you may want to avoid adding these components to projects where they aren’t really used, or are used in minor features of your project. If a project is aimed at high performance, you might consider moving Views using these components to a second project that shares/inherits the same parent project who can act as the ‘data source’. Then you could keep your ‘high performance’ project down to a smaller dependency set, and then just link to the ‘heavy project’ when certain features of it are needed. There are obvious tradeoffs with this approach, but it might be workable depending on your scenario.

Good news:

Loading time/speed is something we are actively working on. One of the most notable improvements (among many) we are working on is to support local caching of perspective resources. While this isn’t going to improve ‘initial’ load times, it’s going to make a dramatic improvement in loading a project that has previously been loaded, and will be true for projects that use all the components mentioned above. Not sure on exact timeline, but likely 8.0.2 or 8.0.3.

Would be great if you could follow up with more information about the conditions you’re seeing slowness (slow network? Slow device? Certain project/pages?) so we have an additional datapoint to consider.

-Perry

3 Likes
3

Hi
Does it solved in v8.0.2rc?

4

Didn't make the cut for 8.0.2RC. There are really a few different improvements happening in parallel, but the primary client caching work is complete and going through review. I believe it will end up in the Nightly builds in the coming days. Keep an eye on the nightly release notes.

1 Like
5

Hi
I still don’t see this fix in 8.0.3 current nightly release.
Do you believe at the end of this month this fix will be added?

6

Yes, I expect these changes by end of month and to be included in 8.0.3 barring any major surprises. Work is done and the QA validation of the changes is in progress.

7

Hi @chris.roys @nader.chinichian, just wanted to give a heads up that the initial support for caching perspective assets made it into last night’s nightly build.

These changes add support for browser caching of many perspective assets. The result is that in slow/limited network connections, initial load times for a project are unchanged. However, follow-up loads of those projects should be much faster, as the browser/app can skip downloading most of the assets it downloaded previously. In our testing we’ve seen some fairly dramatic improvements in launch times.

Few things to note:

  1. Chrome and Safari handle browser cache differently than Edge/FF when it comes to hitting the ‘refresh’ or ‘reload’ page. Edge and FF both seem to send a request for new copies of the resources with header of max-age=0 instead of pulling from cache. Navigating via ‘back’ button or entering the url bar and pressing ‘enter’ will load from cache. This seems to simply be a design difference by these two browsers, in which both are working as intended.

  2. Cache can be disabled via flag in environment (ignition.conf jvm parameter): -Dperspective.gateway.disableClientCaching=true.

  3. Response header’s Cache-Control value defaults to public, max-age=2419400, no-transform. You can set your own cache-control header via another env var: -Dperspective.gateway.cacheControl=<some alternative cache control settings>

We appreciate any feedback you can offer, thanks for your patience. This is only one of many performance improvements we’re working through, but it should prove very noticeable on slower networks/devices.

edit: fixed vm variable capitalization to match what it will be in the nightly builds beginning the morning (PST) of June 13.

4 Likes
8

Create news. It’s seems there are some resources that left to be added later for caching. Am I right?
Does this include mobile app?
I believe you much more option to increase startup performance for only mobile app. Like caching all the project.

9

Indeed this round of general improvements was targeted purely at the browser and is not intended to cache everything, but serves as a good starting point that should help alleviate much of the loading slowness people experience (after they’ve initially downloaded the resources needed of course). The mobile apps benefit from this, but we haven’t done any mobile-specific work with this set of features.

Caching projects on mobile devices is something we’ve yet to look at, but something we’ll likely look at down the road. For now our focus is largely on improvements across all platforms/environments. More platform-specific functionality (mobile, offline functionality, native desktop apps, etc) is definitely coming once we’re more satisfied with where the greater perspective ecosystem is.

5 Likes
10

Is it possible to show some other content during resource load? or show my company logo instead of ignition’s GIF?

11

Old topic, but still relevant!!

Don’t use multi-level nested embedded views (EVs)!
e.g.

View
-> Embedded View
   ->Embedded View
      ->Embedded View

I did a comparison of load times in 8.1.18 between using EVs with no nested EVs, and EVs which contains EVs that have at least one level of nested EV, and the results are incredible.

1st part (1.3s) - EVs with no nested EVs
e.g.

View
-> Embedded View 1
-> Embedded View 2
-> Embedded View 3

2nd part (12.2s) - EVs with nested EVs that also have nested EVs - ignore the graphical crappiness… also it would actually be slightly longer than this as I’m missing one of the template Views
e.g.

View
-> Embedded View 1
   ->Embedded View
      ->Embedded View
-> Embedded View 2
   ->Embedded View
      ->Embedded View

I’m still curious why IA weren’t able to “flatten” the main Views on the gateway before sending to the clients :thinking:
The main hurdle when I briefly looked at it was the inconsistent way of referencing parent level components (Perspective relative references to parent component properties), making it far more difficult to replace bindings in embedded views with their flattened versions :confused: certainly not a roadblock though. I’m curious what the roadblock(s) was/were?

8 Likes
12

It’s sad, because I really like using nested embedded views.
With them I can build views in a very modular way. Create “building blocks” that I use to make more complex views. It also helps keeping things to a certain standard, and making changes are easy because they are then updated throughout the project.

But I am for sure taking a performance hit, and like your video shows, the views load bit by bit which looks bad.

I know for performance I should ‘flatten’ the views, but I am holding out, hoping they would fix this issue

I actually thought this was the whole idea behind embedded views, to enable us to build modular views like this.

Edit:
So I went ahead and added this to the ideas page, I hope the wording is fine.
Link

1 Like
13

A problem I run into with embedded views is that the parameters stay stuck with the default parameter value, which is usually “value”.

I have to refresh the page when this happens (soemtimes more than once) to get the actually values to populate. This is a bigger problem when running a perspective Workstation client as oppose to a web browser client.

14

I thought about trying to write my own “flattener” code to go through all of the embedded views on a page and merge them into a single new version of the main view. The only time you can’t do this is if the view path is bound to something. The stumbling block I found was in converting the bindings in the embedded views, since you can’t just use parent.parent.custom.key; the best you can get is ../../../FlexContainer.custom.key but it requires you to know the name of the component, which is annoying. It’s not a show stopper, but it’s definitely annoying to handle!

Edit: I realise I said some of this already in my post above :slight_smile: time to go buy a walking frame I think…

You’re definitely right about embedded views making for cleaner design and standardisation across the project. Otherwise you’re forever copying and pasting components around, and if ever something needs to change or be added, you’re screwed and have to make the change in many places. CSS does help a little here though at least for the styling of the components, compared to if this was an issue in Vision

1 Like
15

Hrm. Can you check your loading order on these embedded views? We did a lot of work way back to make this faster, you just want to make sure your embedded views are set to load “with-parent” instead of “after-parent”
image

16

All of my embedded Views were all set to after-parent. I’ve changed them all (including all nested one as well) to with-parent and the results are below.
No nested EVs: 1,490ms
Nested EVs using with-parent: 12,120ms

Times calculated from gif frame durations.

No nested EVs
Perspective Tank Farm Load Time - Test 02p - No Nested EVs

Nested EVs using with-parent
Perspective Tank Farm Load Time - Test 02bp - Nested EVs load with-parent

Just note: the nested EV versions were designed for being displayed bigger than what they are on the page, hence they look all squished… although I do actually prefer the new look

2 Likes
17

Can you distill this test down into a project + memory tags that you could export and send to me?

2 Likes
18

Can do, that’s pretty much all I’m working with at the moment anyway. I’ll pm you later today

3 Likes
19

Just to add to this, I experience the same issue, Nested Embedded Views increase the loading Time dramatically, and it’s “choppy” like the GIF shows. That just doesn’t look super professional when presenting to clients. Hence one of my ideas on the forum was some sort of loading indicator, that way I could at least hide it behind something while it loads

1 Like
20

Having a loading graphic for 12s though would probably feel even worse for a user though :sweat_smile: but hopefully Carl and and team can find some more efficiencies to be gained :crossed_fingers:

1 Like