Jeffrey Janner wrote:
Thanks for all the suggestions so far guys.
Are there any other tips I could provide to the developers that they can
do to improve throughput?
Should they hard-code the http:// for all the static elements to avoid
passing them over SSL,
If these items are not sensitive, that /could/ be a good idea, except
that IE is probably going to bother your users no-end, popping up
friendly warnings that this site is switching between secure and
non-secure pages, so they'll probably wonder which brain-dead designer
came up with this scheme.
or do my security constraints take care of that?
(I doub it.)
You're right to doubt, they will do nothing of the kind.
The original URL gets redirected to https immediately, so I'm thinking
everything from there on out is SSL. Correct?
Yes, inasfar as links in html pages are concerned. You have to look at
it from the browser's point of view. When it sees an "incomplete" link,
it completes it using the protocol and hostname from which the current
page was obtained, and then it requests that object.
Can I get more granular? I'd be happy for a pointer to a good reference
on the subject.
There are probably tons on Google, if you look for "website
optimi[z,s]ation" or the like.
Personally, I have found that a very large proportion of websites on the
WWW are slow because their designers just /don't think/. If loading
each page requires 10 or more requests to the server and you fail to
organise stuff so that it can be cached by the browser, then you should
not be surprised that your site feels slow. But it never ceases to
amaze me how many sites ignore the simple common-sense principles.
I would bet that carefully examining what you are actually sending in
your pages and cleaning it up would yeld more benefits, faster, than
playing around with protocols, compression and the like.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
