At the time of this writing, Notes is listed as one of the top 2 million sites globally according to www.alexa.com. You can view the site information here: http://www.alexa.com/siteinfo/ecomware.com.

Two months ago, Notes was in the top 7M. Three months before that, it was in the top 4M. That’s a lot of change in six months.

One of the factors that causes ecomware.com (a micro blog with barely 50,000 readers annually) to rank so high is that it’s linked to from Liferay.com, and regarded as a good source for simple Liferay theme information. Link neighborhoods are important, and having embedded a link to myself in Liferay.com certainly helps ecomware’s visibility.

One of the factors that causes ecomware.com to rank so poorly, especially when it dropped into the 7M range, is caching. During the summer, I was experimenting with document freshness, and set the cache expiration date on the home page (the blog index page) to 14 days into the future. This, I assume, caused the major sites to believe the content was stale.

To speed up ecomware.com, I followed many of the well known steps for reducing latency. I consolidated and condensed the .js and .css that were part of the theme, and in cases where the pre-published source files are small, I simply embed them in the markup as part of the publishing action. This means I have just one include of each type. I also eliminate the head requests for these resources by using an expires header. I layer the real-time assets using AJAX. Subsequent page loads will cache at approximately 85-95%, and without head requests. I also use a publishing mechanism in front of Word Press to serve static pages so that I’m not incurring a real-time processing cost on each request. (Big frameworks have this already, but it’s simple enough to implement on a small scale.) I also leverage XML and XSLT on the client side. In cases where the presentation is almost identical across many assets, I cache a single XSLT file and serve literal XML data to the client. (The transformation creates a normal HTML DOM on the client side.)

The end result is that I can serve this site from a shared host/DB with reasonable performance (especially on subsequent loads) and still reap the benefits of good search ranking.