Further Suggestions - Speed Week, Day 4

Note to self - If you're going to start a week of speed tips, make sure you have at least five things to talk about.

Over the last three days I've talked about some fairly solid techniques for improving speed. What else can we do though?

Today I'll offer some suggestions and then open it to the floor for others. Tomorrow I'll summarize any suggestions I think worthy of more attention and further investigaion.

Browser Cache
Obviously the user's browser is out of our control binvestigationut there are things we can do at server level to help the browser know what to cache. For example, see Chris Linfoot's blog about agressive caching of images on a Domino server using Web Site Rule documents.
Storing File Resources
If you are using the YUI library or something similar that's comprised of dozens - if not hundreds - of files then it's worth considering using the Domino\HTML directory on the server. Why keep all these files inside the NSF!? If the database requires authentication then there's the obvious overhead involved in each request for a resource contained within a secured database. Alternatively place them in a separate library database so other applications can share them and save downloading more than once for each app.
Persistent Connections
Browsers can make a lot of requests all at once for files from a server. You can tweak this but have to keep in mind that the server can only respond to so many at once. This (I think) is governed by the Persistent Connections settings on the server document. Anybody? Increasing the allowed number should theoretically increase speed.
SSL Redirections
The client website I was reviewing has SSL enabled by default. In fact the "homepage" setting for their domain redirected all requests to https://cliient.com/site.nsf. Not only does the redirect slow things down but the use of SSL also has a performance overhead to consider. Unless you really need to use SSL, don't.

Can anybody think of anything else that should be mentioned?


  1. Good week Jake.

    Speeding applications involves a lot of considerations, from server tunning to coding for speed.

    I didn't hear you mention GZIP as an option to speed up traffic between servers and browsers. Compressed content travels faster of course and almost all the new browsers can deal with GZIP. I don't have more facts about it but I've heard that is useful. even Brendon has a product (Web Booster) to help out with speeding applications, but I don't know if it apply for the new versions of Domino that includes GZIP support.

    Anyways, there's a lot of best practices that can be implemented to seed up applications. Thanks for resuming them here!



    • avatar
    • Julien
    • Thu 29 Mar 2007 10:36 AM

    In this iNotes tunning article {Link} we can see that enabling GZIP is not always a good choice and can be sometimes negative.

    I'm not sure it's a really good option.

  2. Alex, I think you might have ruined tomorrow's post. ;-)

  3. Julien, you can still encode individual files yourself and create some web site rules to served those.

    {Check Tim's take on this {Link}

  4. You could just claim that you sped up the postings and finished the week early. :-)

    Re: hosting YUI libraries outside the NSF, for public internet applications you could just use the Yahoo! hosted versions. This was a relatively recent announcement over at the YUI blog: {Link}

    and {Link}

    They include version numbers in filepaths (a good idea for everyone's own libraries when doing the aggresive caching thing) so you can use the version you've developed/tested against on an ongoing basis.

    • avatar
    • Michael Bourak
    • Thu 29 Mar 2007 12:33 PM

    I've seen very few people leverage domino server side caching. It's an heritage of 4.61 evolution, has a lot of caveats (only for anonymous request, for certain domino urls etc...) but can be a real performance boost (by caching the generated HTML by domino, server side, for a defined period of time)

    I've begged IBM to enhance it (so it may behave like Websphere dynacache in terms of flexibility but it never happened).

  5. I agree, server side caching can do wonders (especially usefull for public sites), but you have to carefully design your application with server-side caching in mind before you build it :)

    Another great trick regarding client side caching and response-headers (that really makes a difference) is the one from Tomas Nielsen:


Your Comments


About This Page

Written by Jake Howlett on Thu 29 Mar 2007

Share This Page

# ( ) '


The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social

About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content