This is one of the data gathering methodologies and recommendations for functional performance improvement. The full list is defined in the Performance Recommendations topic.
The Web UI Designer is flexible and can configure a Web UI in many ways. However, not all configurations perform equally well. Therefore, it is important to consider performance when configuring a Web UI. A screen with little data and limited functionality will load faster than a screen with lots of data and functionality.
For more information, refer to the Healthcheck section of the Administration Portal documentation here.
The following actions can limit the performance impacts while using Web UI:
- Web UI Component Report
- Use multiple Web UIs
- Use small dedicated Web UI screens
- Avoid using images in multi-select Web UI screens
- Use 'lazy' loading for Web UI screens
- Use type ahead for LOVs in Web UI screens
- Correctly configure status selectors in Web UI
- Privileges in Web UI configuration
- Consider In-Memory for Web UI screens
Web UI Component Report
The Web UI Component Report provides an in-depth look at the components configured for all Web UIs. Of particular interest are those in the end-stages of their lifecycle. Use this report to replace outdated components and update configurations improve the upgrade process. The reported components are those that have been:
-
Deleted entirely: will not render
-
Withdrawn: once removed cannot be added again
-
Superseded: will work as usual, but a new and improved component is available
The Web UI Component Report link is displayed at the top-right of the system Start Page and in the popup that displays when accessing the Web UI designer. You can also access it using the URL http://[ENVIRONMENT]/webui/componentreport (modified with your environment name).
For more information, refer to the Web UI Component Report section of the Web UI Component Basics topic in the Web User Interfaces documentation here.
Recommendation
For optimal Web UI performance, remove the superseded, withdrawn, and deleted Web UI components or replace with the newer available Web UI components.
Use Multiple Web UIs
Web UI configurations are stored in System Setup under the Web UIs node. When a user logs into the Web UI and opens the homepage, the corresponding configuration XML file is loaded. If the Web UI configuration XML file is large, then the Web UI homepage takes additional time to load. Edit the Web UI configuration to view the XML, as shown below.
For more information, refer to the Managing Web UI Configurations topic in the Web User Interfaces documentation here.
Recommendation
When the Web UI configuration XML is more than 25,000 lines, split the configuration into separate Web UIs where each is used for a specific purpose.
Use Small Dedicated Web UI Screens
A typical Web UI screen fetches all attribute values from the attribute group defined in the Web UI screen. The screen then filters out the attributes based on the validity of the product type and user privileges.
Configuring attribute groups for the Web UI screen which contain a large number of attributes can have a negative impact on the loading time of the screen because it involves:
- fetching all attributes from the attribute groups, and then
- filtering out attributes for display based on the validity of the product type and user privileges.
To reduce the screen load time, first determine which attribute groups are used in the Web UI screen, as shown below.
Then analyze how many attributes each attribute group contains, using the Search Below option.
Recommendation
Avoid using attribute groups with more than 100 attributes. When configured attribute groups contain more than 100 attributes, consider creating attribute groups specifically for Web UI display. Organize the attributes to be displayed on the Web UI screens into these specific attribute groups.
Avoid Using Images in Multi-Select Web UI Screens
A multi-select screen displays a selection of items in a table. The table view also allows for thumbnails of the items to be displayed. However, loading many items with their thumbnails naturally requires fetching these thumbnails from the file system or database, which may have a negative impact on the load time of the screen.
Recommendation
Reconsider displaying thumbnails (or no images at all) in multi-select screens when many items are displayed and load time of the screen is considered slow.
Use 'Lazy' Loading for Web UI Screens
For Web UI tasks where the user needs to inspect many aspects of an item, the recommendation is to split the information out into multiple tabs. However, by default, the Web UI loads the screen including all tabs, which may result in a slow loading time for the Web UI screen.
In Web UI designer, the 'Lazy' parameter allows you to apply 'lazy loading' on these Tab Page screens. When enabled, components are 'lazy loaded’ and rendered only when a tab is displayed, which can reduce screen load time.
Use the Performance section of the STEP Health Check in the Admin Portal to analyze which Web UI screens can be lazy loaded by running the 'Check for Common Web UI Configuration Errors' healthcheck shown below.
For more information, refer to the Healthcheck topic in the Administration Portal documentation here.
Recommendation
When possible, lazy load data on tabs.
Use Type Ahead for LOVs in Web UI Screens
Web UI screens using attributes with a large list of values (LOVs), the load time of the Web UI screen can become slower. The following LOV type-ahead sharedconfig.properties are available to optimize the Web UI screen load time:
- Portal.ValueGroup.LOV.ForceTypeahead forces type-ahead for all LOVs in the Web UI. Set this property when there are attributes used in Web UI screens and many of the LOVs used are large.
- Portal.ValueGroup.LOV.ForceTypeahead.Exclude forces type-ahead for certain LOVs in the Web UI. Certain specific LOVs can be configured not to be forced to user type-ahead functionality. Use this for the LOVs with small number of values and for the LOVs which are required to not be typed-ahead.
Analyze which LOVs have more than 5,000 values by running the 'Too many valid values for list of values' healthcheck. Also review Web UI screens to find where large LOVs with fewer than 5,000 values are being used.
For more information, refer to the Healthcheck topic in the Administration Portal documentation here.
Recommendation
Set up typeahead for large LOVs.
Correctly Configure Status Selectors in Web UI
The workflow Status Selectors Homepage Widget is configured to poll for updates in the background. The statuses are updated whenever the user submits an item. However, if there are many status selectors and/or the update polling is set very fast, the Web UI Homepage screen may suffer from poor performance.
In design mode, double-click the Status Selector Homepage Widget to display the 'Auto Refresh Interval' parameter. The recommended value is 60 seconds. Disable the refresh interval by setting the value to 0.
For more information, refer to the Status Selector Homepage Widget topic in the Web User Interfaces documentation here.
Recommendations
-
Limit the number of status selectors, generally no more than 25 status selectors on the Homepage screen.
Download the Web UI XML to review status selectors used in a Web UI and search for:
-
StatusSelectorHomepageWidget to find the status selectors on the homepage.
-
StatusSelectorWidget to find the status selector on another page.
-
Do not set the Status Selector Homepage Widget 'Auto Refresh Interval' parameter to less than 60 seconds.
Download the Web UI XML and search for AutoRefreshInterval to find auto refresh intervals on status selectors.
-
Be aware that including many nodes in a workflow being calculated in the Status Selector may increase loading times.
-
Reduce load times. On the Web UI designer for the Status Selector Homepage Widget properties screen, Advanced section, check the 'Use Content Indicator' parameter. This shows a button to manually load the count, instead of displaying the exact count automatically.
Download the Web UI XML and search for UseContentIndicator to find the content indicator used on status selectors.
Privileges in Web UI configuration
Although privilege restrictions can be set in the Web UI configuration itself, excessive privilege checking in the Web UI XML configuration can degrade performance.
Recommendations
Download the Web UI XML and search for restrict= and analyze if these user restrictions are necessary.
Consider In-Memory for Web UI Screens
In-Memory can improve performance of the Web UI screens. In-Memory makes the Web UI more responsive in general, but especially when the Web UI screens include multi-object display, complex data models, and/or data with a long history of writes.
For more information, refer to the In-Memory Database Component for STEP section of the Resource Materials section of online help here.