A two-page invoice prints instantly in the office but takes three minutes from a home RDP session. Nothing is broken - the maths of redirected printing is against you. Here is what is really travelling over your connection, and which fixes change the numbers.
Honesty first: a redirected print job is usually the largest thing your RDP session ever sends. The screen updates you watch are small and compressed; a single photo-quality page can be tens of megabytes of rendered data, and it must cross your internet connection completely before the first page appears. Once you understand that, the fixes stop being superstition and start being arithmetic.
With Remote Desktop Easy Print, the document is rendered on the server into a print-ready stream and pushed through the RDP connection to your PC, which forwards it to the printer. Photos, scanned pages and full-page graphics render far larger than their source files, colour multiplies the size again, and your home upload/download speed - not the server's power - sets the pace. On an office LAN this is invisible. On a slow broadband or mobile connection, a graphics-heavy job can legitimately take minutes, and no setting makes bandwidth appear from nowhere.
These are dull fixes, and they are the ones that work - the job gets smaller, so the wait gets smaller.
When the server holds the printer's exact native driver, the printer is mapped to that driver instead of Easy Print, and the data sent can be much more compact for many models - the printer's own language instead of a page image. The trade is real: third-party drivers on a shared RDS server are the classic source of spooler crashes, so this route suits a small, controlled server, not a busy one with twenty printer models. The driver-matching guide in this series covers installing them safely, one at a time, with testing after hours.
The TSPrint route from the video compresses the print stream before sending it to the client, which is one reason it feels faster than plain redirection on the same connection - the same reason it exists. Be clear-eyed about the boundary: compression shrinks the job, it does not repeal your connection speed. A 38 MB job compressed to 9 MB still takes real time on a 2 Mbps link. If printing is business-critical at a branch, the structural answers are a faster link, printing locally, or a printer installed on the server's side of the network - covered in the network-printer guide in this series.
In the video, TSPrint prints from the same session that defeated built-in redirection - watch the difference on a real setup.
▶️ Watch Full VideoThe whole job usually has to transfer before printing starts, so the wait is front-loaded into page one. After the data arrives, the printer runs at its own speed. A printer waking from sleep adds its own delay on top.
Almost never. The rendering takes a moment; the transfer takes the minutes. Unless the server is genuinely overloaded, the connection between the server and the client is the bottleneck.
It can be - the print data crosses both the VPN and the RDP connection. The difference matters most for large jobs. For text-sized office documents most users never notice it.