De site migratie checklist

       @yoast    26544 x bekeken

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.

1

Gepost in: Usability & Design

14 Reacties

Handig! Gaat del.ici.ous in.

Vooral de tip over javascript (zowel voor nieuwe als bestaande sites) is essentieel. Het gebeurt regelmatig dat ik de relevante content van een pagina niet snel genoeg zichtbaar krijg vanwege op zich laten wachtende reclames en andere externe content. Alleen al dat geeft reden genoeg om een adblocker te installeren.

Wat betreft hosting: wij hebben een tijdje gedacht aan een server in Amerika vanwege de extreem lage kosten voor extreem veel ruimte en bandbreedte. In wat voor omgevingen is zoiets wel en niet aan te raden?

geplaatst op om 12:33 uur

Als je site van ip-adres wisselt houdt dan ook rekening met de tijd die het duurt voordat de DNS wijzigingen overal bekend zijn (ca een dag) In deze periode ziet de ene gebruiker de oude site en de andere de nieuwe. Dit kan allerlei consequenties hebben, denk aan een reactie plaatsen op de oude site die niet zichtbaar is op de nieuwe of bestellingen die van twee systemen kunnen komen.

Hosten in States is niet zo'n punt. Google let er volgens mij weinig op (m'n sites staan in de usa en ik scoor uitstekend) en de bandbreedte is vergelijkbaar met die in Nederland (op de site van xs4all verzadig ik mijn adsl verbinding met 780 kb/s, naar mijn hoster in de states haal ik 650 kb/s)

Wat je wel merkt zijn de veel langere pingtijden. Als je veel bestanden in een pagina verwerkt zal die daardoor trager laden. Ook 'web 2.0' en 'ajax' dingen als automatische zoek suggesties werken iets minder soepel maar nog steeds goed. Veel van deze minpunten zijn overigens goed te ondervangen.

geplaatst op om 12:46 uur

@Inge & Willem: let op met die hosting in de States... Dat kan wel degelijk redelijk lastige gevolgen hebben voor je zoekmachine rankings... Zeker als je een reeds bestaande site verhuist van NL naar de US.

geplaatst op om 12:59 uur

@Inge: de belangrijkste overweging is waar je publiek zit. Hoe dichterbij hoe beter. De hoeveelheid bezoekers (en dus traffic) speelt ook zeker mee. Wat Willem aangeeft is ook van belang, met veel AJAX interactie in de site wil je een zo laag mogelijke netwerkvertraging. Het javascript punt is te omzeilen door afhankelijk van de browser de javascript code aan te passen om te zorgen dat zaken 'semi' asynchroon worden geladen.

@Willem : de locatie is uiteindelijk zeker wel van belang; bij een hogere netwerk vertraging (latency) ontstaat er meer packetloss waardoor je effectieve bandbreedte afneemt. Nu valt de latency naar de VS tegenwoordig nog mee, maar bij latency's hoger dan 300ms krijg je sterke beperking in je feitelijke doorvoersnelheid.

geplaatst op om 13:34 uur

@Joost: verhuizen heb ik geen ervaring mee. Wel met een aantal sites met een .nl extensie en landneutrale domeinextensies als .net (met doelvermelding in webmastertool) die in usa gehost zijn vanaf het begin. En die doen het SEO technisch dus prima. Ben overigens wel benieuwd op welke specifieke problemen je doelt.

@Eelco: klopt als een bus. De manier waarop een host verbonden is met NL zal ook invloed hebben op de latency. De waarden van twee hosters waar ik gebruik van maak(te) zaten tussen de 100 en 150 ms en dat is dus laag genoeg om op een heel acceptabele doorvoersnelheid uit te komen.

Als de keus tussen een nederlandse en amerikaanse provider is met zelfde kwaliteit, service en prijs (in die volgorde) zou ik overigens ook voor de nederlandse hoster kiezen.

Zijn er trouwens al nederlandse aanbieders van 'cloud-hosting'?

geplaatst op om 13:52 uur

@Willem Joosten: de specifieke problemen waren enorme ranking dalingen :) Overigens was dat wel voor de tijd van de mogelijkheden voor doelvermelding in Google Webmaster tools.

geplaatst op om 14:00 uur

@ Willem, Joost en Eelco: bedankt voor de uitleg. Ik vermoedde al dat voor websites die veel interactie vereisen tussen client en server dit pijnlijk(er) ligt.

Dat je ranking er ook door beïnvloed wordt wist ik niet, maar er is op zich wel iets voor te zeggen: de kans dat een NL-site die in NL staat ook echt is (en geen automatisch aangemaakte reclamesite vol irrelevante content) is groter dan bij de combinatie NL-site die in Amerika staat. Niettemin fijn om dit bevestigd te horen.

geplaatst op om 14:09 uur

@Willem: Yup, wij bieden onder de noemer jitscale clouddiensten aan. We doen dit transparant in eerste instantie op een eigen cloud infrastructuur en Amazon's EC2. In mei hebben we dit 'officieel' aangekondigd en begin augustus gaat de eerste infra over deze cloud van clouds live!

geplaatst op om 14:26 uur

Mooi overzicht Joost en Eelco, thx!

Ton Wesseling gaf naar aanleiding van bovenstaande de volgende checklist op webanalisten.nl:

1. Meet in een nieuwe omgeving
2. Zorg dat alles wordt gemeten en dat de funnels / kpi’s en dashboard goed zijn ingesteld
3. Vergelijk niet wat je niet kunt vergelijken
4. Vergelijken in de eerste week na lancering heeft geen zin
5. Meet je redirects
6. Extreme controle op pagina laadtijden en 404’s
7. Sta niet stil bij het verleden

geplaatst op om 07:33 uur

Dit blijft een probleem waar veel bedrijven zich op verkijken. In mijn eigen vakgebied (o.a.) seo is dit ook een groot probleem wanneer men compleet overgaat naar een nieuw design (of zelfs al gedeeltelijk).

Jullie noemen al een aantal punten op dit gebied (vooral de eerste paar). Zelf heb ik hierop ook wat aanvullende punten geschreven in een artikel met tips voor het migreren van je website van een half jaartje terug. Deze is niet zozeer zwaar technisch zoals een paar punten hier (en ik lees ook wat redelijk technische migratie tips in de reacties), maar op marketing gebied zeker interessant om mee te nemen.

Overigens vind ik tip 1 toch wel het schrijven van zo'n migratieplan met alle punten. Weten hoe je de dingen aan gaat pakken (eerst denken dan doen) vind ik essentieel.

geplaatst op om 12:53 uur

Zo'n checklist is absoluut verplichte kost voor ontwikkelaars en projectleiders. De projecteindverantwoordelijke moet goed doordrongen zijn van het nut en de noodzaak hiervan, dit is een van die dingen die het verschil maakt tussen echt professioneel bezig zijn en een beetje op goed geluk dingen doen.

Knelpunten goed in kaart brengen, aan de hand daarvan bewuste en weloverwogen keuzes maken en het hoe en waarom duidelijk vastleggen in documenten. Zorg dat benodigde competenties aanwezig zijn of haal anders de juiste expertise in huis. Dit hele proces neemt natuurlijk tijd in beslag maar bespaard je veel problemen en daardoor uiteindelijk veel tijd, geld en nog belangrijker, de immer ongrijpbare goodwil.

geplaatst op om 22:24 uur

"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."

Is hier Linux software voor beschikbaar?

geplaatst op om 17:05 uur

It's a great information to read out.

geplaatst op om 04:32 uur

te verwerven voor geld de eigenschap van een ding. Het kan ook worden gedefinieerd als een operatie uitgevoerd om een behoefte te voorzien. Binnen een organisatie aankopen kan worden gedefinieerd als activiteiten die worden voorgesteld om, in de best mogelijke omstandigheden voor de verschillende sectoren van het bedrijf, materialen (grondstoffen en afgewerkte producten, accessoires, consumptiegoederen, machines, diensten, enz. .), met het minimum dat nodig is nodig is voor een bedrijf, dat wil zeggen prijs, kwaliteit, leveringsvoorwaarden en betalingsvoorwaarden die nodig zijn om de doelstellingen die de administratie heeft het vastgelegd te bereiken.

geplaatst op om 00:12 uur

Plaats een reactie

Log in zodat je (in het vervolg) nóg sneller kunt reageren

  • Maximaal 5000 karakters. Basis HTML tags zoals <a> zijn toegestaan.

  • Let op: je reactie blijft voor altijd staan. We verwijderen deze dus later niet als je op zoek bent naar een nieuwe werkgever (of schoonmoeder). Reacties die beledigend zijn of zelfpromotioneel daarentegen, verwijderen we maar al te graag. Door te reageren ga je akkoord met onze voorwaarden.