Нет прямой зависимости между емкостью канала передачи данных и задержкой.
Абстрактные 32.6 мбит могут быть реализованы на 10Gbit Ethernet на расстоянии пары метров с задержкой, исчисляющейся в наносекундах (а ограничение - полисером, не влияющим на задержку), а может парой каких-нибудь 2G модемов с каждой стороны, добавляющие 100-500мс каждый, с Тихим океаном посередине и его 50+мс задержки, которую вносит медленно распространяющийся по нашей вселенной свет, и ограничением скорости с помощью шейпера с огромным буфером, который ваши пакеты будет мурыжить в очереди еще секунду-другую.
Но нам интересно прохождение сигнала и ответа на него туда-обратно, так что смело умножаем на два и получаем Round Time Trip.
Но! надо учитывать многие другие факторы.
На установку TCP-соединения и отправку GET понадобится ~2RTT.
А еще может быть, например, HTTPS, на согласование TLS уйдет еще ~1.5-2 RTT в лучшем случае.
И это только то, что зависит от RTT и кое-как поддается теоретическому/статистическому просчету при наличии вводных.
Резолв DNS может занять вообще неопределенное время, от 0 до десятков секунд в зависимости от фазы Луны.
Еще хз сколько клиентские и серверные процессы будут ждать у планировщиков ОС своего куска времени.
В общем случае, в диком интернете без серьезной подготовки, задача подобного уровня меряется никак не милисекундами.
Если очень надо - поднимайте, предварительно, какой-нибудь вебсокет до сервера, уже внутри реализовывайте вычисление задержки и передавайте в том же канале свои клики, надеясь, что между измерениями и действиями ничего не изменилось.
