Heen-en-terugreis (X11)
Een verzoek waarvoor eerst het antwoord van de server moet komen voordat het programma verder kan: de duurste bewerking in het X-protocol, en de reden dat een toolkit er over een trage verbinding seconden over kon doen om te starten.
De meeste X-verzoeken, een lijn tekenen, een venster verplaatsen, hebben geen antwoord; Xlib zet ze in een buffer en verstuurt ze in groepen. Maar XInternAtom, XGetWindowAttributes, XQueryTree, XGetGeometry en XSync vereisen een antwoord, en Xlib blokkeert tot dat binnen is. Lokaal over een Unix-socket is dat een fractie van een milliseconde; over een netwerk met 50 ms latentie is elk zo'n verzoek een twintigste seconde stilstand. Een Motif-applicatie kon bij het opstarten honderden atomen registreren en de geometrie van elke widget opvragen, wat de bekende wachttijden op X-terminals en via modems opleverde.
Er zijn veel remedies geweest. Xlib kreeg XInternAtoms om veel atomen in één antwoord op te halen. LBX en later NX plaatsten een proxy naast de server die uit een cache antwoordde. XCB werd in 2001 precies hiervoor gebouwd: elk verzoek geeft direct een cookie terug en het antwoord wordt pas opgehaald wanneer het nodig is, zodat tien vragen tegelijk onderweg kunnen zijn. Toolkits leerden vensterattributen te cachen in plaats van ze op te vragen. Foutafhandeling is een bijzonder geval: omdat fouten asynchroon worden gemeld, weet een programma pas bij de volgende heen-en-terugreis dat een aanroep is mislukt, en dat maakt de X-foutafhandelaar zo lastig te doorgronden.