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.
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.
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.
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.
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).
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.
|Panel Grid Layout|| |
|Very versatile layout component that uses rows and cells to layout components. This component is the preferred general layout component as it offers a small client side footprint while being very flexible in layout capabilities.|
|Go Components||N/A||The Go Components like GoButton, GoLink have little to no client side footprint since they do not carry client side functionality. |
They are also preferred over command components (command button, command link) for general navigation in portals for the fact that they enable SEO friendly URLs.
|List View|| |
|The ListView is a new component that is rendered similar to a table. A Table's client side footprint is about 80kB while the ListView is about 9kb. |
This component offers significant savings on the client side footprint while offering functionality similar to that of a table, when all of the Rich Table's functionality is not required.
|OutputText||N/A||The output text has little to no footprint since there is no client side behavior and should be preferred over a Label component in most cases.|
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 :
HTTP optimization is explained in George’s post. http://www.ateam-oracle.com/improving-webcenter-performance
You can download the sample application here: LeanPortalSample
Please note that you need JDeveloper 126.96.36.199 to run this.