De site migratie checklist

Regelmatig komen we het tegen, of lees je er over, sites die net na de live-gang van een nieuwe versie, een deel van de site uit moeten schakelen, de oude site weer terug moeten zetten, of andere nood oplossingen moeten toepassen. Verder gebeurt het nog regelmatig dat een nieuwe site live komt, en dat alle oude links naar die site dan niet meer werken. Dat is te voorkomen! Deze checklist, opgesteld door Joost de Valk van Onetomarket en Eelco van Beek van IC&S is bedoeld om bedrijven (of individuen) te helpen die een nieuwe versie van hun reeds bestaande site willen lanceren.

Oude URL’s redirecten

In de meeste gevallen komt een nieuwe website ook gepaard met nieuwe URL’s. An sich is dat geen probleem, ware het niet dat mensen gelinked hebben naar die oude URL’s, en dat zoekmachines die oude URL’s in hun index hebben staan. Je ontkomt er dus niet aan al die oude URL’s te laten doorverwijzen naar hun nieuwe equivalenten, door middel van 301 redirects. Als dat niet gebeurt, verlies je alle waarde van alle links die je had opgebouwd…

Er zijn vele voorbeelden bekend van websites die nog maar 20/30% van hun website traffic uit zoekmachines overhielden na een migratie, zorg dat u dat niet overkomt!

Rankings op belangrijke keywords

Een nieuwe website betekent ook vaak een nieuwe huisstijl, en nieuwe teksten. In sommige gevallen zelfs nieuwe productnamen. Door teksten te veranderen, en pagina’s een andere naam te geven, kan het zijn dat je rankings in de zoekmachines kwijt raakt op termen die wel heel relevant verkeer brachten. Kijk dus altijd eerst goed in je analytics voor je producten een andere naam geeft, en maak absoluut zeker dat je geen belangrijke rankings verliest.

Hosting in het juiste land

Voor zoekmachines is het steeds belangrijk dat een domein gehost wordt in het land waar de website voor bedoeld is. Ook voor gebruikers levert dat vaak veruit de beste ervaring op. Ga dus niet bij de overgang naar een nieuwe site eens kijken of de hosting in de VS niet een stuk goedkoper is, want dan zou goedkoop wel eens hele dure koop kunnen worden.

Whois gegevens niet aanpassen

Het is geen goed idee om op het moment dat een website volledig wordt aangepast en nieuwe hosting krijgt, ook even de “whois” gegevens, de eigendoms-gegevens van het domein, aan te passen. Zoekmachines hebben de nare neiging om sites waarvan alles in 1 keer veranderd, te beschouwen als een website die verkocht is. Ze behouden zich dan het recht voor om die website zijn rankings volledig opnieuw op te laten bouwen, en alle “oude” waarde er van af te halen. Ook dat is een situatie die je absoluut wil vermijden.

Meten is weten

Voor de live-gang is het essentieel om eerst te bepalen wat de feitelijke capaciteit is van de site of applicatie. Met diverse programma’s (bijv. jmeter) kan er op een eenvoudige manier een gebruiker op de site worden gesimuleerd. Door meerdere van dit soort simulaties tegelijk te draaien en ondertussen de omgeving op diverse onderdelen te monitoren kan worden vastgesteld hoeveel gebruikers het platform maximaal kan verwerken. Op basis hiervan kan een eventueel schalingsplan worden opgesteld.

Let op: er wordt, vooral op grote sites, nogal eens vergeten om zoekmachine bot verkeer mee in te schatten, dat kan bij een nieuwe versie van een grote site behoorlijk hoog oplopen, tot het spideren van duizenden pagina’s per uur. Een goed idee is het dan om A dat mee te nemen in performance tests, en B zoekmachines als Live en Yahoo! pas op een later moment volledig toegang te geven, en ze in eerste instantie een crawl delay te geven.

Zijn gebruikers zichtbaar in site performance? Opschalen!

Het is altijd verstandig om constant te meten wat de gebruikerservaring (in termen van effectieve snelheid) van een site of applicatie is. Hierdoor kunnen snel bepaalde kritische vertragingen (DNS resolving, bandbreedte, aantal connecties, HTML) worden opgespoord. Is er bijvoorbeeld verschil zichtbaar in site responsetijd bij metingen doordeweeks en in het weekend (waarbij de site doordeweeks meer bezocht wordt dan in het weekend) dan is dit vaak een aanleiding om op te schalen. De hoeveelheid gebruikers (zonder tegen de maximale capaciteit aan te lopen) mogen geen zichtbare invloed hebben op de resultaten in een performance meting! Een voorbeeld van zo’n meetoverzicht is hier te vinden.

Er is altijd iets te cachen

Cachen is het tijdelijk opslaan van (onderdelen van) websites of webpagina’s door een tussenliggende omgeving. Wanneer een stukje informatie dat reeds door de cache is opgeslagen wordt opgevraagd dan hoeft de applicatie voor het genereren van deze content niet opnieuw belast te worden. Websites en -applicaties hebben altijd onderdelen die gecached kunnen worden. Dit geldt ook voor dynamische content waarbij gebruikers specifiek voor de gebruiker gegenereerde content voorgeschoteld krijgt. Neem als voorbeeld een forum. Een forum is statisch tot het moment dat er een reactie of een nieuw forum bericht wordt geplaatst. Bij een dergelijke actie kan een cache worden geïnstrueerd om dat specifieke deel opnieuw te laden. Daarnaast zijn er bijvoorbeeld caches die op basis van het type content (bijv. plaatjes, video of volledig statische teksten) informatie voor een bepaalde tijd kunnen cachen.

Zet gebruikers en servers zo dicht mogelijk bij elkaar

In Nederland is er een populair dataverkeer uitwisselingspunt genaamd AMSIX. Dit uitwisselingspunt koppelt providers aan de gebruikerszijde met gebruikers aan de contentzijde om content en gebruikers zo dicht mogelijk bij elkaar te krijgen. Over het algemeen geldt namelijk de regel dat hoe korter (gemeten zowel feitelijke afstand als in aantal tussenliggende koppelingen) de netwerk afstand tussen 2 punten hoe sneller de informatieoverdracht tussen die punten. Voor sites in Nederland met gebruikers in Nederland geldt dus: maak vooral gebruik van de AMSIX. Voor sites in het buitenland dient goed gekeken te worden hoe een applicatie uiteindelijke zo dicht mogelijk bij de gebruiker geplaatst kan worden. Een mogelijkheid hierbij is het gebruik van Content Delivery Networks (CDN). Zij plaatsen (delen van) de content zo dicht mogelijk bij de eindgebruiker. Een bekend voorbeeld van een omgeving die hier gebruik van maakt is bijvoorbeeld de iTunes music store van Apple.

Er is altijd iets te cachen, ook aan de achterkant

Veel webapplicaties en -sites maken gebruik van gecentraliseerde dataopslag, bijvoorbeeld op basis van een database. Tegenwoordig kennen vrijwel alle databases het begrip querycaching; als dezelfde query meerdere keren voorkomt, en de dataset is niet veranderd, dan wordt de query feitelijk niet uitgevoerd; het resultaat van de query komt dan uit de cache. Naast het cachen van queries in de database zelf kunnen ook de connecties van de applicatielaag naar de database gecached worden (in principe is dit niet caching, maar hergebruiken van bestaande verbindingen: connectionpooling). Het creëren van een verbinding is namelijk een tijdrovend proces.

HMTL of HTML

Volgorde in HTML is belangrijk. Wordt er javascript in de site gebruikt? Let dan op dat javascript het laden van componenten verder in de HTML code blokkeert totdat alle componenten in de javascript code zijn geladen. Tools als Pagetest maar ook Yslow op Firebug geven hier (en ook op een aantal van bovenstaande punten) veel inzicht.

Video? niet te snel

Een video wordt afgespeeld met een bepaalde hoeveelheid bits per seconde (bitrate, dit is voornamelijk afhankelijk van de codec en kwaliteit van de video). Zorg dat wanneer een bepaalde video wordt opgevraagd deze door de server geleverd wordt met iets meer bits/seconde dan de bitrate van de video, anders wordt de download snelheid bepaald door de bandbreedte van de kijkers. Aangezien veel mensen tegenwoordig minimaal een DSL verbinding wordt het aantal kijkers beperkt. Neem het volgende voorbeeld. Er is een internet bandbreedte beschikbaar van 100/s mbit. 10 gebruikers met DSL verbinding kunnen dan downloaden met 10 mbit/s. Op dat moment wordt de gehele beschikbare bandbreedte voor deze 10 gebruikers ingezet. De video heeft echter een minimale afspeelsnelheid van 256 kbit/s. Door die video met bijvoorbeeld 350 kbit / sec te versturen is de gebruikerscapaciteit naar ruim 290 gebruikers. Let wel: deze gebruikers maken wel langer gebruik van de capaciteit. Een tussenweg is dat bijvoorbeeld de eerste 10 seconde van de video op volledig beschikbare snelheid worden doorgestuurd om vervolgens te vertragen naar een lagere snelheid.

Werkt de applicatie in een wolk?

De nieuwe hype rondom internet infrastructuren is het zogenaamde cloud computing. In principe is een cloud niets anders dan een grote hoeveelheid aan elkaar gekoppelde computers waarop virtuele computers ‘on-the-fly’ kunnen worden afgenomen. Men hoeft alleen af te rekenen naar daadwerkelijk verbruikt. Voordeel van deze aanpak is dat er niet van te voren hoeft te worden geïnvesteerd in een compleet platform. Door de applicatie zo in te richten dat het zichzelf schaalt door bijvoorbeeld bij een bepaalde capaciteitsbehoefte zichzelf te dupliceren op een nieuwe virtuele computer (autoscaling). Dit is een erg interessante ontwikkeling voor platformen waarvan de populariteit moeilijk valt in te schatten; de investeringen zijn laag en het platform, mits goed opgezet, heeft een enorme capaciteit. Animoto is een voorbeeld van een dergelijk platform, in dit geval gebaseerd op de Amazon EC2 cloud.