Improving the performance of the JSPs that serve your HTML pages is the first step in improving the overall site performance. The user’s browser can not start rendering the page or requesting the secondary media. Also the faster the page request is completed, the sooner you have a thread free to handle the next request.
There are two parts to this: first, the time it takes the JSP servlet to generate the HTML response, and secondly the time it takes to transmit that HTML response back to the user’s browser.
Caching content sections
The easiest way to reduce the time it takes for the JSP servlet to generate the response is by reducing the amount of dynamic content on the page. Or more precisely by reducing the amount of real-time or unique individual content on the page.
The Cache droplet is THE most under-utilized ATG droplet.
The Cache droplet caches the rendered output of the contents of the oparam based on a content key (such as category, user gender, logged in/logged out state, etc..) for a configured period of time. This can be very useful for things like navigation menus dynamically built based on the catalog. The catalog won’t change too often, so this dynamically generated menu can be safely cached for hours. Or for some or all of a category or product page, when you set the key to the category id or product id.
Look at your pages and evaluate what parts of the page don’t change that frequently. Even if you can only cache the page or block for five minutes, that can be a huge performance win.
Read on for more….
I’ll talk about things like repository caching and other related topics when I dive into the server side of performance tuning your ATG application in a future post.
Reduce CPU utilization in page rendering
You’re also going to want to look at potential CPU draining elements of your pages. Think about what has to happen to render the page. Don’t use RQLQueryForEach if you have the Repository Id you want, just use the RepositoryLookup droplet. Don’t loop through collections if you don’t have to. Think through it. If you have to do something computationally expensive, don’t do it twice. If you need the same data later just store the first result in a param or JSP variable.
Reduce the size of the HTML
Now that we’ve reduced the CPU time need to render the JSP, we need to reduce the amount of time it takes to transmit to the end user. First, we want to shrink the generated HTML. The smaller the output HTML is, the less time it will take to transfer across the wire to the end user. Also, you want to keep the HTML output under 100k, as Google does not index page content over the first 100k (that’s 100k ungzipped). Also, the smaller the HTML is, the quicker the browser can parse it out into the DOM tree.
Simplify the html structure as much as you can. Don’t use more tags than you need. I’ve seen an amazing amount of useless nested divs on pages.
Move comments from HTML comments to JSP comments (if you can). Most comments shouldn’t be seen by end users anyhow.
Reduce spaces. This is huge. JSPs (especially ones heavy in ATG droplets) tend to generate a huge amount of extraneous spaces. Part of it is that you generally want to format the JSP files using spaces and tabs to make it easy to see the tag hierarchy structure. It makes development and maintenance much easier. Unfortunately these linefeeds, tabs, and spaces get multiplied by iterative or recursive droplets, and other outputs.
If you’re using JBoss the Tomcat engine has an option to strip out extraneous whitespace. It doesn’t remove all of it, but it helps with multiple blank lines very well. In the tomcat55.sar/conf/web.xml file add the following init param to the <servlet-name>jsp</servlet-name> section: