Raheel Hussain : SEO

Working with AJAX - Part 2 - Speed & Page Size

Raheel Hussain — Thu, 03 Jan 2008 07:22:00 GMT

The Purpose of the AJAX (as also discussed by many writters and many websites) is to improve the user experience, as well as client centric operations and development. Instead of fetching the entire page contents, or displaying a completely new page, AJAX enables browsers to fetch and update/alter particular sections of page through the HTML, XML or through Javascript.

I launched my website all full with AJAX, though a very simple one, but it appeared to be very expensive in sense of it's loading time as well as data size.

I received couple of comments on my Guest Book as well as some of my collegues verbally told me of reducing the page load time, for atleast the home page.

Since then, I started doing my research on particularly reducing the page size and then in general, the appropriate combination of AJAX.

Consider the following general Scenario for your website size and images : -

Bigger than 60k in size : Your visitors will be unlikely to wait around and see your homepage.
50k to 60k : You visitors may see your first page, but may wary to wait and see second page.
40k to 50k : Better, but you may still loose visitors.
30k to 40k : Absolute, largest and serious sites would be.
20k to 30k : Responsive, and likely to get second visit.
10k to 20k : Very responsive and a pleasure for your visitors.

Obvisouly! my website had gone above 500k and it was Huge difference, and to make it shorter upto the mark, lots of changes were required.

Since the HomePage of your web-site is considered as a Gateway, that would lead you to the ( text and graphics based ) content. If the HomePage is very heavy just like what I have at http://www.raheelhussain.com/ , it is possible that the Search Engine Spider that might want to index your HomePage and entire site, might skip you (I mean your website) if it gets Timed Out while loading your page.

The page size of your HomePage for such a case (recommended by many experience webmasters) should be less than 125k.

While analysing my website, I found of couple of more things :

A huge amount of ViewState - Hidden Data
Due to AJAX implementation, the View State gets increased, unless we explicitly disable it on all occurances except wherever required.

Script Source Files with AJAX may increase your page size
When you use AJAX in your site, it includes lots of Script Sources files in the page sources, to support the functionalities like as follows :

<script src="/ScriptResource.axd?d=e0Z5w1xlI94kfI-ca3Wnd_wh0&t=633309435532426250" type="text/javascript"></script>

You will find a big number of References to such files... the more you use different AJAX functionalities on to the site.
So the recommendation is that you may use very less AJAX functionality on the HomePage at least.

Too many External Http Objects references.
To further explain this, each reference to an external file is refered as an external HTTP Object, You may take the example of http://www.google.ae/ or
http://www.yahoo.com/ as these sites are with very less references to external object and are really fast loading.

To demonstrate this, I went to http://www.websiteoptimization.com/services/analyze/ which is a free tool to analyze your site.
I did that for http://www.yahoo.com/ , http://www.google.ae/ and finally for my website http://www.raheelhussain.com/ for comparision.

Though the site for http://www.asp.net/ is also heavy, but my website (being very simple) was more havier than it.

You when you do it, you'll see the external object references, listed in a separate table.

Above is for http://www.yahoo.com/ and http://www.google.ae/ is even better with less load time.

Image sizes
Offcourse the image sizes need to be lesser unless there's really a need to put a bigger image file on the homepage.

And the Important One - The GuestBook
Since the Guestbook consumes/implements most of the AJAX functionalitiy. The conclusion to this is, that unless you do not have a requirement, keep all the
functionality in the inside pages, rather than keeping it on the Homepage.

Working out further, I gathered following Tips and Tricks to make a website, or at least the home page efficient and fast loading.

Fewer external Objects, means try to group them maximum into one combined, rather than many.

Turn on HTTP keepalives for external objects. Otherwise you add an extra round-trip to do another TCP three-way handshake for every HTTP request. If you are worried about hitting global server connection limits, set the keepalive timeout to something short, like 5-10 seconds. Also look into serving your static content from a different webserver than your dynamic content. Having thousands of connections open to a stripped down static file webserver can happen in like 10 megs of RAM total, whereas your main webserver might easily eat 10 megs of RAM per connection.

If your users regularly load a dozen or more uncached or uncacheable objects per page, consider evenly spreading those objects over four hostnames. This usually means your users can have 4x as many outstanding connections to you. Without HTTP pipelining, this results in their average request latency dropping to about 1/4 of what it was before.
Minimize HTTP response size by enabling gzip compression for HTML and XML for browsers that support it. For example, the 17k document you are reading takes 90ms of the full downstream bandwidth of a user on 1.5Mbit DSL. Or it will take 37ms when compressed to 6.8k. That's 53ms off of the full page load time for a simple change. If your HTML is bigger and more redundant, you'll see an even greater improvement.

I've implemented most of the changes on my website but it is yet to go live again.
Possibly by the end of this month.

Regards - raheel Hussain

References :
http://www.websiteoptimization.com/services/analyze/wso.php
http://www.websiteoptimization.com/services/analyze/

URL Rewriting (Part 3)

Raheel Hussain — Wed, 03 Oct 2007 08:13:00 GMT

This is offcourse linked to the last blog for URL Rewritting, some technical bits to be shared, a little enhancement to the previous technique to URL Rewriting and also an issue which could be a limitation (or more likely that a I'm unable to findout solution to it) for the way I implemented the URL Rewritting.

I had implemented the URLs with a directory structure strategy.
i.e. http://localhost:3648/Teams/
       http://localhost:3648/Teams/Pakistan/
       http://localhost:3648/Teams/India/
       http://localhost:3648/Teams/Sri-Lanka/

While going into live environment, I faced an issue and which (so far) I'm unable to resolve...

The issue was that when the page was redirected to a URL (say http://localhost:3648/Teams/Pakistan/) the images to be displayed in the page took the different relative path for the image URL and hence not displaying the picture.

For example:
If the image path was "images/testimage.jpg" then after URL Rewritting, it became as "Pakistan/images/testimage.jpg" and therefore misguiding the browser to retreive the image from a non-existent and wrong directory...

This led me to change my strategy towards URL Rewritting technique, and I rather switched to a slighly different URL Rewritting bit.

i.e. http://localhost:3648/Teams.aspx
       http://localhost:3648/Pakistan.aspx
       http://localhost:3648/India.aspx
       http://localhost:3648/Sri-Lanka.aspx
       http://localhost:3648/Hockey.htm
       http://localhost:3648/Tennis.shtml

From the SEO (Search Engine Optimization) point of view, this is still very useful URL.

I had to do the following change in the "Application_BeginRequest" event in global.asax file

Old Code:

    Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
        Dim strPath As String = Request.Url.ToString()
        If strPath.Contains("Pakistan/") Then
            Context.RewritePath("~/teampage.aspx?TeamID=1")
        ElseIf strPath.Contains("India/") Then
            Context.RewritePath("~/teampage.aspx?TeamID=2")
        ElseIf strPath.Contains("Sri-Lanka/") Then
            Context.RewritePath("~/teampage.aspx?TeamID=3")
        ElseIf strPath.Contains("Cricket/") Then
            Context.RewritePath("~/sportspage.aspx?SportID=1")
        ElseIf strPath.Contains("Football/") Then
            Context.RewritePath("~/sportspage.aspx?SportID=2")
        ElseIf strPath.Contains("Tennis/") Then
            Context.RewritePath("~/sportspage.aspx?SportID=3")
        ElseIf strPath.Contains("Hockey/") Then
            Context.RewritePath("~/sportspage.aspx?SportID=4")
        Else
            Context.RewritePath("~/default.aspx")
        End If
    End Sub

New Code:

    Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
        Dim strPath As String = Request.Url.ToString()
        If strPath.Contains("Pakistan.aspx") Then
            Context.RewritePath("~/teampage.aspx?TeamID=1")
        ElseIf strPath.Contains("India.aspx") Then
            Context.RewritePath("~/teampage.aspx?TeamID=2")
        ElseIf strPath.Contains("Sri-Lanka.aspx") Then
            Context.RewritePath("~/teampage.aspx?TeamID=3")
        ElseIf strPath.Contains("Cricket.aspx") Then
            Context.RewritePath("~/sportspage.aspx?SportID=1")
        ElseIf strPath.Contains("Football.aspx") Then
            Context.RewritePath("~/sportspage.aspx?SportID=2")
        ElseIf strPath.Contains("Tennis.shtml") Then
            Context.RewritePath("~/sportspage.aspx?SportID=3")
        ElseIf strPath.Contains("Hockey.htm") Then
            Context.RewritePath("~/sportspage.aspx?SportID=4")
        End If
    End Sub

Also, with the changes in the URLs i.e. Hockey.htm or India.aspx, you may also had noticed that I've removed the else condition, that was because, while when the browser is reading the image file, this function is called and the control directly goes to the else condition, while reading the image, and that lead the image URL to parse as default.aspx

Following is the snapshot of the application with the folder technique

Following is the new snapshot of the application with the URL (without folder)

With this strategy also, the limitations remain the same as discussed in previous post.
But as far as SEO is concerned this way or the previous one, we can acheive our targets.

The Server.Execute or Server.Transfer methods for instance, can be utilized at places where necessary but they would definetely show up with the original URL which was masked (re-written) but since the Top Level Menus of the website are using "response.redirect" method, it will still serve the purpose.

The project is the same consists of the following files

Global.asax
MasterPage.master
default.aspx
teampage.aspx
sportspage.aspx
web.config

The master page contains the menus (Four link buttons) each of which redirects to a different page (A dummy URL).

OLD Example Code:

    Protected Sub LinkButton1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton1.Click
        Response.Redirect("~/Cricket/")
    End Sub

    Protected Sub LinkButton2_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton2.Click
        Response.Redirect("~/Football/")
    End Sub

    Protected Sub LinkButton3_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton3.Click
        Response.Redirect("~/Tennis/")
    End Sub

    Protected Sub LinkButton4_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton4.Click
        Response.Redirect("~/Hockey/")
    End Sub

New Example Code:

    Protected Sub LinkButton1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton1.Click
        Response.Redirect("~/Cricket.aspx")
    End Sub

    Protected Sub LinkButton2_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton2.Click
        Response.Redirect("~/Football.aspx")
    End Sub

    Protected Sub LinkButton3_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton3.Click
        Response.Redirect("~/Tennis.shtml")
    End Sub

    Protected Sub LinkButton4_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton4.Click
        Response.Redirect("~/Hockey.htm")
    End Sub

------------------------

Although, this is one other way for implementing the URL re-writting, I'll will welcome to some one of you would find a solve to it to help me out
as well as I will be searching for it, and will update you if I find some resolution to that.

The change I did in the existing project can be downloaded by clicking URL_TEST_updated.zip
------------------------

There are other ways for the URL rewriting two, while IIS7 provides much better functionalities supporting the pageless URL re-writing

You can have a look at ScottGu's Blog to have an indepth view of what other ways are there for URL re-writing as well.
Othere Useful Links are
http://www.asp101.com/articles/matteo/urlrewriting/default.asp
http://www.mattcutts.com/blog/asp-net-2-and-url-rewriting-sometimes-harmful/

Cheers !

raheel Hussain

URL Rewriting (Part 2)

Raheel Hussain — Tue, 24 Jul 2007 00:51:00 GMT

URL rewriting can be performed by many techniques. Basically you need to decide the technique according of your requirements.

Every technique has its ups and downs. I tried using the HTTPModule approach by dynamically re-writing the URL.

This technique involves the usage of the "Application_BeginRequest" event in global.asax file

Whenever a file is requested, this event gets fired, before the requested page events. In the Application_BeginRequest, we need to check the requested URL and on the basis of that, re-write the URL with the HttpContext

Following is the snapshot of the application.

However, there are some limitations.

You cannot use server.transfer or server.execute methods.
The Server.Transfer require a relative path as well as the Server.Execute. Hense a virtual path within the virtual directory of application server is required.
You can notice this when you open the Braces to put the argument i.e. the path of the page that it asks for Path, while if you do the same with
response.redirect, it rather ask you for the URL. Therefore, a dummy address cannot be used with these two methods like what we do with response.redirect.
The normal Hyperlink controls cannot be used, instead, you need to use Linkbuttons or Buttons with response.redirect in their code
The reason for this is mainly because they hyperlinks doesnt cause the requested URL to change everytime they are clicked,while on the other hand with
response.redirect command in the code behind of the linkbutton tries accessing a page with its exact path.

for example:
by using the link button you would see the URL in the address bar as
http://localhost/myapplication/Products/
next time clicking on the same linkbutton will cause the same URL to be displayed.

on the other hand Hyperlink is treated differently with the URL rewriting technique
Hyperlink provides the existing URL in the address bar and the code concatenates another URL rewrite string with it.
Hense the URL in the address bar would end UP like as follows:
http://localhost/myapplication/Products/Products/Products ............... and so on with every click.

The project consists of the following files

Global.asax
MasterPage.master
default.aspx
teampage.aspx
sportspage.aspx
web.config

The master page contains the menus (Four link buttons) each of which redirects to a different page (A dummy URL).

For Example:

    Protected Sub LinkButton1_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton1.Click
        Response.Redirect("~/Cricket/")
    End Sub

    Protected Sub LinkButton2_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton2.Click
        Response.Redirect("~/Football/")
    End Sub

    Protected Sub LinkButton3_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton3.Click
        Response.Redirect("~/Tennis/")
    End Sub

    Protected Sub LinkButton4_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles LinkButton4.Click
        Response.Redirect("~/Hockey/")
    End Sub

None of the folder (the redirected url or folder) above in the response.redirect, actually exists.

While in the global.asax file following code is to be implemented:

    Sub Application_BeginRequest(ByVal sender As Object, ByVal e As EventArgs)
        Dim strPath As String = Request.Url.ToString()
        If strPath.Contains("Pakistan/") Then
            Context.RewritePath("~/teampage.aspx?TeamID=1")
        ElseIf strPath.Contains("India/") Then
            Context.RewritePath("~/teampage.aspx?TeamID=2")
        ElseIf strPath.Contains("Sri-Lanka/") Then
            Context.RewritePath("~/teampage.aspx?TeamID=3")
        ElseIf strPath.Contains("Cricket/") Then
            Context.RewritePath("~/sportspage.aspx?SportID=1")
        ElseIf strPath.Contains("Football/") Then
            Context.RewritePath("~/sportspage.aspx?SportID=2")
        ElseIf strPath.Contains("Tennis/") Then
            Context.RewritePath("~/sportspage.aspx?SportID=3")
        ElseIf strPath.Contains("Hockey/") Then
            Context.RewritePath("~/sportspage.aspx?SportID=4")
        Else
            Context.RewritePath("~/default.aspx")
        End If
    End Sub

As you can see that, upon detecting the requested URLs which are dummy to show to the user, the context.rewritepath() method to actually determine that what is the underlying page to be redirected.

The querystrings which are not visible to the user in the address bar are used the same way as they are to be used.

You can download the code by clicking on the following link.URL Rewriting Demo

------------------------

There are other ways for the URL rewriting two, while IIS7 provides much better functionalities supporting the pageless URL re-writing

You can have a look at ScottGu's Blog to have an indepth view of what other ways are there for URL re-writing as well.
Othere Useful Links are
http://www.asp101.com/articles/matteo/urlrewriting/default.asp
http://www.mattcutts.com/blog/asp-net-2-and-url-rewriting-sometimes-harmful/

Cheers !

raheel Hussain

URL Rewriting (Part 1)

Raheel Hussain — Sun, 22 Jul 2007 08:22:00 GMT

During one of the projects I did, I was asked for having URLs like YAHOO or GOOGLE for an intranet application and believe me that before that requirement came out, although I knew that there would've been some technology, but never bothered to check that out.

Since now I've already done it, let me explore in my blog what I've learnt so far, as well as your comments and views are most welcome, and even the corrections.

URL REWRITING is a technique through which you rename/re-write the URLs which are displayed in the web browser's address bar.

There are many advantages of URL rewriting technique. Following are the listed advantages of the URL re-writing:

1 - Simplicity.
2 - Security & Hiding the Technology
3 - SEO (Search Engine Optimization)

(Simplicity) Simplified URLs:

Consider a following URL
http://websitename.com/products/productindex.aspx?flag=y&date1=120107&date2=150107&tabid=5&hidepicture=true
If the above URL goes changed to the following...
http://websitename.com/products/listings.apx ...... then wouldn’t that be fantastic ??

This is an easy to remember as well as simple URL, and we can count it as a plus-point of URL re-writing.

Security & Hiding the Technology:

Many of you have probably noticed that the dynamic pages hosted by Yahoo or even Google have no extensions for the pages like
mypage.aspx or products.asp, etc. but you can see .htm on Google at some places, where there are some static content coming through the
CMS (may be).

There are many reasons to it, simply it can be said that the extensions of the pages, provide way for the hackers and let them think what they can do.

As well as the query strings can also help them out in different ways.

SEO (Search Engine Optimization):

SEO is a very important base for the success of any website (of the business). And URL rewriting is one very strong aspect of it. Lets try this out with a small example.

Go to http://www.google.com/ and type "Football" in the search box.

You will notice the following results.

Listed at 1st Place : www.football.com/
Listed at 2nd Place : http://news.bbc.co.uk/sport1/hi/football/default.stm
Listed at 3rd Place : http://en.wikipedia.org/wiki/Football_(soccer)
Listed at 3rd Place : http://en.wikipedia.org/wiki/American_football

In the above results, I guess there is very little to explain about, as you can notice the URLs. Not necessarily all the pages which came out of the search are static, but static pages are always top in the queue for search engine as compare to the dynamic pages, I cannot change it for you :)

But if we do have a search engine friendly URL, it would definitely find its place up on the top 10 or at least top 15.

In my next blog I would provide some working examples...

STAY TUNED.......................

cheers !

raheel Hussain