Don’t Gateway Static Content
In my last post, I talked about all the HTTP requests that are made during a single ALUI portal page request. One of the things you may have noticed was that all HTTP requests were routed through the portal and the portal gateway. In cases where you’ve got portlet HTML that needs to be aggregated on a page or transformed using Adaptive Tags, that is necessary.
However, content gatewayed through the portal by definition puts load on the portal server. A common mistake people make when publishing content is to put ALL content in the gateway space for a Publisher Content Item, including things like images, style sheets, and javascript files. This creates unnecessary load on the portal server, since it’s just acting like a proxy server and not really doing anything with the content it’s proxying.
Fortunately, Publisher offers an easy fix for this; it allows you to publish images to a separate target that can be outside the gateway space. That way, the HTML that you create in a Content Item can be gatewayed (so that it can be transformed and aggregated on a portal page), but the images can be placed on the image server. Then, when the browser needs to load all the associated images, it can get them directly from the image server, resulting in faster page load times and less load on the portal server – a win/win proposition.
To access these settings, simply right-click a folder in Publisher and go to "Publishing Target". There you can specify the other Publishing Target for Images.
Note that you shouldn’t just do this on your existing content without making sure the image links are set properly, because it’s possible that existing content uses links that point to the original publishing target. But it still could be worth the effort of fixing all those tags, given the performance benefits you’re likely to see.