Introduction

Page weight and page load times are two of the most common performance metrics used to measure a Portal's performance. These are significant factors behind a portal's success especially in the context of mobile devices. This article walks you through identifying and analyzing some common WebCenter Portal performance bottlenecks related to page weight and describes a generic approach that can streamline your portal while improving the performance and response times. Understanding the tuning parameters and how the framework delivers portal pages will significantly improve your ability to design a portal optimized for your business needs and tune the system to meet your performance goals.

This article specifically takes a close look at analyzing the JavaScript footprint of your application and how you can improve it by strategically designing pages and JavaScript partitions. As an example we take the use case of the landing page for a portal delivered through a mobile device. This article is accompanied by an example application which is geared towards mobile delivery and when deployed to an environment which is setup as described here will yield a page that is less than 230kB in size.

Main Article

In this article, I use the Firefox browser, the FireBug extension and YSlow plug-in for FireBug to measure performance. To start off we begin with a normal WebCenter Portal Framework application in JDeveloper. We can run the bare bones application right away and we see that on a cold browser (nothing previously cached), the total page weight is around 1.4 MB. A screenshot of the application and full break down is below.

The graph above clearly shows that JavaScript is one the main sources that contribute to the current page weight. Drilling down reveals the actual JavaScript files downloaded and how much they contribute to the page weight. We have 12 JavaScript assets taking up a total of 900kB, and looking at the files themselves we know what JavaScript partitions are being downloaded.

JavaScript Partitioning and a Phased delivery model

When using a framework that relies on JavaScript like ADF, a common challenge is to reach a balance in how to deliver the JavaScript code base to the client. Delivering all the JavaScript in one go, on the first request is obviously inefficient since it increases the page weight for the initial page, and delivering the JavaScript code in fine grained chunks will result in too many HTTP round-trips being made to fetch the required assets. ADF solves this problem elegantly using JavaScript Partitioning. JavaScript partitioning should be one of the first things you consider to minimize page weight by downloading only the necessary JavaScript files and creating your partitions so that only the required features are downloaded.

In our approach, we use four generic, but customized partitions which are designed to deliver the assets in a phased manner, striking a balance between the page weight and the HTTP round trips needed. The ADF Core and Boot partitions provide the basic functionality for ADF faces and are required. Our customized partitions however will be downloaded only if the page uses a component belonging to that partition.

• Initial Partition
  • Compressed size is about 15 kB
  • Includes basic components like Form, Window, Dialog
  • Includes Output components, and Go components
  • Includes the Panel Grid Layout component since we will use this as our primary layout component
  • Intended to be used on a landing page with mostly static content
• Basic Partition
  • Compressed size is about 10 kB
  • Includes common components like command components, Input components
  • Intended to be used on a login style page
• Essential Partition
  • Compressed size is about 10.3 kB
  • Includes region support, Show detail frames, List View and Panel Box 
• Desktop Partition
  • Compressed size is about 70 kB
  • Rich interactive components like Rich Tables, Query Panels
  • Components aimed towards a traditional web/desktop delivery. 

Other partitions are possible, and based on the requirement and the footprint SLAs, these can be modified to include the components required. Husain explains the steps on creating your own partitions in his post here :http://www.ateam-oracle.com/adf-javascript-partitioning-for-performance

 For the phased delivery to be effective, proper page templates and design is also required. The approach is to deliver a phase of our partitioned code base with every request, till all four partitions are delivered. For instance, the initial pages and page template should limit the component flavors to those made available in the initial partition. This makes it possible for the page to be rendered with just the first partition being downloaded, minimizing the page weight. Pages can however reuse the assets delivered through earlier requests if appropriate HTTP headers are set using web server configuration (OHS/Apache). Therefore, pages can get progressively complex in design and component flavors, just that this progression has to be closely matched in terms of asset delivery by designing your partitions.   The first page maybe simple, but delivers core part of the framework, and each subsequent page builds up on this quickly making the code base available completely to the client.

Page Design and Component Choices

Pages and Page template design are business driven, but evaluating the footprint of the graphical and interactive elements and making the right component choices for minimizing the page weight when achieving a design is important as well. To take full advantage of the partitions we created, we need to design our pages such that we stay within a single partition for each page, until all partitions are downloaded (which would be 4 page loads or less in our example).

Component choice is important because ADF Faces is designed to provide a rich UI component set with client side interactivity and therefore components and layouts are accompanied by their corresponding JavaScript as well. A highly interactive component like an af:table will have more JavaScript associated with it than a component with lesser interactive features, like an af:goButton.  Therefore the components you use to create the page have a direct impact on the size and number of JavaScript files downloaded. To minimize the page weight, we first need to ensure that we use components that have the minimum footprint for the functionality we need to achieve, and minimize the components flavors we use on any given page. Making the right component choices matter a lot when we are against very tight page weight limits.

To find the client side footprint of a component, you can visit the ADF component demo here: http://jdevadf.oracle.com and use firebug to introspect the size of each partition that is downloaded. The default partitions file will tell you what component features are included in each partition. Knowing the footprint of each feature, and what features are available in a partition will help you choose components and craft highly optimized partitions that minimize the page weight.

Since the client side footprint is tied to the components used, the variety of components used in the page or page template directly affect the footprint. Therefore, promoting component reuse in page and page template design is highly recommended. The following list highlights some of the component selection considerations.

For our example, the first thing to do is to create a new page template, using more light weight components and see what impact it makes.  Remember that the template markup is weaved into the page markup, and adds to the weight of the pages when page navigations are performed, therefore the leaner the template the smaller our footprint will be.  We used the new component af:PanelGridLayout to do our layout, and keep the template markup as lean as possible. We chose the OutputText and Go components since it has little to no client footprint, and List view instead of a table. To layout the ListView, we re-used the panel grid layout, so as to minimize component flavors. We also remove the composer tags, as we do not expect people to edit the pages on a mobile device. The example is constructed with 4 pages that demonstrate the phased delivery of the JavaScript assets. The landing page (home) requires only the initial partition. The Products page will pull in the basic partition as it contain input components, and the services page will pull in the essential partition as it uses regions. The ‘My Account’ page is protected, and has a ListView element on it as well. The example application does not use the desktop partition.

As we will be performing our own styling and not depend on the default portal skin, we switch back to the simple skin family. To reduce the skin size even more, we inhibit the generation of style classes that we do not intend to use, instead relying on our own styling. This effectively suppresses ADF’s built in styling for its components, and care should be taken to style all elements as required by the page design.

Our new template, with the new skin geared towards mobile delivery looks like this :

Using the new 4 phase partitioning, a minimalistic skin, and the page template that takes advantage of this partitioning, we see the following results for page weight :

We went from 12 JavaScript downloads to 5, and the total size for JavaScript went from 899.4 kB to 711.5 kB. These results can be further improved through HTTP tuning by setting cache headers and compressing the resources.

HTTP optimization is explained in George’s post. http://www.ateam-oracle.com/improving-webcenter-performance

After configuring OHS to compress responses, our results are much leaner, with the total page weight coming down to 209 kB and the JavaScript, just 174 kB.

The key element in this approach is the 4 phases of JavaScript delivery and the synergy we have created between this delivery model and page design that progressively uses more complex tags. Using the 4 JavaScript partition phases makes sure that only the minimally required assets are downloaded, and the page weight is always kept to a minimum.

Download the sample application

You can download the sample application here: LeanPortalSample

Please note that you need JDeveloper 11.1.1.7 to run this.

All content listed on this page is the property of Oracle Corp. Redistribution now allowed without written permission