Technische schuld op een website is de optelsom van alle keuzes die ooit werden gemaakt omdat het snel moest. Een plugin erbij omdat er die week geen tijd was voor iets beters. Een stukje code rechtstreeks in het thema omdat de bouwer met vakantie ging. Een functie die niemand meer gebruikt maar die nog wel elke pagina laadt.
Los is elk van die keuzes verdedigbaar. Bij elkaar leveren ze na een paar jaar een site op waar niemand nog iets in durft te veranderen, omdat niemand weet wat er dan kapotgaat. Dat is geen slordigheid; dat is hoe het bij vrijwel elke site gaat die lang meegaat.
Hoe technische schuld op een website ontstaat
Er zijn vier gebruikelijke routes, en u herkent er waarschijnlijk minstens twee.
De stapel plugins. U wilde een schuifbalk met logo’s, dus kwam er een plugin. Later een andere voor formulieren, en nog een voor pop-ups. De eerste twee gebruikt u niet meer, maar niemand durft ze weg te halen “want misschien staat er ergens nog iets op”. Zo staan er zes jaar later drieëndertig plugins actief, waarvan er zestien nooit worden aangesproken.
De aanpassingen in het thema. Iemand zette een codefragment rechtstreeks in het themabestand in plaats van in een child-thema. Bij de eerstvolgende themaupdate is dat weg, dus wordt de update overgeslagen. Vanaf dat moment staat het thema stil, en dat is een van de vervelendste vormen van schuld: het blokkeert al het andere.
De opeenvolging van bouwers. Drie bureaus in acht jaar. Elk met eigen voorkeuren, eigen paginabouwer en eigen manier van opmaken. Het resultaat is een site waarin dezelfde knop op vier manieren is gemaakt, met vier stukken CSS die elkaar overschrijven.
De pagina’s die nooit weggingen. Actiepagina’s, oude vacatures, een landingspagina voor een beurs uit 2019. Ze staan nog online, worden nog geïndexeerd, en gebruiken nog steeds een plugin die u anders had kunnen verwijderen.
Wat het u werkelijk kost
Het bedrag staat nergens op een factuur, en juist daarom wordt het onderschat. Vier vormen van kosten.
Elke wijziging duurt langer. Een tekstaanpassing is nog steeds vijf minuten. Maar een nieuwe pagina in de stijl van de rest kost bij een opgeruimde site een uur en bij een dichtgeslibde site drie, omdat er eerst uitgezocht moet worden hoe het elders is gedaan.
De risico’s stapelen. Meer plugins is meer code van derden, dus meer kans dat er ergens een lek zit. Verlaten plugins zijn daarbij het grootste risico. Hoe u die eruit pikt, staat in het opsporen van plugins die niet meer onderhouden worden.
De site wordt trager. Niet dramatisch, maar gestaag. Elke plugin voegt bestanden toe en doet databasevragen. Dat effect is bekend en wordt uitgelegd bij de invloed van het aantal plugins op de laadtijd.
Niemand durft nog wat. Dit is het duurste en het minst zichtbare. Op een gegeven moment wordt “we laten het maar zo” het standaardantwoord. De site staat stil terwijl uw bedrijf doorgaat, en dat kost u aanvragen zonder dat er ooit iets kapot is gegaan.
De nuance: niet alle schuld hoeft weg
Hier ga ik tegen het gebruikelijke advies in. Er wordt vaak gedaan alsof elke rommelige constructie opgeruimd moet worden. Dat is niet zo, en het is meestal ook niet verstandig.
Schuld die u gerust laat staan:
- Werkende maatwerkcode die niemand aanraakt. Als dat stukje al vijf jaar zonder problemen zijn werk doet en het staat niet in de weg, laat het staan.
- Een verouderde opmaak op een pagina die vier bezoekers per jaar krijgt. Herbouwen kost geld en levert niets op.
- Een plugin die technisch niet mooi is maar wel actief onderhouden wordt. Vervangen brengt eigen risico’s mee.
De vraag is niet “is het netjes”, maar “houdt het mij ergens van af”. Blokkeert een constructie een update, een beveiligingsmaatregel of een wijziging die u wilt doen, dan is het een probleem. Doet het dat niet, dan is het gewoon oude code, en daar is niets mis mee.
Afbouwen zonder alles te herbouwen
Een volledige herbouw klinkt aantrekkelijk en is bijna altijd de duurste route. U betaalt dan namelijk ook opnieuw voor alles wat wél werkte. Een gefaseerde aanpak levert meestal meer op:
- Maak een inventarisatie. Zet elke actieve plugin op een rij met de vraag: waar staat dit op de site en wanneer is het voor het laatst bijgewerkt? Dit kost een middag en levert vaak direct een lijst van tien overbodige onderdelen op.
- Ruim in een testomgeving op, nooit direct. Zet plugins uit, kijk wat er gebeurt, en pas dan verwijderen.
- Los eerst wat u blokkeert. Zit het thema vast door aanpassingen die niet in een child-thema staan, begin daar. Dat maakt alle volgende stappen mogelijk.
- Ruim één ding per maand op. Twee uur per maand is genoeg om een site in een jaar merkbaar lichter te maken, zonder dat er een project van gemaakt hoeft te worden.
- Leg vast wat u doet. Een simpel document waarin staat waarom een plugin er is en wie welke code heeft geschreven, voorkomt dat de volgende beheerder opnieuw niets durft.
Dat laatste is misschien wel de goedkoopste maatregel die er bestaat. Het grootste deel van de verlamming komt niet door de code zelf, maar doordat niemand meer weet waarom hij er staat.
Wanneer wel opnieuw beginnen
Er is een grens. Kost een normale wijziging structureel het viervoudige van wat u redelijk vindt, staat de PHP-versie vast omdat de code niet meer meekan, of is de site niet meer met een telefoon te bedienen zonder herbouw, dan is opnieuw beginnen goedkoper dan doorlappen. Reken daar wel eerlijk aan: zet de kosten van herbouw naast twee jaar geleidelijk opruimen en kijk wat er overblijft.
Wat de meeste sites uiteindelijk redt, is niet een grote schoonmaak maar een klein, vast ritme. Dat is ook precies wat wij in beheer met vaste opruimmomenten per kwartaal inbouwen: elke drie maanden een half uur voor wat er niet meer nodig is. Zo groeit de stapel niet aan, en blijft de site iets waar u wél iets in durft te veranderen.
