Round trip (X11)
A request that must wait for the server's reply before the program can continue: the most expensive operation in the X protocol, and the reason a toolkit could take seconds to start over a slow link.
Most X requests, draw a line, move a window, have no reply; Xlib queues them in a buffer and sends them in batches. But XInternAtom, XGetWindowAttributes, XQueryTree, XGetGeometry and XSync require an answer, and Xlib blocks until it arrives. Locally over a Unix socket that is a fraction of a millisecond; over a network with 50 ms of latency each such request is a twentieth of a second of standstill. A Motif application could intern hundreds of atoms and query the geometry of every widget at startup, which produced the familiar waits on X terminals and over modems.
The remedies have been many. Xlib gained XInternAtoms to fetch many atoms in one reply. LBX and later NX put a proxy next to the server that answered from cache. XCB was built in 2001 for exactly this: every request returns a cookie immediately and the reply is collected only when needed, so ten questions can be in flight at once. Toolkits learned to cache window attributes instead of asking for them. Error handling is a special case: because errors are reported asynchronously, a program does not know a call failed until the next round trip, which is what makes the X error handler so hard to reason about.