However, the problem you're seeing is very likely an issue with overflowing the receive buffer. Focusing your attention on the transmitter timing is probably just a distraction.
But first, you should understand that USB virtual serial has end-to-end flow control built into the USB protocol. When you transmit a large amount of data, it's written into buffers on the Teensy side. Each buffer is only sent when the PC is able to receive it. If the PC isn't ready, the data remains sitting on the Teensy side. USB is a complex protocol, but for this case the thing you need to understand is the USB protocol fundamentally includes flow control negotiation between the PC and Teensy, so you can't get data loss by sending too fast. Because Serial.print() and Serial.write() wait when all buffers are full, the actual end-to-end speed is only as fast as the software on both side can run. This flow control is built into the USB protocol at the lowest level. It can't be turned off. It's always how USB virtual serial works (but again, with some caveats I've glossed over to keep this message shorter).
Real hardware serial works the opposite way, unless you're using the optional RTS/CTS hardware flow control. When you transmit data, it's also written into a buffer on the Teensy side, which allows your program to keep running without waiting (unless the buffer fills up). But unlike USB, and without flow control signals, the data immediately begins transmitting, paced only by the baud rate. Teensy can't know whether the other side is ready or able to receive. The voltage on the TX1 pin simply toggles with the bits you wrote. There is no way to assure the other side really will really will receive the byte and store it into a buffer.
We see this serial data loss problem over and over on this forum. You transmit bytes, but they don't get received on the other side. It's almost always because the receive buffer filled up and the receiving Teensy couldn't accept more data as it arrived at the RX1 pin, because the receive buffer had no more space at that moment.
Usually the problem is poorly designed receive-side code which calls Serial1.available(), but doesn't actually do Serial1.read() until some large amount is reported. We can't see your code to know whether you're doing anything like that, but it is a common issue. The other less common problem is doing some lengthy operation, or just a delay, without checking Serial1.availalbe() and calling Serial1.read() to get the received bytes quickly out of the buffer, so you have room for more to arrive. Usually this is an issue only at high baud rates. A 3rd problem we see here involves certain libraries which block interrupts, disrupting the serial receive no matter what you do with Serial1.availalbe() and Serial1.read(). Adafruit_NeoPixel is the most common problem, and switching to WS2812Serial is the solution.
Of course this is all just a lot of guesswork, and a lengthy message to explain the common problems... when it could have been a much shorter message focusing on the specific problem you're probably facing, had you been clearer about what you're doing and shown us the code. But hopefully this long and very general explanation helps anyway?