Late last year Google announced that the next major update to the Page Rank Algorithm (search result indexing) will start taking into account the pages load (response time) see below:
This is introduce a major challenge while developing and hosting NZ/AU based web application, which many believe could be addressed using the following delivery techniques:
1) Identify your main landing pages for your primary key terms and define the most frequently managed content (banners, specials, news etc.) and push the container HTML out to the cloud managing the content using iframes or content deployment technologies (such as SharePoint).
2) Using more frequently updated pages with heavier functionality as link juice back into those primary fast loading landings pages.
3) Its been confirmed that both Bing and Google will not penalize on repeating content within sub domains (e.g. nz.mysite.com and au.mysite.com) allowing regional content and location related functionality to exist closer to its potential audience while containing similar data and templates.
4) Following the Latency Recommendations for AU/NZ based web pages for minimising the response time only to the one introduced as a result of router hops and distance.
2010 will be a good year for optimising South Pacific content, ensuring high ranking on future mobile device based search results(these will have only five relevant winners on the first page ;o)
Had an interesting biz tour in Seoul last month, pretty amazing growth in terms of GDP and Internet usage, once there LG and Samsung seems to be just the tip of the iceberg when looking into the local devices, service providers and wireless data infrastructure.
web mapping capabilities and internet UI (animation and front-end stuff) still has lots of potential giving the fact that the local script (Hangul) is all left to right with a nice reasonable 24 character set.. and could run Joomla almost out of the box!!
I have done a few speed/load tests from downtown Seoul, lots of router hops on a really good link, latency to NZ/AU was pretty big though..
I have stated looking into deploying Win2008 which made me do a bit of research on Ipv6 tunneling and coexisting it with IPv4.
Voice over IP can survive low bandwidth but has hard time with network latency (a human syllable averages 200ms-300ms) so choosing the best possible IP implementation will effect the transmitted voice quality), this makes AU/NZ VOIP a real interesting challenge.
These seem to be the main network/transport level solution I came across:
ISATAP: uses Dual-stack nodes to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP views the IPv4 network as a link layer for Ipv6.
Teredo: creates IPv6 connectivity by tunneling packets over UDP, Teredo service runs by sing “Teredo servers” and “Teredo relays”. Teredo relays act as IPv6 routers between the Teredo service and the native” IPv6 Internet.
6to4: treats the NAT box as a point to point link layer router into the native Ipv4 network and abstracts the global routing by using the NAT gateway as its Ipv6 termination point.
Tunnel Brokers: uses dedicated servers, called Brokers, to automatically manage tunnel requests coming from the Ipv6 client. Maps isolated IPv6 clients to agree on the routing tables used, allows the client to connect and activate IPv6 connections to other IPv6 by creating a virtual network between the Ipv6/IPv6 dual stack nodes. Dual stack users are nodes that can implement both protocols and uses the v4 implementation for the encapsulation mechanism.
From knowing how Cisco and Junipers are working together my guess will be that dual stack application level proxies (HTTP, SIP) that allows serving clients on both protocols will be the most common implementation in the short term (i.e. ISPs will be able to negotiate optional delivery methods over the available link and allow all types of client to receive the relevant service according to the clients protocol capabilities(blue coat seems to have a lot of research going in this direction)
This also make sense in terms of fighting latency as well since it allows efficient traffic over IPv6 on high bandwidth links (ISP to ISP) and last mile content proxy mechnism for optional clients (Win XP can do IPv6 from SP1).. VOIP will do the same with SIP termination points as the application proxy.
Some of my sites are hosted in Kansas City,MO which is a common location for many large data centers in the US, Kansas is a popular place for building data centers because it provides equal network latency for both east and west cost clients due to its central location (latency depends on the length of the actual link, i.e. how long is the transmitting optical fiber cable).
Kansas City was initially built because of the strategic confluence of the Kansas and Missouri rivers that provided good steam ship transport through the Mississippi-Missouri river.
Kansas City 1869
Being a large population center on the river it had one of the first major railroad bridges across the Missouri which made the city a major south to north east to west railroads hub
Once the optical fiber network infrastructure used by the core of today’s Internet was build, the public land of the railroad grid has been utilised for laying out the cables making it the new communication highway, Kansas once again became a major network/data center hub (all of this because the same bridge on the same old river..)
(source: colocationmontreal.com).
I am currently running most of my response time and web latency tests from Dallas and Kansas which provides extremely reliable results giving the infrastructure and location of those data centers.
This one speeds the loading of a mobile web page + full parsing of the interaction layer(Javascript) from 2600ms to 240ms (10 faster!!) on the same script block size(200KB)!!
Worth trying when customising web apps for moblies (which has good 3G bandwidth but really bad latency due to the transport over microwave).
Kansas City 1869
