Freigeben über


SYSK 178: A Simple Way to Improve Performance of a Secure Web Site

If I had to choose one performance optimization technique for a web site that uses SSL, such that it gives me the biggest value compared to a relatively small effort (the proverbial low hanging fruit), the answer would be simple – improve cacheability of your content by separating secured and unsecured content into different folders.

 

From a performance perspective, SSL handshake and encryption/decryption create an additional processing layer, beyond regular HTTP processing (for those who are interested, there is a good article at http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/ssl_performance.mspx for SSL capacity planning).  So it only makes sense that you should only use Secure Sockets Layer (SSL) for pages that require it.  By having image files and other content that does not have to be secured in a separate folder, you not only avoid the SSL overhead such as encryption/decryption, but also can leverage client and/or server side caching of that content.

 

For other recommendations on how to improve performance of a web site, check out “Checklist: ASP.NET Performance” at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/scalenetcheck03.asp.

Comments

  • Anonymous
    August 15, 2006
    The problem with putting your images in locations that are not under SSL is that your visiters will receive a warning stating that part of the site isn't secure.  You don't want to put doubt in your users.
  • Anonymous
    August 22, 2006
    Scott's comment is right on... A better solution may be to reduce the number of images on the pages that are protected with SSL.

    However, I do have a concern about only having certain pages with SSL. SSL is supposed to be transparent to the application. So, if you have to redirect the visitor to a secure page, that actually involves coding the "https" prefix, which at that point makes SSL less transparent to the application than it can be.

    The other reason of course is to continue to protect the cookies. Proctecting only the login page of a site will protect the username and password from being intercepted. If you later send the cookie over an unencrypted connection, that cookie could still be intercepted and used maliciously. There are of course ways to protect cookies, but some of these also require the application code to be modified, which makes the security less transparent.