Waarom je QR-code zo lang doet over de redirect (en hoe je dat oplost)

Waarom je QR-code zo lang doet over de redirect (en hoe je dat oplost)

Iemand opent zijn camera, de QR-code wordt in een fractie van een seconde gescand, en dan... een laadicoontje. Twee seconden. Drie. De pagina laadt uiteindelijk, of niet, en de scanner heeft zijn telefoon dan al weer opgeborgen. Als je ooit hebt gezien dat een campagne van een klant onderpresteerde ondanks een mooi ontworpen code op een goede plek, is de snelheid van de redirect een van de meest onderschatte oorzaken.

Elke dynamische QR-code hangt af van een reeks kleine technische stappen tussen het scannen en het laden van de pagina. De meeste bureaus kijken daar nooit naar, omdat het onzichtbaar is tenzij je er specifiek naar zoekt. Deze gids laat zien wat er echt gebeurt in die tussenliggende stappen, welke onderdelen de moeite waard zijn om op te letten, en hoe je je eigen redirect-keten controleert voordat je tienduizend codes drukt die allemaal naar dezelfde trage link verwijzen.

Wat er echt gebeurt tussen een scan en een geladen pagina

Een statische QR-code, een die rechtstreeks een bestemmings-URL codeert zonder trackinglaag, stuurt de telefoon van de scanner meteen naar dat adres. Een dynamische QR-code, het type dat ScanKit en de meeste serieuze campagnetools genereren, codeert in plaats daarvan een korte trackingurl. Dat maakt de bestemming aanpasbaar nadat de code al gedrukt is, en dat is precies wat de redirect-keten introduceert waar dit artikel over gaat.

De volgorde ziet er zo uit:

1. De camera decodeert de QR-code en geeft de URL door aan het besturingssysteem.
2. Het besturingssysteem opent de standaardbrowser van de telefoon, of, als de scan vanuit een app zoals Instagram, TikTok of een berichten-app gebeurde, de ingebouwde in-app-browser van die app.
3. De browser zoekt de domeinnaam op (DNS-lookup) en onderhandelt een beveiligde verbinding (TLS-handshake).
4. De browser vraagt de trackingurl op. De server registreert de scan en stuurt vervolgens een HTTP-redirect naar de echte bestemming.
5. Als er een tweede trackinglaag in de keten zit, bijvoorbeeld een losse analyticspixel of een link-shortener van derden tussen het QR-platform en de bestemming, herhalen stap 3 en 4 zich.
6. De browser volgt de laatste redirect en begint de bestemmingspagina te laden.

Geen van deze stappen is op zichzelf traag. Het probleem is dat ze na elkaar plaatsvinden in plaats van tegelijk, en dat elke stap een volledige rondreis naar een server toevoegt voordat de volgende kan beginnen. Twee of drie stappen op elkaar gestapeld is het punt waarop een scan die instant zou moeten aanvoelen, kapot begint te voelen.

301 of 302: het redirecttype dat de meeste mensen verkeerd gebruiken

Elke redirect heeft een HTTP-statuscode die de browser (en zoekmachines) vertelt om welk type redirect het gaat. Voor QR-campagnes zijn 301 en 302 de twee die ertoe doen, en bureaus grijpen vaak naar de verkeerde.

Een 301 (Moved Permanently) vertelt de browser dat de bestemming definitief is veranderd. Browsers mogen die reactie voor onbepaalde tijd cachen en de redirect bij het volgende bezoek volledig overslaan, door direct naar de gecachete bestemming te springen zonder de server opnieuw te raadplegen.

Een 302 (Found), of zijn strengere neefje 307 (Temporary Redirect), vertelt de browser dat de verhuizing tijdelijk is. De browser wordt geacht elke keer opnieuw bij de server te checken in plaats van de bestemming te cachen.

Dit onderscheid is enorm belangrijk voor dynamische QR-codes, omdat het hele punt van een dynamische code is dat je kunt wijzigen waar hij naar verwijst nadat hij gedrukt is. Als je QR-platform (of een link-shortener die je er tussenin hebt gezet) een 301 stuurt, kan een telefoon die de code één keer heeft gescand de oude bestemming lokaal in de cache krijgen en je update simpelweg nooit zien, ook niet nadat je de campagne in je dashboard hebt aangepast. De scanner ziet dan geen bug in je campagne; hij ziet een verouderde cache zonder vervaldatum die jij niet in de hand hebt.

Gebruik 302 of 307 voor elke QR-code waarvan de bestemming ooit kan veranderen. Bewaar 301's voor het zeldzame geval waarin de bestemming van een code echt permanent is en je wilt dat zoekmachines of aggregators die als gezaghebbend behandelen. Als je een bestaand QR-platform of een redirectservice die je er voor gezet hebt aan het auditen bent, check de responsheaders, niet alleen de marketingtekst, om te bevestigen welke er daadwerkelijk verstuurd wordt.

Wat kost elke tussenstap eigenlijk?

Dit is waar veel online adviezen vaag worden of getallen verzinnen die geen steek houden. Hier is wat wel meetbaar is, en wat niet.

DNS-lookup en TLS-handshake zijn echte, meetbare kosten, maar ze variëren te veel om er één getal op te plakken. Ze hangen af van het netwerk van de scanner (4G, 5G, publieke wifi), of het domein al gecachet is bij de resolver van zijn provider, en of jouw redirectservice achter een CDN draait. Het enige dat de data duidelijk laat zien: TLS-handshakes zijn merkbaar sneller wanneer een domein achter een CDN-edge draait dan wanneer de verbinding rechtstreeks een origin-server moet bereiken, en mobiele verbindingen voegen op beide punten doorgaans aanzienlijk meer overhead toe dan vast breedband. Behandel elk specifiek millisecondegetal dat je ergens tegenkomt voor "gemiddelde DNS-lookuptijd" hoogstens als een vuistregel, niet als een specificatie.

Elke extra redirectstap voegt een volledige rondreis toe, niet alleen verwerkingstijd. De browser moet een verzoek versturen, wachten op een reactie, en dan het hele verbindingsproces opnieuw starten voor de volgende server in de keten als het een ander domein is. Richtlijnen van zoekmachines over redirectketens (oorspronkelijk geschreven voor SEO-crawlbudgetten, maar het onderliggende mechanisme is identiek voor een scannende telefoon) adviseren consequent om ketens zo kort mogelijk te houden en behandelen alles voorbij drie of vier stappen als een teken dat er iets verkeerd is geconfigureerd, niet als een bewuste keuze.

Wat dit in de praktijk betekent: een QR-code die rechtstreeks van scan naar één trackingredirect naar de bestemming gaat, is snel. Een QR-code die via een redirect van het QR-platform, dan een losse URL-shortener, dan een marketinganalyticspixel en uiteindelijk de landingspagina loopt, heeft al drie of vier opeenvolgende rondreizen gestapeld voordat de scanner iets ziet. Elke van die tussenstappen is onzichtbaar op een screenshot van de uiteindelijke pagina, maar heel merkbaar in hoe lang de scanner moest wachten om daar te komen.

Waarom die wachttijd meer uitmaakt dan het lijkt

Het is verleidelijk om een extra seconde laadtijd te zien als een klein ongemak. De data over mobiel gedrag zegt iets anders. In een van de grootste onderzoeken van dit soort analyseerden Google en DoubleClick ongeveer 900.000 mobiele landingspagina's en ontdekten dat 53% van de bezoeken wordt afgebroken als een mobiele pagina langer dan drie seconden nodig heeft om te laden. Hetzelfde onderzoek liet zien dat de kans op afhaken sterk toeneemt, meer dan verdubbelt, als de laadtijd oploopt van één naar tien seconden.

Een QR-scan is een nog minder vergevingsgezind moment dan een gemiddelde klik op een mobiele advertentie. De scanner heeft al de moeite genomen om zijn telefoon te pakken, de camera te openen en de code te richten. Hij staat voor een poster, een menukaart of een product, vaak zonder sterke reden om te blijven wachten als er niets snel gebeurt. Elke redirectstap die je toevoegt tussen de scan en de pagina, kost je goodwill die je niet makkelijk terugkrijgt, en dat gebeurt nog voordat de laadtijd van je eigen landingspagina überhaupt in beeld komt.

In-app-browsers voegen een onbekende factor toe die je niet zelf in de hand hebt

Als iemand je QR-code scant vanuit een app in plaats van de camera van zijn telefoon of een aparte QR-scanner, bijvoorbeeld een code die gedeeld wordt in een Instagram Story of geopend via een QR-scanner die in TikTok is ingebouwd, opent de bestemming vaak in de ingebouwde browser van die app in plaats van de standaardbrowser van de telefoon. Deze in-app-browsers zijn niet identiek aan een normale mobiele browser. De veelgeciteerde analyse van beveiligingsonderzoeker Felix Krause uit 2022 liet zien dat verschillende grote apps, waaronder Instagram en Facebook, hun eigen JavaScript injecteren in elke pagina die in hun in-app-browser wordt geladen, en dat de iOS-in-app-browser van TikTok op dat moment elke toetsaanslag en aanraking op externe websites die daarmee werden geopend, registreerde.

Er is geen solide publieke benchmarking over precies hoeveel vertraging die geïnjecteerde code toevoegt; wees dus sceptisch over elk specifiek getal dat je tegenkomt voor "overhead van in-app-browsers". Wat wel vaststaat: in-app-browsers zijn een black box die je niet controleert, met extra code die je niet zelf hebt geschreven, op een renderengine die zich anders kan gedragen dan Safari of Chrome. Als een aanzienlijk deel van de scans van je campagne waarschijnlijk vanuit sociale apps komt, bijvoorbeeld een QR-code die vooral via een Instagrampost wordt gepromoot, is het de moeite waard om je landingspagina specifiek in die in-app-browsers te testen in plaats van aan te nemen dat een gewone browsertest dat afdekt.

Hoe audit je je eigen redirect-keten

Je hebt geen gespecialiseerde tools nodig om te zien wat er echt gebeurt tussen een scan en een geladen pagina. Een paar praktische checks:

• Volg de keten handmatig. Plak de trackingurl van je QR-code in het netwerkpaneel van een browser (het tabblad Network van Chrome DevTools, met "Preserve log" aangezet) en kijk hoe elke redirect afgaat. Tel de tussenstappen. Alles voorbij de eigen trackingredirect van je QR-platform en de uiteindelijke bestemming is de moeite van het bevragen waard.
• Check de statuscodes, niet alleen de bestemming. In datzelfde netwerkpaneel klik je elk redirectverzoek aan en bevestig je of het 301, 302 of 307 teruggaf. Als je 301's ziet op een link die je later nog wilt bijwerken, is dat een cachingprobleem dat vroeg of laat de kop opsteekt.
• Timen met curl. Door curl -w "%{time_redirect} %{time_total}\n" -o /dev/null -s -L <je-trackingurl> in een terminal te draaien, krijg je de daadwerkelijke tijd die aan het volgen van redirects is besteed versus de totale verzoektijd, zonder dat browseroverhead de getallen vertroebelt.
• Test vanaf een echte telefoon op een echte verbinding. Vast breedband en kantoorwifi laten bijna elke redirect-keten prima lijken. Test op 4G, en als een aanzienlijk deel van je publiek scant vanuit sociale apps, test specifiek binnen de in-app-browsers van die apps.
• Vraag je af waar elke tussenstap eigenlijk voor dient. Als de redirect van je QR-platform naar een losse analyticsredirect leidt voordat de bestemming wordt bereikt, vraag je af of die analyticslaag de scan niet in één stap kan registreren en doorsturen in plaats van twee. Minder tussenstappen is niet alleen sneller, het betekent ook minder plekken waar een kapotte integratie een scanregistratie kan laten vallen of dupliceren, wat net zo belangrijk is voor de nauwkeurigheid van je rapportages als voor scanmetrics die je bij een klant kunt verantwoorden.

De korte versie

De redirect-keten van een dynamische QR-code is onzichtbaar op een screenshot, maar heel merkbaar in hoe lang een scanner moet wachten voordat er iets gebeurt. Gebruik 302- of 307-redirects, nooit 301, voor elke code waarvan de bestemming kan veranderen, want een gecachete permanente redirect kan herhaalscanners stilletjes laten stranden op een oude bestemming. Houd de keten waar mogelijk beperkt tot één trackingstap; elke extra redirect tussen het QR-platform en de landingspagina is een volledige rondreis die de scanner moet uitzitten voordat je landingspagina überhaupt begint te renderen. Wees sceptisch over specifieke millisecondegetallen voor DNS of in-app-browseroverhead, maar neem het onderliggende mechanisme wel serieus: minder tussenstappen, correct getypeerd, is zowel sneller voor de scanner als betrouwbaarder voor je tracking. Volg voor je volgende drukronde de redirect-keten van je eigen QR-code in het netwerkpaneel van een browser en tel de tussenstappen. Zijn het er meer dan twee, dan weet je wat je moet fixen.

Veelgestelde vragen

Waarom doet mijn QR-code zo lang over de redirect?

De meeste vertraging komt van gestapelde redirectstappen, niet van één specifieke trage stap. Een dynamische QR-code codeert een trackingurl, die doorstuurt naar de bestemming. Als er een losse analyticsdienst, URL-shortener of extra trackinglaag tussen het QR-platform en de landingspagina zit, voegt elke stap een volledige rondreis toe voordat de pagina begint te laden. Check de redirect-keten in het netwerkpaneel van een browser om precies te zien door hoeveel tussenstappen je code gaat.

Hoeveel redirects mag een QR-code hebben?

Één tussenstap, rechtstreeks van de trackingurl naar de bestemming, is ideaal. Twee is meestal ook nog prima. Voorbij dat punt kun je het zien als een teken dat er iets in de opzet verkeerd geconfigureerd of overbodig is, vergelijkbaar met hoe zoekmachines lange redirectketens als een crawl-efficiëntieprobleem markeren. Elke extra tussenstap is een volledige netwerk-rondreis waar een scanner doorheen moet wachten.

Moet een QR-code een 301- of 302-redirect gebruiken?

Gebruik 302 (of 307) voor elke QR-code waarvan de bestemming kan veranderen, wat precies de hele reden is om een dynamische QR-code te gebruiken. Een 301 vertelt browsers dat de verhuizing permanent is, en browsers mogen dat cachen en de server niet opnieuw raadplegen, waardoor een telefoon die de code één keer heeft gescand vast kan blijven zitten op een oude bestemming, ook nadat je de campagne hebt bijgewerkt.

Heeft een trage redirect echt invloed op de conversieratio van een QR-code?

Het onderliggende mechanisme, de laadsnelheid van mobiele pagina's, is rechtstreeks onderzocht. De analyse van Google en DoubleClick van ongeveer 900.000 mobiele landingspagina's liet zien dat 53% van de bezoeken wordt afgebroken zodra een pagina langer dan drie seconden nodig heeft om te laden, en dat de kans op afhaken sterk toeneemt naarmate de laadtijd oploopt. Een QR-scan voegt daar nog een extra laag ongeduld aan toe boven op een normaal mobiel bezoek, omdat de scanner al de fysieke stap heeft gezet om te scannen voordat de pagina überhaupt begint te laden.

Vertragen in-app-browsers zoals die van Instagram of TikTok de redirect van QR-codes?

Er is geen solide publieke benchmark die de exacte vertraging van in-app-browsers kwantificeert, dus wees sceptisch over specifieke getallen. Wat wel gedocumenteerd is: verschillende grote apps injecteren hun eigen JavaScript in pagina's die in hun ingebouwde browser worden geopend, waardoor ze zich op meer manieren dan alleen snelheid anders gedragen dan een normale mobiele browser. Als een aanzienlijk deel van je scans vanuit sociale apps komt, test je landingspagina dan specifiek binnen die in-app-browsers in plaats van aan te nemen dat een standaard mobiele browsertest representatief is.

Hoe test ik hoe snel de redirect-keten van mijn QR-code echt is?

Open je trackingurl in Chrome DevTools met het tabblad Network en "Preserve log" aangezet, en tel elke redirect die afgaat voordat de uiteindelijke pagina laadt. Voor een concreet getal in plaats van een visueel spoor draai je curl -w "%{time_redirect} %{time_total}\n" -o /dev/null -s -L <url> in een terminal, wat de tijd op redirects apart rapporteert van de totale verzoektijd. Test op een echte mobiele verbinding, niet op kantoorwifi, want vast breedband laat bijna elke keten prima lijken.

Is een statische QR-code sneller dan een dynamische?

Een statische QR-code die rechtstreeks naar een URL verwijst zonder trackinglaag, slaat de redirectstap volledig over, dus in theorie is die marginaal sneller. In de praktijk is het verschil meestal te klein om op te merken tegenover alles wat de laadtijd van een mobiele pagina verder beïnvloedt, en het gaat ten koste van de mogelijkheid om de bestemming aan te passen nadat de code al gedrukt is of scans überhaupt bij te houden. Voor de meeste bureaucampagnes is een goed geconfigureerde dynamische code met één schone tussenstap de betere keuze.

Kan ik een trage QR-code repareren zonder opnieuw te drukken?

Ja, en dat is een van de voordelen van een dynamische code. Omdat de gedrukte code altijd alleen naar de trackingurl verwijst, kun je overbodige tussenstappen verwijderen, een verkeerd geconfigureerde 301 omzetten naar een 302, of volledig overstappen op een snellere redirectservice, allemaal zonder de fysieke code aan te raken. Als je trackingcijfers laten zien dat scans wegvallen voordat ze de bestemming bereiken, is dat de moeite van het uitzoeken waard, samen met je bredere QR-analytics en UTM-opzet, want een trage redirect kan er identiek uitzien als een scan die simpelweg nooit converteerde.