How does the theme influence the performance of the Portal site?
The theme influences both the server side and client side performance. Whenever a Portal page is rendered the theme is included on the server. The theme defines the layout and structure of the site – including various static files like javascript, pictures, css, and others. It also triggers the rendering of portlets, widgets or other content. Depending if the theme is a client side or server side theme the requests that are sent after the initial rendering of the Portal in the browser also differ – a server side theme will trigger full server side rendering requests including the theme again with each request while the client side theme would trigger a larger number of small dynamic requests that will update the layout to the newly selected page and its portlet content.
When trying to optimize the performance of the theme one needs to think about both about the time spent on the server as well as the time on the client side. On the server side it is all about execution of code on the server that can take up processing power and memory. This can be analyzed with profiling tools like the Java Health Center or Jprof or … Also the number of requests influences the server side response - if an excessive amount of requests is sent it will slow down the server.
On the client side the performance of the site is determined by the rendering of the returned markup. The markup links to static resources. The static resources can contain javascript, pictures, css, and others. Time is not only spent for the download of those resources but also in the interpretation of the loaded javascript and css. The more complex the css and javascript is the more time is spent in the browser for parsing and execution.
Tools like Firebug or Development Console from other browsers typically allow to determine how much time is spent on the download as well as the rendering of the resources.
My recommendation is to check the time spent for the loading of the page and then optimize the slowest parts. If the main Portal request (typically to .../wps/myportal/... unless you changed the context root) is taking too long you would need to check what is slow on the server side. Most of the other resources being rendering are referenced by the theme or the portlets on the page.
This article does not cover basic tuning tips like ensuring that compression is enabled on the web or proxy server and that the correct cache headers are being set for static resources to prevent subsequent downloads of static resources. Both tunings have a large impact on the theme performance and should be enabled. Please see the Portal tuning guide for more information on those topics:
1. Removing unused features
Features that can be disabled to improve performance:
-
Semantic Tagging
-
Menu Service and People Tags
-
Disabling Page Builder Functionality completely
Note that you should not disable those features if you are using them in your theme or portlets. The file locations are specified here for the default theme. You should modify the files in your own theme and not the default ones as they will be overwritten when you apply fixes.
How to remove semantic tagging from the theme:
Modify the file init.js inside your theme - by default the file is part of webdav in the folder js:
Before:
lgr.trace(mname, "Adding live text config entries for decorations and semantic tagging");
/* Add live text service configuration entries for layout control decorations and semantic tagging */
var livetextEntryAdded = "/com/ibm/mashups/livetext/configentryadded";
var decorationsEntry = new com.ibm.mashups.livetext.ConfigEntry("*.component-control", true, "com.ibm.pb.decorations",
ibmConfig["com.ibm.mashups.contextroot.builder"]+"/js/com/ibm/pb/decorations","com.ibm.pb.decorations.DecorationManager", true);
var configEntryAction = new com.ibm.mashups.livetext.ConfigEntry(".com\\.ibm\\.portal\\.action", false, "portallof",
"/wps_semanticTag/javascript", "portallof.vcard", false, "com.ibm.portal.action");
var configEntryVCard = new com.ibm.mashups.livetext.ConfigEntry(".vcard", false, "portallof","/wps_semanticTag/javascript", "portallof.vcard", false, "hcard");
var configEntryC2aSourceTarget = new com.ibm.mashups.livetext.ConfigEntry(".c2a\\:source,.c2a\\:target", false, "portallof",
"/wps_semanticTag/javascript", "portallof.vcard", false, "c2a");
dojo.publish(livetextEntryAdded,[decorationsEntry]);
dojo.publish(livetextEntryAdded,[configEntryAction]);
dojo.publish(livetextEntryAdded,[configEntryVCard]);
dojo.publish(livetextEntryAdded,[configEntryC2aSourceTarget]);
After:
lgr.trace(mname, "Adding live text config entries for decorations and semantic tagging");
/* Add live text service configuration entries for layout control decorations and semantic tagging */
var decorationsEntry = new com.ibm.mashups.livetext.ConfigEntry("*.component-control", true,
"com.ibm.pb.decorations", ibmConfig["com.ibm.mashups.contextroot.builder"]+"/js/com/ibm/pb/decorations","com.ibm.pb.decorations.DecorationManager", true);
var livetextEntryAdded = "/com/ibm/mashups/livetext/configentryadded";
if ( ibmCfg.themeConfig.disableSemanticTagging == false ) {
var configEntryAction = new com.ibm.mashups.livetext.ConfigEntry(".com\\.ibm\\.portal\\.action", false, "portallof",
"/wps_semanticTag/javascript", "portallof.vcard", false, "com.ibm.portal.action");
var configEntryVCard = new com.ibm.mashups.livetext.ConfigEntry(".vcard", false, "portallof","/wps_semanticTag/javascript",
"portallof.vcard", false, "hcard");
var configEntryC2aSourceTarget = new com.ibm.mashups.livetext.ConfigEntry(".c2a\\:source,.c2a\\:target", false, "portallof",
"/wps_semanticTag/javascript", "portallof.vcard", false, "c2a");
dojo.publish(livetextEntryAdded,[configEntryAction]);
dojo.publish(livetextEntryAdded,[configEntryVCard]);
dojo.publish(livetextEntryAdded,[configEntryC2aSourceTarget]);
}
dojo.publish(livetextEntryAdded,[decorationsEntry]);
In the theme which will be used, modify the
/PortalServer/theme/wp.mashup.cc.theme/installedApps/wp.mashup.cc.theme.ear/PageBuilder2.war/themes/html/PageBuilder2/config.jsp file to add the disableSemanticTagging: true json parameter to themeConfig, for example:
<script type="text/javascript">
(function(){
ibmCfg.controllers = {<%-- controllers initialized in com.ibm.themes.PageBuilder2.init
--%>rendering: null,<%--
--%>navigation: null,<%--
--%>dnd: null<%--
--%>};
ibmCfg.userName = "<portal-fmt:out escape="json">${wp.user[ccConfig['cc.enabler.user.displaynameattribute']]}</portal-fmt:out>";
dojo.mixin(ibmCfg.themeConfig, {<%--
--%>editModeJSURL: "${dojoRoot}/com/ibm/themes/PageBuilder2/theme.edit.js",<%--
--%>themeUniqueName: "<%=((Theme)pageContext.getAttribute("currentThemeObj", PageContext.REQUEST_SCOPE)).getObjectID().getUniqueName()%>",<%--
--%>skinRootURI: stripTrailingSlash("<%=getStaticUrl(pageContext, "skinRootURI")%>"),<%--
--%>themeRootURI: stripTrailingSlash("<%=getStaticUrl(pageContext, "themeRootURI")%>"),<%--
--%>commonResourcesRootURI: stripTrailingSlash("<%=getStaticUrl(pageContext, "commonResourcesRootURI")%>"),<%--
--%>isRTL: false,<%--
--%>disableSemanticTagging: true,<%--
--%><%
if((Boolean)pageContext.getAttribute("isRTL", PageContext.REQUEST_SCOPE)) {
%>isRTL: true,<%
}
%>isPageRenderModeCSA: <%=pageContext.getAttribute("isPageRenderModeCSA", PageContext.REQUEST_SCOPE)%>,<%--
--%>navHiddenMetadata: <json:array value='<%=(List)pageContext.getAttribute("navHiddenMetadata", PageContext.APPLICATION_SCOPE)%>'/>,<%--
In that same file, comment out the line which causes the semanticTagService.js file to be loaded:
<script type="text/javascript" src="/wps_semanticTag/javascript/semanticTagService.js"></script>
In the WebSphere Application Server admin console, the Live Object Framework application can be stopped. Be sure to set the application so that will not start automatically when portal is re-started.
How to remove the Menu Service and People tags from the theme:
Edit the file PortalServer\theme\wp.mashup.cc.theme\installedApps\wp.mashup.cc.theme.ear\PageBuilder2.war\themes\html\PageBuilder2\config.jsp:
Remove the following two lines in the file:
<menu:menuinit/><c:if test="${empty sametimeProxyUrl && isAuthenticated}"><pa:peopleinit/></c:if>
<c:if test="${empty sametimeProxyUrl && isAuthenticated}"><pa:peopleend/></c:if>
Disabling Page Builder Functionality completely:
Disabling the Page Builder Functionality completely yields the highest reduction in included javascript code and javascript execution on the client. The disadvantages are that the following functionality will stop working (not a complete list):
- client side aggregation
- portlet menu
- page context menu
- theme edit page functionality
- active site analytic
The page context menu and portlet menu can be added in again by providing the functionality on the server side - similar to what the default administration Portal theme is doing.
Edit the theme.html or theme_.html (e.g. theme_en.html) and remove the following lines:
<script type="text/javascript">
dojo.addOnLoad(function(){
com.ibm.pb.themes.commonInit({
setWindowTitle:false, // title is set by the head dynamic content spot
useNavigationController: true,
useRenderingController: true,
useDNDController: true,
initLiveTextService: true,
lazyLoadModeWidgets: true,
navPrimingContainers: ["selectionPathPrimer","topNavLinks","navTabsRoot"],
customInit: com.ibm.themes.PageBuilder2.init
});
dojo.publish("com.ibm.portal.theme.portlet_ready"); // notifies ASA that portlet IDs are ready to be found in the DOM
});
</script>
Also make sure to remove all instances of the tag ibmLayoutContainersHidden from the file or the portlets will not show any more.
Edit the file PortalServer\theme\wp.mashup.cc.theme\installedApps\wp.mashup.cc.theme.ear\PageBuilder2.war\themes\html\PageBuilder2\config.jsp:
Remove the following two lines in the file:
<script type="text/javascript" src="<%=pageContext.getAttribute("dojoContextRoot", PageContext.REQUEST_SCOPE)%>
/layerLoader.jsp?path=v1.4.3/com/ibm/themes/PageBuilder2&name=theme&locale=
<%=pageContext.getAttribute("preferredLocale", PageContext.REQUEST_SCOPE)%>
<%="true".equals(getCCConfigValue(pageContext, "cc.isDebug", null)) ? "&uncompressed=true" : ""%>"></script>
<script type="text/javascript">
ibmCfg.themeConfig.contextMenus.bannerLinks = <r:dataSource uri='<%=pageContext.getAttribute("themeWebDAVBaseURI", PageContext.REQUEST_SCOPE) +
"menuDefinitions/bannerLinks.json"%>' escape="none"><r:param name="pragma" value="cache"/></r:dataSource>;
</script>
<script type="text/javascript" src="<%=getStaticUrl(pageContext, "init.js")%>"></script>
<script type="text/javascript" src="<%=getStaticUrl(pageContext, "init.js")%>"></script>
2. How to combine css files
The more different css file being loaded the more requests the browser has to send and also the longer the rendering will take as typically the browser will load all referenced css files before starting to render. Combining the css files improves the performance by avoiding many server roundtrips to fetch the files.
There are several options how to combine css files - from simple copying the contents to creating a jsp that combines the files on the server.
Combining the files on the server has the advantage that the css files can still be easily maintained separately without requiring a copy process every time.
The following simple sample jsp shows how to possibly combine css files on the server (the sample only includes one css file). Note that the include tag only works for css files that are part of the same ear file. To avoid having one jsp per application I would recommend to move the different css files to a central application.
<%@ page session="false" buffer="none" %>
<%@page contentType="text/css" %>
<%
HttpServletResponse httpResponse = (HttpServletResponse) response;
httpResponse.setHeader("Cache-Control", "public;max-age=86400");
httpResponse.setDateHeader("Expires", System.currentTimeMillis() + 86400000);
%>
<jsp:include page="com/ibm/widgets/css/widgets_combined.css" />
The included code sets cache headers and includes one css file - you would want to include as many css files as possible that are used on the site.
The created jsp would be included in the theme via a normal stylesheet reference - for example:
<link rel="stylesheet" href="/mycontextroot/css-combiner.jsp" type="text/css" />
Note that some browsers can have limitations on the length of the css file / number of style rules or tags. You might need to split up the css inclusion file into multiple files in that case.
3. How to combine pictures
Each request for a picture takes additional time as it causes another server roundtrip. By combining pictures into one picture and using CSS to specify the width and length of the single images to extract them it is possible to lower the amount of requests. This technique is called CSS Spriting. There are several tools available that can perform this process automatically and generate the combined picture file and CSS style sheet.
4. How to combine javascript / dojo requests
The Portal Page Builder theme includes dojo as javascript library and also integrates a few more javascript files. So called layers have been built in dojo to reduce the amount of single requests to additional js files containing additional required javascript logic.
To combine javascript files multiple options are possible - one can manually combine the files, or use a similar concept as we used with css writing a jsp that combines the files or use the native capabilities of the javascript library that is used to combine javascript files. This article focuses on dojo so I will explain how to use the dojo profiles.
Independent of the technique used it is recommended to minify the combined javascript fileto remove unnecessary spaces and breaks. Different tools are available to perform this task.
Portal is building custom profiles to reduce the amount of separate javascript files being loaded. It is possible to create your own custom profiles and include the built js file inside the theme.
The following document describes how to build custom profiles in dojo.
You can follow this article that explains on how to perform a dojo profile build - ignore replacing the dojo version and just update the portal_dojo_143.profile.js, adding your own layer and rebuilding:
The disadvantage of this method is that you will have to maintain a separate dojo ear file and also reference it in the theme.