Tips & trick to decrease startup loading time in perspective


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

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.



Does it solved in v8.0.2rc?

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

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?

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.

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.


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.

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.


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