Compression View State

org.apache.myfaces.trinidad.COMPRESS_VIEW_STATE

Controls whether the page state is compressed. If the size of the data is compressed, latency can be reduced. This parameter should be set to True.

Enhanced Debug

org.apache.myfaces.trinidad.resource.DEBUG

Controls whether output should be enhanced for debugging. This parameter should be removed or set to False.

Check File Modification

oracle.adf.view.rich.CHECK_FILE_MODIFICATION

Controls whether ADF faces check for modification date of JSP pages and discards any saved state if the file is changed. This parameter should be removed or set to False.

Client State Method

oracle.adf.view.rich.CLIENT_STATE_METHOD

Specifies the type of saving (all or token) that should be used when client-side state saving is enabled. The default value is token.

Client-Side Log Level oracle.adf.view.rich.LOGGER_LEVEL

Sets the log level on the client-side. The default value is OFF. This parameter should be removed or set to False.

Assertion Processing

oracle.adf.view.rich.ASSERT_ENABLED

Specifies when to process assertions on the client-side. The default value is OFF. This parameter should be removed or set to False.

Avoid inline JavaScript in pages.

Inline JavaScript can increase response payload size, is never cached in the browser, and can block browser rendering. Instead of using inline JavaScript, consider putting all scripts in .js files in JavaScript libraries and add scripts to the page by using af:resource tag.

TIP: Consider using af:resource rather than trh:script when possible.

Configure the JSP timeout parameter.

Using the JavaServer Pages (JSP) timeout parameter causes infrequently used pages to be flushed from the cache by the following setting in web.xml:

<servlet>
         <servlet-name>
            oraclejsp
         <init-param>
            <param-name>
               jsp_timeout
            </param-name>
            <param-value>
               x
            </param-value>
         </init-param>
  </servlet-name>
</servlet> 

Create a single toolbar item with a drop-down popup.

When the browser size is small because of the screen resolution, the menubar/toolbar overflow logic becomes expensive in Internet Explorer 7 and 8. It especially has problems with laying out DOM structures with input fields.

Create a single toolbar item with a drop-down and put all the input fields inside it. This drop down should have deferred child creation and contentDelivery="lazy".

Remove unknown rowCount.

A table that has an unknown rowCount can impact performance because getting the last set of rows takes excessive scrolling from the user and the application can appear to be very slow.

Remove unknown rowCount by setting DeferEstimatedRowCountProperty="false" on the view object (VO).

Disable pop-ups that cannot be displayed by the user.

The fnd:attachment component, when stamped in a table, can generate an excessive amount of DOM and client component. The amount of DOM + Client component is ~8K per cell, which impacts the performance of the entire page especially on slower browsers.

Most cells have no attachments initially and only one popup can be displayed by the user. Therefore, pop-ups that cannot be displayed by the user should have renderer="false". This cuts down the unnecessary DOM or client components sent to the browser. Similarly, the DOM has a panelGroupLayout with a number of cells that are empty. There is no need to send DOM for empty cells.

Do not use hover pop-ups on navigation links.

A hover popup on a navigation link causes the navigation to wait for the hover to be fetched first.

Consider removing the hover popup on the compensate workforce table navigation link column and, instead, place it on a separate column or on an icon inside the cell.

Increase table scrolling timeout.

Tables send a fetch request to the server on a scroll after a timeout. The timeout, before the fetch is sent to the server, is typically only 20ms if the user scrolls a short distance, but can increase to 200ms if the user scrolls further. Therefore, performance can be impacted when the user scrolls to the bottom of a page and the table sends multiple requests to the server.

To prevent the performance impact, consider increasing the timeout limit to 300ms.

Use a timeout to call _prepareForIncompleteImages.

During Partial Page Rendering (PPR) some images may not load completely. When this occurs, the parent component must be notified that the size of one of its descendants has changed. In the past this was done by using the complete attribute on the image tag. Now with Internet Explorer 8 the complete attribute is always false to alleviate performance issues with Internet Explorer 7 and 8. The attribute shows as false event for cached images immediately after the PPR content is fetched.

For Internet Explorer 8 use a timeout (10ms) to call _prepareForIncompleteImages so that the image tag called right after the .xml request is processed. Note that this is not an issue for Mozilla Firefox or Google Chrome.

Cache the GetFirstVisibleRowKeyandRow.

Performance can be improved by locally caching the first visible Rowkey and row. This cached value can be deleted on a scroll or a resize.

Use partial page navigation.

Partial Page Navigation is a feature of the ADF Faces framework that enables navigating from one ADF Faces page to another without a full page transition in the browser. The new page is sent to the client by using Partial Page Rendering (PPR)/Ajax channel.

The main advantage of partial page navigation over traditional full page navigation is improved performance: the browser no longer reinterprets and reexecutes Javascript libraries, and does not spend time for cleanup or initialization of the full page. The performance benefit from this optimization is very big; it should be enabled whenever possible.

Some known limitations of this feature are:

• For the document's metaContainerfacet (the HEAD section), only scripts are brought over with the new page. Any other content, such as icon links or style rules can be ignored.

• Applications cannot use anchor (hash) URLs for their own purposes.

Use page templates.

Page templates enable developers to build reusable, data-bound templates that can be used as a shell for any page. A developer can build one or more templates that provide structure and consistency for other developers building web pages. The templates have both static areas on them that cannot be changed when they are used and dynamic areas on them where the developer can place content specific on the page they are building.

There are some important considerations when using templates:

• Since templates are present in every application page, they have to be optimized so that common performance impacts are avoided. For example, adding round corners to the template, can impact the performance for every page.

• When building complex templates, sometimes it is easier to build them in multiple pieces and include them in the top-level template by using the <f:subview> tag. However, from a performance perspective, this is not typically recommended since it can impact memory usage on the server side. The <f:subview>tag introduces another level into the ID scoping hierarchy, which results in longer IDs. Long IDs have a negative impact on performance. Developers are advised to avoid using the <f:subview> tag unless it is required. If you can ensure that all IDs are unique, it is not necessary to use the <f:subview> around <jsp:include> . For example, if you are using <jsp:include>, break a large page into multiple pieces for easier editing. And whenever possible, avoid using the <f:subview> tag. If you are including content developed by someone else, use the <f:subview> tag if you do not know which IDs the developer used. In addition, you do not have to put the <f:subview> tag at the top of a region definition.

• Avoid long IDs in all cases, especially on pageTemplates, subviews, subforms, and on tables or within tables. Long IDs can have a performance impact on the server side, network traffic, and client processing.

Enable ADF rich client geometry management.

ADF Rich Client supports geometry management of the browser layout where parent components are in the UI explicitly. The children components are sized to stretch and fill up available space in the browser. While this feature makes the UI look better, it has a cost. The impact is on the client-side where the browser must spend time resizing the components. The components that have geometry management by default are:

PanelAccordion

PanelStretchLayout

PanelTabbed

BreadCrumbs

NavigationPane

PanelSplitter

Toolbar

Toolbox

Table

Train

Notes:

• When you use geometry management, try to minimize the number of child components that are under a parent geometry managed component.

• The cost of geometry management is directly related to the complexity of child components.

• The performance cost of geometry management can be smaller (as perceived by the user) for the pages with table or other data stamped components when table data streaming is used. The client-side geometry management can be executed while the browser is waiting for the data response from the server.

Use the ADF rich client overflow feature.

ADF Rich Client supports overflow feature. This feature moves the child components to the non-visible overflow area if they cannot fit the page. The components that have built-in support for overflow are: PanelTabbed, BreadCrumbs, NavigationPane, PanelAccordion, Toolbar, and Train. The Toolbar component should be contained in a Toolbox to handle the overflow.

While there were several optimizations done to reduce the cost of overflow, it is necessary to pay special attention to the number of child components and complexity of each of them in the overflow component. Sometimes it is a good practice to set a big enough initial size of the overflow component such that overflow does not happen in most cases.

Use ADF Rich Client Partial Page Rendering (PPR).

ADF Rich Client is based on Asynchronous JavaScript and XML (Ajax) development technique. Ajax is a web development technique for creating interactive web applications, where web pages feel more responsive by exchanging small amounts of data with the server behind the scenes, without the whole web page being reloaded. The effect is to improve a web page's interactivity, speed, and usability.

With ADF Faces, the feature that delivers the Ajax partial page refresh behavior is called partial page rendering (PPR). PPR enables small areas of a page to be refreshed without having to redraw the entire page. For example, an output component can display what a user has chosen or entered in an input component or a command link or button can cause another component on the page to be refreshed.

Two main Ajax patterns are implemented with partial page rendering (PPR):

• native component refresh

• cross-component refresh

While the framework builds in native component refresh, cross-component refresh has to be done by developers in certain cases.

Cross-component refresh is implemented declaratively or programmatically by the application developer defining the components that are to trigger a partial update and the other components that are to act as partial listeners, and so be updated. Using cross-component refresh and implementing it correctly is one of the best ways to improve client-side response time. While designing the UI page always think about what should happen when the user clicks a command button. Is it needed for the whole page to be refreshed or only the output text field? What should happen if the value in some field is updated? For more information, see Developing Fusion Web Applications with Oracle Application Development Framework.

Consider a typical situation in which a page includes an af:inputText component, an af:commandButton component, and an af:outputText component. When the user enters a value for the af:inputText, then clicks the af:commandButton, the input value is reflected in the af:outputText. Without PPR, clicking the af:commandButton triggers a full-page refresh. Using PPR, user can limit the scale of the refresh to only those components you want to refresh, in this case the af:outputText component. To achieve this, you would do two things:

• Set up the af:commandButton for partial submit by setting the partialSubmit attribute to true. Doing this causes the command component to start firing partial page requests each time it is clicked.

• Define the components that are to be refreshed when the partial submit takes place, in this example the af:outputText component, by setting the partialTriggers attribute for each of them to the id of the component triggering the refresh. In this example, this means setting the partialTriggers attribute of the af:outputText component to give the id of the af:commandButton component.

The steps above achieve PPR by using a command button to trigger the partial page refresh.

The main reason why partial page rendering can significantly boost the performance is that full page refresh does not happen and the framework artifacts (such as ADF Rich Client JS library and style sheets) are not reloaded and only a small part of page is refreshed. In several cases, this means no extra data is fetched or no geometry management.

The ADF Rich Client has shown that partial page rendering results in the best client-side performance. Besides the impact on the client-side, server-side processing can be faster and can have better server-side throughput and scalability.

Use ADF rich client navigation.

ADF Rich Client has an extensive support for navigation. One of the common use cases is tabbed navigation. This is currently supported by components like navigationPane, which can bind to xmlMenuModel to easily define navigation.

There is one drawback in this approach, however. It results in a full page refresh every time the user switches the tab. One option is to use panelTabbed instead. panelTabbed has built-in support for partial page rendering of the tabbed content without requiring any developer work. However, panelTabbed cannot bind to any navigational model and the content has to be available from within the page, so it has limited applicability.

Cache resources.

Developers are strongly encouraged to ensure that any resources that can be cached (images, CSS, and JavaScript) have their cache headers specified appropriately. Also, client requests for missing resources on the server result in addition round trips to the server. To avoid this, make sure that all the resources are present on the server.

Consider using the ResourceServlet to configure the web.xml file to enable resource caching:

<servlet-mapping>
     <servlet-name>resources</servlet-name>
     <url-pattern>/js/*</url-pattern>
   </servlet-mapping>
<servlet-mapping>
     <servlet-name>resources</servlet-name>
     <url-pattern>/images/*</url-pattern>
   </servlet-mapping> 

Reduce the size of state token cache.

This property is defined in web.xml org.apache.myfaces.trinidad.CLIENT_STATE_MAX_TOKENS in token-based client-side state saving and determines how many tokens should be preserved at any one time. The default value is 15. When this value is exceeded, state is forgotten for the least recently viewed pages, which can impact users that actively use the Back button or have multiple windows that are open simultaneously.

To reduce live memory per session, consider reducing this value to 2. Reducing the state token cache to 2 means one Back button click is supported. For applications without support for a Back button, this value should be set to 1.

Define custom styles at the top of the page.

A common developer task is to define custom styles inside a regular page or template page. Since most browsers use progressive scanning of the page, a late introduction of styles forces the browser to recompute the page. This impacts the page layout performance. For better performance, define styles at the top of the page and possibly wrap them inside the ADF group tag.

An HTML page basically has two parts, the head and the body. When you add an af:document component to a page, this component creates both parts of the page for you. Any child component of the af:document is in the body part of the page. To get a component (or static CDATA content) to show up in the head, use the metaContainer facet.

To get a component (or static CDATA content) to display in the head, use the metaContainer facet as follows:

<af:document title="#{attrs.documentTitle}" theme="dark">
<f:facet name="metaContainer">
<af:group><![CDATA[
<style type="text/css">
.TabletNavigationGlobal {
text-align: right;
padding-left: 0px;
padding-right: 10px;
white-space: nowrap;
}
HTML[dir=rtl] .TabletNavigationGlobal {
text-align: left;
padding-left: 10px;
padding-right: 0px;
}
</style>
]]>
<af:facetRef facetName="metaContainer"/>
</af:group>
</f:facet>
<af:form ...>
<af:facetRef facetName="body"/>
</af:form>
</af:document>

If you use page templates, consider including af:document and af:form in the template definition and expose anything that you may want to customize in those tags through the page template attributes and page template af:facetRef. Your templates are then able to utilize the metaContainer facet if they have template-specific styling as shown above. Also, your usage pages do not have to repeat the same document and form tags on every page.

See Developing Fusion Web Applications with Oracle Application Development Framework for details about af:facetRef.

Optimize custom JavaScript code.

ADF Rich Client uses JavaScript on the client side. The framework itself provides most of the functionality needed. However, you may have to write a custom JavaScript code. To get the best performance, consider bundling the JavaScript code into one JS lib (one JavaScript file) and deliver it to the client. The easiest approach is to use the ADF tag: <af:resource type="javascript" source=" "/>.

If most pages require custom JavaScript code, the tag should be included in the application template. Otherwise, including it in particular pages can result in better performance. If you customize the Javascript code the lib file becomes too big. Then consider splitting it into meaningful pieces and include only the pieces needed by the page. Overall, this approach is faster since the browser cache is used and the html content of the page is smaller.

Disable debug output mode.

The debug-output element in the trinidad-config.xml file specifies whether output should be more verbose to help with debugging. When set to TRUE, the output debugging mechanism in Trinidad produces pretty-printed, commented HTML content. To improve performance by reducing the output size, you should disable the debug output mode in production environments.

Set the debug-output element to FALSE, or if necessary, remove it completely from the trinidad-config.xml file.

Disable test automation.

Enabling test automation parameter oracle.adf.view.rich.automation.ENABLED generates a client component for every component on the page, which can negatively impact performance.

Set the oracle.adf.view.rich.automation.ENABLED parameter value to FALSE (the default value) in the web.xml file to improve performance.

Disable animation.

ADF Rich Client framework has client-side animation enabled by default. Animation is introduced to provide an enhanced user experience. Some of the components, like pop-up table, have animation set for some of the operations. While using animation can improve the user experience, it can increase the response time when an action is executed. If speed is the biggest concern, then animation can be disabled by setting the flag in the trinidad-config.xml file.

Disable client-side assertions.

Assertions on client-side code base can have a significant impact on client-side performance. Set the parameter value to FALSE (the default value) to disable client-side assertions. Also ensure that the oracle.adf.view.rich.ASSERT_ENABLED is not explicitly set to TRUE in the web.xml file.

Disable JavaScript Profiler.

When the JavaScript oracle.adf.view.rich.profiler.ENABLED profiler is enabled, an extra round-trip occurs on every page to fetch the profiler data. Disable the profiler in the web.xml file to avoid this extra round-trip.

Disable resource debug mode.

When resource debug mode is enabled, the response headers do not tell the browser that resources (JS libraries, CSS style sheets, or images) can be cached.

Disable the org.apache.myfaces.trinidad.resource.DEBUG parameter in the web.xml file to ensure that caching is enabled.

Disable timestamp checking.

The org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION parameter controls whether the jsp or the jspx files are checked for modifications each time they are accessed.

Ensure that the parameter value org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION is set to FALSE (the default value) in the web.xml file.

Disable checking for CSS file modifications.

The org.apache.myfaces.trinidad.CHECK_FILE_MODIFICATION parameter controls when the CSS file modification checks are made. To aid in performance, this configuration option defaults to false-does not check for css file modifications. Set this to TRUE if you want the skinning css file changes to be reflected without stopping or starting the server.

Enable content compression.

By default, style classes that are rendered are compressed to reduce the page size. In production environments, make sure that you remove the DISABLE_CONTENT_COMPRESSION parameter from the web.xml file or set it to FALSE.

For debugging, turn off the style class content compression. You can do this by setting the DISABLE_CONTENT_COMPRESSION property to TRUE.

Enable JavaScript obfuscation.

ADF Faces supports a runtime option for providing a non-obfuscated version of the JavaScript library. The obfuscated version is supplied by default, but the non-obfuscated version is supplied for development builds. Obfuscation reduces the overall size of the JavaScript library by about 50%.

To provide an obfuscated ADF Faces build, set the org.apache.myfaces.trinidad.DEBUG_JAVASCRIPT parameter to FALSE in the web.xml file.

There are two ways to check that the code is obfuscated by using Firefox with Firebug enabled:

Check the download size:

1. Ensure that All or JS is selected on the Net tab.

2. Locate the all-11-version.js entry.

3. Check the size of the column. It should be about 1.3 MB (as opposed to 2.8 MB).

Check the source:

1. From the Script tab select all-11-version.js from the drop-down menu located above the tabs.

2. Examine the code. If there are comments and long variable names, the library is not obfuscated.

   Note: Copyright comments are kept even in the obfuscated version of the JS files.

Enable library partitioning.

In the Oracle 11g release, library partitioning is ON by default. In the previous versions, library partitioning was OFF by default. Ensure that the library partitioning is ON by validating the oracle.adf.view.rich.libraryPartitioning.DISABLED property is set to false in the web.xml file.

Use the immediate attribute.

ADF Rich Client components have an immediate attribute. If a component has its immediate attribute set to TRUE (immediate="true"), then the validation, conversion, and events that are associated with the component are processed during the applyRequestValues phase. These are some cases where setting immediate to TRUE can lead to better performance.

• To avoid processing the data from the current screen while navigating to the new page set the immediate attribute to TRUEin the commandNavigationItem in the navigationPane.

• If the input component value has to be validated before the other values, immediate should be set to TRUE. In case of an error it be detected earlier in the cycle and additional processing be avoided.

ADF Rich Client is built on top of JSF and uses standard JSF lifecycle. See Using the JSF Lifecycle with ADF Faces in Developing Web User Interfaces with Oracle ADF Faces.

There are some important issues that are associated with the immediate attribute. Refer to Using the Immediate Attribute in Developing Web User Interfaces with Oracle ADF Faces for more information.

Note that this is an advanced feature. Most of the performance improvements can be achieved by using the af:subform component.

Use the visible and rendered attributes.

All ADF Faces Rich Client display components have two properties that dictate how the component is displayed on the page:

• The visible property specifies whether the component is to be displayed on the page or to be hidden.

• The rendered property specifies whether the component shall exist in the client page at all.

The EL expression is commonly used to control these properties. For better performance, consider setting the component to not rendered instead of not visible, assuming that there is no client interaction with the component. Making a component not rendered can improve server performance and client response time since the component does not have client-side representation.

Use client-side events.

ADF Rich Client framework provides the client-side event model based on component-level events rather than DOM level. The client-side event model is a very useful feature that can speed up the application. Review the following performance considerations:

• Consider using client-side events for relatively simple event handling that can be done on the client side. This improves client-side performance by reducing the number of server round trips. Also, it can increase server-side throughput and scalability since requests do not have to be handled by the server.

• By default, the events generated on the client-side by the client components are propagated to the server. If a client-side event handler is provided, consider canceling the event at the end of processing so that the event does not propagate to the server.

Use the id attribute.

The id attribute should not be longer than 7 characters in length. This is particularly important for naming containers. A long id can impact performance as the amount of HTML that must be sent down to the client is impacted by the length of the ids.

Use client-side components.

ADF Rich Client framework has client-side components that play a role in client-side event handling and component behavior. The clientComponent attribute is used to configure when (or if) a client-side component should be generated. Setting clientComponent attribute to TRUE has a performance impact, so determine if its necessary to generate client-side components.

For more information, see What Happens When You Set clientComponent to true in Developing Web User Interfaces with Oracle ADF Faces.

Set the childCreation attribute on af:popup to deferred for a server-side performance enhancement

Setting childCreation to deferred postpones construction of the components under the popup until the content is delivered. A deferred setting can therefore reduce the footprint of server-side state in some cases.

CAUTION: This approach cannot be used if any of the following tags are present inside the popup:

• f:attribute

• af:setPropertyListener

• af:clientListener

• af:serverListener

It also cannot be used if you need to refer to any child components of the popup before the popup is displayed. Setting childCreation="deferred" postpones creating any child components of the popup and you cannot refer to them until after the popup is shown.

Use editingMode="clickToEdit".

When using editingMode="editAll" all content of the editable values holders and their client components is sent. This can significantly increase the payload and the Document Object Model (DOM) content on the client.

Consider switching to editingMode="clickToEdit" to reduce the amount of transmitted data and potentially improve user interaction.

Reduce fetchSize when possible.

A larger fetch size attribute on af:table implies that more data needs to be processed, fetched from the server, and displayed on the client. This can also increase the amount of DOM displayed on the client.

Modify table fetch size.

Tables have a fetch size, which defines the number of rows to be sent to the client in one round-trip. To get the best performance, keep this number low while still allowing enough rows to fulfill the initial table view port. This ensures the best performance while eliminating extra server requests.

In addition, consider keeping the table fetch size and iterator range size in sync. By default, the table fetch size is set to the EL expression #{bindings.<name>.rangeSize} and should be equal to the iterator size.

For more information, see Using Tables, Trees, and Other Collection-Based Components in Developing Web User Interfaces with Oracle ADF Faces.

Disable column stretching.

Columns in the table and treeTable components can be stretched so that there is no unused space between the end of the last column and the edge of the table or treeTable component. This feature is turned off by default due to potential performance impacts. Turning this feature on may have a performance impact on the client rendering time, so use caution when you enable this feature with complex tables.

Consider using header rows and frozen columns only when necessary.

The table component provides features that enable you to set the row header and frozen columns. These options can provide a well-designed interface, which can lead to a good user experience. However, they can impact client-side performance. To get the best performance for table components, use these options only when they are needed.

Consider using visitTree instead of invokeOnComponent.

A partial visit using visitTree is always at least as fast as invokeOnComponent. In addition, for components that control visiting, providing both invokeOnComponent and visitTree implementations is a source of errors. Consider deprecating invokeOnComponent and use visitTree instead.

For more information, see Using Tables, Trees, and Other Collection-Based Components in Developing Web User Interfaces with Oracle ADF Faces.

Lazy Delivery (default)

Lazy delivery should be used for tables, or other stamped components, which are known to have slow fetch time. For example, the stamped components are the ones based on data controls using web services calls or other data controls with slow data fetch. Lazy delivery can also be used on pages where content is not immediately visible unless the user scrolls down to it. In this case the time to deliver the visible context to the client is shorter, and the user perceives better performance.

Lazy delivery is implemented by using the data streaming technique. The advantage of this approach is that the server has the ability to execute data fetches in parallel and stream data back to the client as soon as the data is available. The technique performs very well for a page with two tables, one that returns data very quickly and one that returns data very slowly. Users see the data for the fast table as soon as the data is available.

Executing data fetches in parallel also speeds up the total time to fetch data. This gives an advantage to lazy loading in cases of multiple, and possibly slow, data fetches. While streaming is the default mechanism to deliver data in lazy mode, parallel execution of data controls is not. To enable parallel execution, open the page definition and change RenderHint on the iterator to background.

In certain situations, the advantage of parallel execution is faster response time. Parallel execution could potentially use more resources due to multiple threads executing requests in parallel and possibly more database connections are opened.

Consider using parallel execution only when there are multiple slow components on the page and the stamped components belong to different data control frames (such as isolated task flows). When there is a single data control frame, parallel execution may not improve performance, since parallel execution synchronizes on the data control frame level.

Immediate Delivery

Immediate delivery (contentDelivery="immediate") should be used if the table data control is fast, or if it returns a small set of data. In these cases, the response time is faster than using lazy delivery.

Another advantage of immediate delivery is less server resource usage, compared to lazy delivery. Immediate delivery sends only one request to the server, which results in lower CPU and memory usage on the server for the given user interaction.

Modify the RangeSize attribute.

The RangeSize attribute defines the number of rows to return simultaneously. A RangeSize value of -1 causes the iterator to return all the rows. Using a lower value may improve performance, but it may be harder to stop the data and any data beyond RangeSize is not available in the view.

Use horizontal text instead of vertical text.

By default, pivot tables use horizontal text for column headers. However, there is an option to use vertical text as well. Vertical text can be used by specifying a CSS style for the header format such as:

writing-mode:tb-rl;filter:flipV flipH;

While vertical text can look better in some cases, it has a performance impact when the Firefox browser is used.

The problem is that vertical text is not native in Firefox as it is in Internet Explorer. To show vertical text, the pivot table uses images produced by GaugeServlet. These images cannot be cached as the text is dynamic and depends on the binding value. Due to this, every rendering of the pivot table incurs extra round-trips to the server to fetch the images, which impact network traffic, server memory, and CPU.

To have the best performance, consider using horizontal text instead of vertical text.