Латентность при загрузке веб-страниц

    Пост «Кое-что о весе страницы» вызвал у меня желание написать маленькое дополнение. Многие замечают, что оптимизация размера веб-страниц становится менее актуальной в связи с увеличением пропускных способностей каналов. Рано или поздно все будут сидеть на гигабите, и будет совершенно неважно, весит ваша страница 100Кб или 250. Возможно, так оно и будет. Однако помимо скорости канала есть и другой параметр — задержка или латентность. И если пропускная способность каналов с развитием технологий может вырасти ещё очень сильно, то у латентности существует физический предел: это скорость света в оптоволокне — около 200 тысяч километров в секунду.

    Хотя эта скорость очень велика, но всё же недостаточно, чтобы о ней забывать, ведь и планета у нас немаленькая. Wolfram Alpha не зря выдаёт на запросы по расстоянию время прохождения этого расстояния светом в волокне. Пусть у вас стоит сервер в Токио, а клиент пришёл из Рио-де-Жанейро. Если даже эти два города соединить оптоволокном по кратчайшей траектории на поверхности Земли, свет будет идти 86.7 мс.

    Что это значит для вас? Предположим, пользователь открывает вашу страницу в браузере, например, из закладок. От того момента, когда он кликнул, до того, когда сигнал дойдёт до сервера, пройдёт минимум 86.7 мс. И ещё столько же, чтобы сигнал дошёл обратно. Ваша страница никак не может загрузиться быстрее 173.4 мс, даже если она мало весит и вообще закэширована клиентом (чтобы узнать, что она не менялась, всё равно придётся спросить сервер).

    Казалось бы, 173.4 мс — мелочи жизни. Но не всё так просто. Многим страничкам требуются скрипты, стили и картинки, без загрузки которых страничка нефункциональна. Браузер не может начать всё это загружать, не загрузив сам HTML хотя бы чуть-чуть (ссылки-то на скрипты в HTML). А значит, нам потребуется уже 86.7 мс (запрос HTML) + 86.7 мс (получение HTML) + 86.7 мс (запрос всего остального) + 86.7 мс (получение всего остального) — минимум 346.8 мс.

    Конечно, и 346.8 мс можно подождать. Бывает, однако, что для нормального отображения страницы требуется выполнить AJAX-запрос. К примеру, основной информационный блок у вас на странице может автоматически обновляться с сервера по AJAX. Чтобы не усложнять логику сервера, вы его не отдаёте при первоначальной загрузке страницы, а оставляете пустым, но сразу же вызываете функцию обновления. Таких сайтов множество. Скажем, на rts.micex.ru так загружаются индексы, котировки и прочие блоки. Теперь, если вы зашли посмотреть актуальные котировки, вам придётся подождать загрузки HTML, загрузки JS, а затем выполнения AJAX-запроса — минимум 520.2 мс. Полусекундная задержка уже некомфортна хотя, конечно, можно потерпеть.

    Бывает однако и так, что некоторая информация подгружается AJAX-запросом, который ждёт результатов выполнения другого AJAX-запроса. Иногда это связано с непродуманностью взаимодействия между клиентом и сервером: чтобы послать следующий запрос, нужна информация из предыдущего. Гораздо чаще это связано с ленью разработчика, который не разобрался с функциями, позволяющими выполнить определённый код после завершения сразу нескольких запросов (или не написал сам таких функций, если предпочитает Vanilla JS), и поэтому просто посылает второй запрос в onreadystatechange первого.

    Вот такую чудную картину загрузки демонстрирует стартовая страница одной системы онлайн-банкинга, которой я пользуюсь:

    Здесь подгружаются дополнительные ресурсы и скрипты через 9 последовательных AJAX-запросов. Добавим к этому запрос на HTML и запрос скрипта, который всё это добро загружает — получается минимальная задержка при нашей расстановке клиента и сервера в 1.9 секунды. Вот ведь какая штука: хоть терабитный интернет по всей Земле проведите, сделайте бесконечно быстрые сервера и жёсткие диски, а пользователь из Рио-де-Жанейро всё равно будет ждать две секунды из-за кривых программистов.

    Даже если предположить, что инженеры научатся посылать сигналы не по поверхности, а сквозь Землю и со скоростью света в вакууме (скажем, пускаем пучок релятивистских нейтрино, а на той стороне ставим детектор), латентность упадёт максимум вдвое. Но, я думаю, раньше интернет на Луну проведут, чем такое сделают. А с Луны такой сайт будет грузиться сами посчитайте, сколько.

    Конечно, клиентов с другого конца Земли у вас может быть немного, но ведь и провода лежат не по кратчайшему пути, да и задержки на повторителях и маршрутизаторах вполне осязаемы.

    Ну и очевидные полезные советы в заключение:
    • Старайтесь, чтобы ваш сайт был функционален и информативен уже после загрузки основного HTML. Главная страница YouTube как раз хороший тому пример.
    • Не получайте AJAX-запросом то, что вы хотите сразу показать пользователю. Сгенерируйте правильную страничку сразу.
    • Разумеется, можно и нужно не загружать ту информацию, которую пользователь не увидит, пока не совершит явного действия (прокрутит страницу, нажмёт «показать подробности» и т. д.). Но старайтесь исключить последовательные AJAX-запросы при реакции на эти действия. Либо уложитесь в один запрос, либо выполните все параллельно.
    • При возможности размещайте зеркала сайта в разных частях света и перенаправляйте пользователя на ближайшее.
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 91
    • +5
      Интересная сторона вопроса, действительно такая, казалось бы, «бесконечно быстрая» величина как скорость света при современной ширине канала становится уже заметной.
      Вывод напрашивается очевидный — размещать сервер поближе к своей аудитории :)
      Не редко, кстати, встречаю решение, когда основной сервер «мозг» русского сайта стоит за границей (ну не все любят в России размещаться и не без причин) а сервера со статикой (картиночки, медия, документы, файлы) — размещены ближе к пользователю, в каком-то местном дата-центре. «Про запас» есть копия всего того же в европе с возможностью быстрого переключения — (вся адресация на поддоменах типа files.site.ru, img.site.ru, static.site.ru и т.д.)
      • +3
        Вывод напрашивается очевидный — делать меньше запросов, т.к. всегда будут пользователи с другой стороны планеты.
        • 0
          А у меня иной вывод напрашивается, для меня очевидный.

          При неограниченном/значимым росте ширины каналов вместо технологии толстый клиент (коей на текущий момент является месиво технологий в современных вебсайтах) разработчики снова вспомнят про тонкие клиенты.

          Примером такой технологии, хоть и не завершенной а значит не оптимальной по отзывчивости, может являться opera mini (страница загружается на сервере opera, там формируется снимок страницы в своем формате, и отсылается на клиент), если такой прокси-сервер будет находиться рядом с веб-сервером, то таймауты загрузок станут минимальными.

          Ну и самым быстрым (по отзывчивости при толстых каналах) на текущий момент может являться следующая схема — на веб-сервере устанавливается сервер vnc/rdp/иной аналог, хоть те же полу аппаратные видеокодеки у серверов onlive, а клиент подключается по этому протоколу к браузеру, запущенному на этом же веб-сервере, открывающим страницу по localhost… При должном внимании к возможностям выбранного протокола возможно кеширование мультимедиа на стороне клиента (это если канал все таки не на столько широк как хотелось бы).
      • НЛО прилетело и опубликовало эту надпись здесь
        • +3
          И про прямые руки, как многие полезные посты на хабре ;)
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Можно построить взаимодействие с сервером так, чтобы всё нужное можно было получить одним запросом. Но пара или тройка не вредна, если упрощает программный код. Конечно, если вы посылаете несколько десятков в параллель, это в любом случае повод задуматься.
          • +3
            Теперь ясно, почему у меня админка адворда так тормозит.
          • 0
            Извините за мысли в слух и может быть не совсем по теме топика.
            Клиент-серверная архитектура с запросами от клиента в данном случае будет в любом случае иметь задержки. У нас обязательно будет один файл с разметкой, один css и один js, как минимум. Картинки еще. Пускай первый будет загружен сразу, а последующие все вместе. Задержек не избежать.
            А если в запрос клиента включать идентификаторы кэшированных файлов, а серверу отсылать все необходимое для отображения страницы одним пакетом, без ожидания запросов со стороны клиента? Да, часть клиентов не загружает картинки, часть не загружает js. Все это можно предусмотреть в запросе. Клиент, который просто запрашивает страницу, без дополнительных ухищрений получит все скопом, без последующих запросов.

            Помимо идеальных задержек есть еще и всякие пока что не очень быстрые в этом отношении беспроводные технологии.
            • 0
              Если сильно захотеть (или сильно не хотеть), то разметка, css и js вполне могут помещаться в одном файле. По хорошему надо смотреть конкретные случаи, конкретную ЦА.
              • 0
                Не, запихнуть в один файл все можно, но потом это будет при каждом запросе передаваться клиенту. А в предлагаемом мной варианте кэширование все так же работает, как и должно, не гоняем туда-сюда лишние запросы и имеющиеся файлы.
                • 0
                  Можно обойтись двумя файлами: HTML и CSS+JS.
                  • 0
                    А картинки? Два файла это все равно удвоение задержки.
                    Там даже на транспортном уровне есть о чего поговорить, но там движение есть.
                    • 0
                      Навигацию в dataURI, остальное не очень важно, если это не фотосайт.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        В чём именно бяка будет, что-то не соображу?
                        • 0
                          При отключении посетителем js он не увидит и css?
                          • 0
                            А его кто-то отключает?
                            • 0
                              Мобильный браузер, например? Хотя это отдельная тема. Но вопрос то был «в чем бяка будет».
                              • –2
                                Для всяких опер можно и разными файлами отдавать. А все остальные мобильные умеют джаву.
                            • +2
                              Почему не увидит-то? Я вот про эту технику: http://bolknote.ru/2011/04/19/~3185/.
                            • 0
                              JS отключен у ботов, так что и CSS им не нужен.
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • +1
                                Не останется. Я вот про это: http://bolknote.ru/2011/04/19/~3185/.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  • 0
                                    Не знаю, не изучал. А чего в нём костыльного? «Сжатие» CSS и JS перед выкладкой на продакшн многие используют. Отчего бы ещё одну строчку в этот скрипт не добавить?
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      • 0
                                        Ну а что такого в этом ограничении? Ещё одна строка в скрипте, можно заменить обычным sed'ом.

                                        Насчёт быстрее спорить не буду, детально исследовать надо в разных браузерах и условиях, у меня времени на это нет.
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                          • 0
                                            Он надёжный. Синтаксически «*/» может встретиться в правильном JS только в определённых местах, правится это тоже единообразно.
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • 0
                                                Это ваше имхо. Реальность она иная. «*/» в синтаксисе JS попадается в двух случаях: регулярки и строки (если мы уже пропустили JS через «сжатие»). В том и другом случае «патч» один — заменить символ «*» на \x2A.
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                  • 0
                                                    Что за source map? Не соображу.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                      • 0
                                                        А вон вы про что. Понял.
                      • 0
                        Если я не ошибаюсь, то это не совсем то. Я говорю о передаче пользователю содержащихся на странице ресурсов вместе с самой страницей. До запроса этих элементов браузером. Браузер понятия не имеет о том, что там будет на странице до того, как распарсит html. Я говорю о том, что можно передавать при запросе страницы, при первом запросе — требующиеся для отображения страницы css, js и картинки. Один запрос — одна страница. Это если грубо.
                        • 0
                          В SPDY есть механизм push — сервер может сразу заслать ресурсы, если уверен что они потребуются. Т.е. HTML, CSS, JS и даже результаты каких-нибудь AJAX-ов, можно засунуть клиенту в один присест.
                          • +1
                            Ну если это можно сделать при первом запросе, без уточнения со стороны клиента, что именно он хочет получить -то я таки ошибаюсь и SPDY это именно то.
                    • 0
                      А про SPDY, Server-Push не читали?
                      • 0
                        Нет, логика, конечно, такая же, но когда размер и количество файлов уменьшить нельзя никак — можно подумать и о другом протоколе.
                      • +3
                        Ха! 500мс? Да я на этих ваших ТриДжи (нет кабельного пока) уже привык в ГуглоРидере новости с хабра колёсиком нажимать (открытие в фоновой странице). Пока ленту глазами пробежишь (кликнув 2-3 интересующие новости), переключаешься на уже загрузившуюся первую вкладку.
                        • +2
                          И после этого ненавидишь мобильные версии сайтов, которые норовят показать 5 комментов и подгружают дальше при скролле…
                          • +2
                            Странно, что вконтактик и на 3джи работает сносно — сразу видна мотивация разрботчиков сайта — ведь хомячкам не объяснишь про латентность и особенности радиосвязи — приходится напрягаться и оптимизировать. Не то что разработчики корпоративного софта…
                            • 0
                              Да вконтактик с кешированием перегнул палку. В ИЕ10 вообще для обычного пользователя сайт покажется нерабочим.
                          • +1
                            Спасибо за клик колесиком, не знал о такой возможности. Век живи — век учись!
                            Реально помогает и не только при 3G. Чтобы десять раз не переключаться между той же лентой и новостями, например.
                            • +3
                              Да Вы что!?
                              Хотите сказать что не пользуетесь ежедневно Ctrl+T F6 Ctrl+F4 в браузере и Ctrl+D Ctrl+C Ctrl+V Ctrl+Shift+ESC Winkey в системе?
                              • +3
                                Спасибо за F6, не знал. А вот Ctrl + F4 как-то неожиданно сработало.
                                • 0
                                  А я как дурак который год Ctrl+L жму вместо F6 >_<

                                  А что у нормальных людей делает Ctrl+F4? А то у меня, как и у любого не сильно заморачивающегося переделками линуксоида, это комбо переключает на четвёртый рабочий стол.
                                  • 0
                                    Я знал, что Ctrl+F4 закрывает под виндой, стало интересно под линуксом и эта вкладка закрылась. Хорошо наизусть знаю Ctrl+Shift+T :)
                                  • 0
                                    Ctrl+D Ctrl+C Ctrl+V — это уж совсем простые сочетания :) хотя и их некоторые не знают до сих пор
                                    Из всего перечисленного не пользовался только F6, аналогично комментарию ниже, нажимал Ctrl+L
                                    • +1
                                      Еще Ctrl+K, а вместо Ctrl+F4 использую Ctrl+W
                                      • +1
                                        Ctrl + W, кстати, очень много где работает для закрытия вкладки или окна (а в терминале, как известно, стирает последнее набранное слово). Ещё часто можно выйти из программы, нажав Ctrl + Q.
                                        • +1
                                          А ещё оконные менеджеры в Linux позволяют нажать на Alt и перетаскивать окно за любое место. :)

                                          А если нажать среднюю кнопку (колёсико), то можно менять размер окна без длительной охоты за краешком (но это не работает в XFwm, например).
                                  • +1
                                    При гонянии инфы по HTTP туды сюды забыли о том, что всё это не начнётся пока TCP не установит сессию, а это ещё несколько запросов. Есть способы всё это ускорить, тот же TCP Fast Open.
                                    • 0
                                      keep alive почти полностью решает проблему: используется уже установленное соединение для десятков других запросов
                                      • 0
                                        Это не keep alive, а related соединения. Да они спасают сильно, но я в основном о первом запросе страницы.
                                        • 0
                                          Первый запрос — 5-10% от общего времени загрузки. Тогда уж DNS нужно ускорять, это сильнее поможет.
                                          • 0
                                            Ну там время всё же более-менее предсказуемо, у меня, например, DNS запрос идёт в пределах 400ms. Но DNS меня меньше коробит, т.к. везде где я обитаю используется BIND на шлюзе, посему все запросы кэшируются и последующие ответы идут за 1ms, вместо 300ms. И время кэширования DNS ответа, явно больше чем время жизни TCP соединения.
                                            • 0
                                              Интернет только для Вас? Мы говорим про миллионы случайных пользователей, для которых делаем сайты быстрее, а не про настройку сервера, чтобы конкретно у Вас сайт загружался быстрее молнии
                                              • 0
                                                В большинстве случаев DNS запросы кэшируются, обычно на DNS сервере провайдера, так что это у всех примерно одинаково выглядит. Свою ситуацию я описал лишь для примера, что бы показать что затраты на DNS, imho, меньше чем накладные расходы на TCP.
                                            • 0
                                              А вот и про ускорение DNS.

                                              Кстати, если нужно именно постоянно что-то передавать между клиентом и сервером, да ещё и в обе стороны (то есть сервер может отправлять информацию клиенту, а не только клиент может делать запросы на сервер), то может оказаться эффективным использователь веб-сокеты (я про них писал недавно).
                                      • +1
                                        Отлично, напоминание про латенси лишним не бывает. Это как с иопсами в дисках — все знают что такое ширина канала, но мало кто знает (и понимает влияние) задержек.

                                        К этому нужно ещё добавить, что при задержке от скорости света в ~80мс, реальная задержка будет куда больше, ибо TCP-сессия устанавливается в три этапа. Плюс изначальный DNS-запрос. Плюс, расположить все эти элементы на разных поддоменах (а значит, dns-запросы перед каждым непосредственно запросом данных), да ещё редирект какой-нибудь. И тут, в примере, ещё довольно небольшая задержка, можно сказать идеальные условия от Парижа до Токио, в реальной жизни от Иркутска до Москвы такая задержка не всегда, а если речь о каком-нибудь высоколатентном соединении (типа 3G или подобное), то суммарная величина может достигать просто гигантских значений — минуты и больше, хотя казалось бы — провайдер даёт 4-10Мбит.
                                        • 0
                                          Ну — днс же обычно кешируется близким сервером, в идеале — на локалхосте или у провайдера…
                                        • +2
                                          Long Fat Network.
                                          en.m.wikipedia.org/wiki/Bandwidth-delay_product
                                          itperformancemanagement.blogspot.ru/2010/04/tcp-throughput-over-long-fat-networks.html?m=1

                                          — особенности TCP не позволят получить 100% отдачи от скорости канала при высоких задержках.
                                          Недавно наблюдали, как 100Мбит (теоретических) при пинге 60мс превращаются в 35 реальных (goodput) Мбит.
                                          И это происходит только из-за одного аналога «запроса» с веб-странички — ожидания подтверждения клиента, что пакеты дошли без ошибок.
                                          Если же поверх приторможенного TCP мы будем ждать 9 последовательных AJAX запросов, то все «тормоза» перемножаются… И 1 мегабита из 100 обещанных не останется.
                                        • 0
                                          Насчет достижения скорости света в вакууме — это уже сделано.
                                          Есть оптоволокно для мажоров, с пустой сердцевиной.

                                          Окупает себя на высокочастотной торговле :-)
                                          • 0
                                            Ух ты, круто. Звучит очень просто и банально, но мне блин даже в голову не приходило.

                                            Правда теперь осталось его сквозь центр Земли пробрасывать и можно не париться с этими нейтринами.
                                            • 0
                                              Скорость света при движении по нему всё равно ниже, чем в вакууме.
                                              • 0
                                                На доли процента.
                                                • 0
                                                  Вы посчитали или с потолка эту цифру взяли?
                                                  • +1
                                                    Вероятно, что пустотелое волокно заполнено воздухом, показатель преломления (который есть отношение скорости света в вакууме к скорости в среде) воздуха равен 1,0002926, итого разница в процентах будет 0,02926%, плюс учтём всякие мелочи, типа движения по криволинейной траектории, время на переотражения и всё равно получится мизер.
                                                    • 0
                                                      Пустотелое волокно? Воздухом? А свет по изогнутому волокну как движется-то? Мне кажется, оно пустотелое в сердцевине, а по краям у него что-то ещё, какая-то среда, которая позволяет свету преломляться и свет в ней тоже движется, нет? А потери скорости в этой среде вы считаете?
                                                      • 0
                                                        А как по-вашему устроено обычное волокно? У него в центре стекло с одним показателем преломления, вокруг с другим и свет на границе отражается без потерь. В случае с пустотелым волокном будет граница не стекло-стекло, а воздух-стекло с аналогичным эффектом, свет не попадает в эту среду, он от неё отражается.
                                                      • 0
                                                        плюс учтём всякие мелочи, типа движения по криволинейной траектории, время на переотражения и всё равно получится мизер
                                                        Что-то я не вижу почему там мизер получится.
                                                        • 0
                                                          Мизер, мизер, криволинейная траектория это примерно такая — в трубе диаметром 50мкм и длиной 1000км (разница в 20 000 000 000 раз) движется свет, отражаясь от стенок, думаете там получится сильно удлинить путь света?
                                                        • 0
                                                          В одномодовом оптоволокне нет никакого криволинейного движения, там диаметр сердцевины сравним с длиной волны света.
                                                          • 0
                                                            Ну это я так, для количества слов :)
                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                  • +7

                                                    Статья ж не про то =)
                                                    • +1
                                                      Выпороть бы тебя
                                                    • +1
                                                      Скажите, почему Вы не перевели термин «latency» на русский язык словом «задержка» или словосочетанием «время ожидания»? Что заставило Вас выбрать слово «латентность»?
                                                      • 0
                                                        Это не переводная статья, и я не переводил. Я воспользовался общеупотребительным термином. Вариант «задержка» упоминается в первом же абзаце статьи для тех, кому вдруг слово «латентность» непонятно.
                                                        • +5
                                                          Ваши дефиниции пролонгируют тайминги чтения вашего эссе.
                                                          • 0
                                                            И добро бы только пролонгировали; дык они ж ещё провоцируют и другие речи на пиджин-инглише или аналогичном дикарском жаргоне.

                                                            Например, вон там у одного из комментаторов «ассеты бандлятся» да «финальный профит».
                                                      • 0
                                                        Если мои основные клиенты в Бразилии, а сервера стоят в Японии, то это повод задумать «а перенести ли сервера в Бразилию?».
                                                        Если мои основные клиенты в Японии и раз в месяц заходят клиенты из Бразилии, то стоит посчитать о целесообразности открытия узла в Бразилии. Если не целесообразно, то можно забить на клиента (как бы грустно это не звучало).
                                                        Если же мои клиенты по всему миру, то нужно использовать глобальный CDN.
                                                        • 0
                                                          Если говорить о временах с безграничной шириной канала, первым же запросом можно загрузить все содержимое сервера, а дальше все работает локально. Так сказать, скачать весь интернет :)
                                                          • +1
                                                            <зануда mode>
                                                            Тут надо сделать два замечания. Wolfram Alpha показывает самое короткое расстояния с учетом шарообразности Земли. Такой путь из Рио в Токио действительно используется в авиации (с небольшими корректировками). Но сигнал пойдет по магистральным каналам примерно так: Rio->Los Angeles->Tokyo, то есть фактическое расстояние будет больше, чем 86.7 ms + задержка на IX (она минимальная, но все-таки есть).
                                                            </зануда mode>

                                                            Когда считают время передачи по сети, то считают время от выхода из сетевухи сервера до сетевухи клиента, чтобы аннигилировать время обработки запроса на сервере/клиенте.

                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                            Самое читаемое