out any leading and trailing whitespace from JSP pages. That allows the JSP pages to be
developed and maintained with correct (for humans, at least) indentation, but without
paying the penalty for transmitting all that needless whitespace over the network.
As a developer, it makes sense to keep CSS resources in separate files; they are easier to
serve up those resources, it is much more efficient to send one larger file rather than sev-
eral smaller files. There is no Java EE standard for this, nor is there a way to do it auto-
matically in most application servers. But there are several development tools that can
help you combine those resources.
Compress the output
From the perspective of the user sitting at her browser, the longest time in executing a
web request is often the time required to send the HTML back from the server.This is
something that is frequently missed in performance testing, since performance testing
between clients (emulating browsers) and servers often occurs over fast local-area net-
works. Your actual users might be on a “fast” broadband network, but that network is still
an order of magnitude slower than the LAN between the machines in your lab. Most ap-
plication servers have a mechanism to compress the data sent to the browser: the HTML
data is compressed and sent to the browser with a content type of zip or gzip . This is
done only if the original request indicates that the browser supports compression. All
modern browsers support that feature. Enabling compression requires more CPU cycles
on the server, but the smaller amount of data usually takes less time to traverse the net-
work, yielding a net improvement. However, unlike the other optimizations discussed in
this section, it is not universally an improvement; examples later in this section show that
when compression is enabled on a LAN, performance may decrease. The same is true for
an application that sends very small pages (though most application servers will allow
output to be compressed only if it is larger than some specified size).
Don't use dynamic JSP compilation
By default, most Java EE application servers will allow a JSP page to be changed on the
fly: the JSP file can be edited in place (wherever it is deployed), and those changes will
be reflected the next time the page is visited. That's quite useful when a new JSP is being
developed, but in production it slows down the server, since every time the JSP is ac-
cessed, the server must check the last modified date on its file to see if the JSP needs to
be reloaded. This tunable is often called development mode, and it should be off in pro-
duction and for performance testing.