Высокая производительность Google Chrome

http://www.igvita.com/posa/high-performance-networking-in-google-chrome/
  • Перевод

История и краеугольные принципы Google Chrome.


imageGoogle Chrome был представлен во второй половине 2008 года, как бета версия для Windows платформы. Код Chrome, авторство которого принадлежит Google, был сделан доступным под либеральной BSD лицензией — как и Chromium проект. Для большинства заинтересованных, такой поворот событий стал сюрпризом — война браузеров возвращается? Сможет ли Google сделать свой продукт действительно лучше других?

«Это было столь хорошо, что заставило меня изменить свое мнение..» — Эрих Шмидт, первоначально не желающий принимать идею Google Chrome.

Да, он смог! Сегодня Google Chrome является одним из наиболее популярных браузеров (35% доля рынка, показатели StatCounter) и доступен на Windows, Linux, OS X, Chrome OS, Android и iOS платформах. Несомненно, его достоинства и широкий функционал нашли отклик в сердцах пользователей, подарив много замечательных идей другим браузерам.

Оригинал 38 страничной книги комиксов, с разъяснениями идей и принципов Google Chrome предлагает нам замечательный пример мышления и процесса проектирования, результатом которых стал этот браузер. Однако, это только начало пути. Главные принципы, которые стали мотиваторами первых этапов разработки Chrome, нашли свое продолжение и в правилах непрерывного усовершенствования браузера:
  • Скорость: сделать самый быстрый браузер
  • Безопасность: предоставить пользователю наиболее защищенную среду для работы
  • Стабильность: предоставить гибкую и стабильную платформу для веб-приложений
  • Простота: сложные технологии за простым интерфейсом.

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

Многогранность производительности.


Современные браузеры представляют собой платформу, которая во многом напоминает операционную систему, и Google Chrome не исключение. Браузеры, которые предшествовали Chrome, были спроектированы как монолитные программы, с одним рабочим процессом. Все открытые страницы делили между собой одно адресное пространство и работали с одними и теми же ресурсами, поэтому ошибка в обработке любой страницы или в механизме браузера, грозила сбоями и крахом всего приложения.
image
В отличие от этого подхода, в основе Chrome лежит мульти-процессная архитектура, которая предоставляет каждой странице свой отдельный процесс и память, создавая что-то вроде жестко изолированной песочницы для каждой вкладки. В мире все возрастающей мульти-ядерности процессоров, способность изолировать процессы одновременно с защитой каждой страницы от других, работающих из ошибками, страниц, дала Chrome значительное преимущество в производительности по сравнению с конкурентами. Стоит заметить, что большинство других браузеров последовало их примеру, внедрив или начав внедрение упомянутой архитектуры.

С разделением процессов, исполнение веб-приложения главным образом включает три задачи: получить все нужные ресурсы, построить структуру страницы и отобразить ее, выполнить JS. Процессы построения страницы и выполнения JS следуют однопоточной, чередующей схеме, поскольку невозможно выполнить одновременное построение и модификацию одного и того же дерева страницы (DOM). Эта особенность объясняется тем фактом что JS сам по себе — однопоточный язык. Следовательно, оптимизация совместного построения страницы и исполнения скриптов в реальном времени является очень важной задачей, как для разработчиков веб-приложений, так и для разработчиков самого браузера.

Для отображения страниц Chrome использует WebKit, быстрый, открытый (Open Source) и совместимый со стандартами движок. Для выполнения JS Chrome использует собственный, очень хорошо оптимизированный V8 Javascript движок, который, кстати, является Open Source проектом, и нашел свое применение в множестве других популярных проектов — к примеру, в node.js. Однако, оптимизация выполнения скриптов V8, или обработки и отображения страниц вебкитом не столь важны, когда браузер находится в ожидании ресурсов, необходимых для построения страницы.

Способность браузера оптимизировать порядок, приоритет, и управлять возможными задержками каждого необходимого ресурса является одним из наиболее важных факторов его работы. Вы можете даже не подозревать об этом, но сетевой интерфейс Chrome, выражаясь образно, умнеет с каждым днем, пытаясь скрыть или максимально уменьшить стоимость ожидания загрузки каждого ресурса: он учится подобно DNS поиску, запоминая топологию сети, выполняя предварительные запросы до наиболее вероятных к посещению страниц, и прочая. Внешне, он являет собой простой механизм для запроса и получения ресурсов, но его внутреннее устройство дает нам увлекательную возможность изучить, как нужно оптимизировать веб производительность чтобы оставить пользователю только лучшие впечатления.

Что такое современное веб-приложение?


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

Проект HTTP Archive сохраняет историю эволюции веб, и он поможет нам ответить на этот вопрос. Вместо того, чтобы собирать и анализировать контент со всей сети, он периодически навещает популярные сайты, чтобы собрать и записать данные о использованных ресурсах, типах контента, заголовках, и других мета-данных для каждого отдельного сайта. Статистика, доступная на январь 2013, может удивить вас. Средняя страница, с выборки среди первых 300 000 сайтов интернета, имеет такие характеристики:

image

  • «Вес» — 1280 КB
  • Состоит из 88 ресурсов (картинки, css, js)
  • Использует данные более чем из 30 сторонних сайтов.

Давайте посмотрим на это более детально. Свыше 1MB веса в среднем, состоит из 88 ресурсов, и собирается из 30 различных собственных и сторонних серверов. Заметим, что каждый из этих показателей неуклонно растет в течении нескольких последних лет, и нет повода прогнозировать, что этот рост остановится. Мы в все большем количестве строим все более громоздкие и требовательные веб-приложения, и этому не видно конца.

Сделав несложные математические расчеты на основе показателей HTTP Archive, можно увидеть, что средний ресурс страницы имеет вес 12KB (1045KB / 84), а это значит, что большинство интернет-соединений в браузере кратковременные и импульсивные . Это еще больше усложняет нам жизнь, поскольку лежащий в основе протокол (TCP) оптимизирован под большие, потоковые загрузки. Поэтому стоит докопаться до сути вещей, и рассмотреть один из типичных запросов на типичный ресурс.

Жизнь типичного запроса


Спецификация W3C Navigation Timing обеспечивает API браузера и возможность отследить часовые рамки и производительность каждого запроса. Давайте подробней рассмотрим его компоненты, так каждый из них представляет очень важную часть в общем впечатлении пользователя от производительности браузера.



Получив URL ресурса в интернете, браузер начинает проверку, не локальный ли он, и имеются ли сохраненные данные в кэше. Если вы перед этим уже получали данные с этого ресурса, и соответствующие заголовки браузера были установлены (Expires, Cache-Controle, ...) то есть возможность получить все данные из кэша — быстрейший запрос — это тот запрос, который не был сделан. В другом случае, если мы проверили ресурс и кэш «протух» или мы еще не посещали сайт, приходит очередь сделать дорогостоящий сетевой запрос.

Имея адресу сайта и путь к запрашиваемому ресурсу, Chrome сначала проверяет, имеются ли открытые соединения на этот сайт, которые можно использовать снова — сокеты, объединены в группы по {scheme, host, port}. В случае, если вы выходите в интернет через прокси, или установили у себя proxy auto-config (PAC) скрипт, Chrome проверяет наличие нужного соединение через соответствующий прокси. PAC скрипт позволяет задать несколько прокси, базируясь на URL или других правилах настройки конфигурации, и каждый из них может иметь свой собственный набор соединений. И наконец, если ничто из вышеуказанных условий не подошло, пришел черед получения IP адреса для нужного нам адреса — DNS Lookup.

Если нам повезло, и адрес находится в кэше, ответ наверняка обойдется нам в один быстрый системный запрос. Если нет, то первым делом нужно выполнить запрос к DNS серверу. Время, которое потребуется для его выполнения, зависит от вашего интернет провайдера, популярности запрашиваемого сайта и вероятности, что имя сайта находится в промежуточном кэше, плюс время ответа сервера DNS на данный запрос. Другими словами, здесь много неопределенности, но время в несколько сот миллисекунд, которое понадобится на запрос до DNS, не будет чем-то из ряда вон выходящим.
image
Получив IP, Chrome может устанавливать новое TCP соединение к удаленному серверу, а это значит, что мы должны выполнить так называемое three-way handshake (трехкратное приветствие): SYN > SYN-ACK > ACK. Этот обмен приветствиями добавляет задержку на запрос-ответ для каждого нового TCP соединения — без исключений. В зависимости от расстояния между клиентом и сервером, учитывая выбор пути маршрутизации, это может отнять в нас несколько сот и даже тысяч миллисекунд. Заметим, что вся эта робота выполняется перед тем, как даже один байт данных веб-приложения будет передан!

Если TCP соединение установлено, и мы используем защищенный протокол передачи данных (HTTPS), дополнительно потребуется установить соединение по SSL. Это может отнять до двух дополнительных полных циклов вопрос-ответ между клиентом и сервером. Если SSL сессия сохранилась в кэше, мы можем обойтись только одним дополнительным циклом.

Наконец, после всех процедур, Chrome имеет возможность наконец отправить HTTP запрос (requestStart в диаграмме выше). Получив запрос, сервер начинает его обработку, и отправляет ответ назад клиенту. Это потребует минимум один цикл, плюс время на обработку запроса на сервере. И вот, мы наконец получили ответ. Да, если этот ответ не есть HTTP редирект! В таком случае нам придется повторить еще раз всю вышеописанную процедуру целиком. На ваших страницах есть парочка не совсем нужных редиректов? Наверное, стоит вернутся к ним, и поменять ваше решение.

Вы считали все эти задержки? Чтобы проиллюстрировать проблему, допустим худший сценарий типичного широкополосного соединения: локальный кэш утерян, за ним следует относительно быстрый DNS поиск (50мс), TCP приветствие, SSL переговоры, и относительно быстрый (100мс) ответ сервера, с 80мс на доставку запроса и ответа (среднее время цикла на континентальной Америке):
  • 50 мс для DNS
  • 80 мс для DNS приветствия (один цикл)
  • 160 мс для SSL приветствия (два цикла)
  • 40мс на запрос до сервера
  • 100 мс на обработку запроса на сервере
  • 40 мс на ответ из сервера

В суме это 470 мс для одиночного запроса, что приводит к затратам более чем 80% времени на установление соединения с сервером в сравнении с временем, которое нужно серверу для обработки запроса. На самом деле, даже 470 миллисекунд могут быть оптимистичной оценкой:

  • если ответ сервера не вмещается в начальное congestion окно (4-15KB), то потребуются еще несколько циклов запрос-ответ.
  • SSL задержка может быть даже хуже, если нам надо получить утерянный сертификат или выполнить онлайн проверку статуса сертификата, в каждом случае потребуется установить новое, самостоятельное, TCP соединение, которое может добавить сотни миллисекунд или даже секунды к задержке.


Что значит «Достаточно быстро»?


Сетевые расходы на DNS, приветствия, и обмен сообщениями — это то, что доминирует в общем времени в предыдущих случаях — ответ сервера потребует только 20% общего ожидания! Но, по большому счету, имеют ли эти задержки значение? Если вы читаете это, то вы наверное уже знаете ответ — да, и очень даже большое.

Последние исследования пользователей рисуют следующую картину, что пользователи ожидают от любого интерфейса, как онлайн так и оффлайн приложений:
Задержка Реакция пользователя
0-100мс. мгновенно
100-300 мс. небольшая, но уже заметная задержка
300-1000мс. запрос в обработке
больше 1с. переключение внимания пользователя на другой контекст
больше 10с. я вернусь попозже

Таблица выше также объясняет неофициальное правило производительности в среде веб-приложений: отображайте ваши страницы, или, по крайней мере, предоставьте визуальный ответ на действие пользователя в течении 250мс для сохранения его заинтересованности вашим приложением. Но тут не просто скорость ради скорости. Исследования в Google, Amazon, Microsoft, как и многих тысяч других сайтов показывают, что дополнительная задержка имеет непосредственное влияние на успешность вашего сайта: более быстрые сайты приносят больше просмотров, выше лояльность пользователей и выше конверсия.

И так, что мы имеем — оптимальный показатель задержки около 250мс, но, однако, как мы видели выше, комбинация DNS запросов, установка TCP и SSL соединений, и доставка запросов отнимает до 370мс. Мы перешли лимит более чем на 50%, и мы все еще не учли время обработки запроса на сервере!

Для большинства пользователей и даже веб-разработчиков, DNS, TCP, SSL задержки совершенно непрозрачные, и формируются на слоях абстракции, о которых только немногие из нас думают. Тем не менее, каждый из этих этапов критически важен для взаимодействия с пользователем в целом, поскольку каждый дополнительной сетевой запрос может добавить десятки или сотни миллисекунд задержки.
Это та причина, по которой сетевой стек Хром есть много, много больше чем просто обработчик сокетов.

Проблему мы обсудили, пора переходить к деталям реализации.

P.S. переводчика: поскольку статья довольно большая, решил разбить ее на теорию и практику, другая часть интересней и намного большая. Как оказалось, очень много времени в обработке запроса на перевод занимает оформление под Хабр, около 40% времени, и вычитка на русском языке, поскольку для меня это в некоем роде двойной перевод. Спасибо за внимание.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 95
  • НЛО прилетело и опубликовало эту надпись здесь
    • +5
      Это плохо, поскольку перевод включал только словарь, никакого google translate, но здесь проблема не в переводе с английского, а в нормальном оформлении на русском, поскольку он не мой родной. А как большинство знают, перевести на свой язык легче, чем из своего на чужой.
      Первый блин комом, да.
      • +1
        Главное — не отчаивайтесь.

        Если это так, то все не так уж и плохо, тем более для первого раза
        • +4
          извините, но для украинца это не оправдание.
          • +10
            Что значит не оправдание?
            Может для вас новость, что далеко не для всех украинцев русский — родной язык?
            И да, если человек живет где-нибудь во Львове, то с русским языком сталкиваться в жизни будет далеко не регулярно.
            • +6
              Так вышло, что я жил в Украине (в Восточной, конечно), знаю украинский, а сейчас несколько лет работаю как раз с текстами и авторами-фрилансерами, в том числе — из Украины. Дело в том, что порядок слов в предложении у русского и украинского идентичен, в то время как при переводе с английского этот порядок частенько становится неестественным — переносится из английского.

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

              Я не принижаю достижений автора, просто в следующий раз надо потратить побольше времени на вычитку. Спасибо ему за пост.
              • +3
                Я уже переводил на родной язык небольшие статьи, только чтобы поучиться, и лично для меня, невзирая на родственность языков, родной много легче — легче вспомнить подходящую идиому, легче заметить шероховатость, или постоянное «мы-мы-мы», легче увидеть, что вот так люди не говорят, а вот тут слишком сухо. Когда говоришь на русском из головы, вот как сейчас, разницы как будто и нет, а вот когда на входе каша украинского и русского, как например «другой» вместо «второй», вычитать на пусть и близком, но в жизни активно не использованном языке много сложнее, чем перевести с английского. Но вы совершенно правы, нужно побольше времени на вычитку, это мой косяк.
      • +8
        У публикации неправильный заголовок. Надо так: «Высокая производительность Google Chrome и низкое качество Google Translate».
        • +2
          А лучше так: низкое качество Google Chrome (много процессов=прожорливость) и высокая производительность Google Translate
          • +4
            Думал увидеть в статье, что хром уже не такой быстрый, как хотелось бы. Памяти дофига жрет, собака :(
            • +1
              Вы давно не пользовались Firefox с фаербагом…
          • +4
            Надо так: «Высокая производительность Google Chrome — мифы и реальность»
          • +7
            Картинки в формате WebP отображаются только во браузерах Chrome, Opera и Yandex.

            У меня Mozilla Firefox, так что иллюстрации из Вашей блогозаписи не видны мне.
            • +1
              И, вероятно, они и не будут видны: на соответствующем баге стоят пометки «WONTFIX» («не внедрять в производство») и «DO NOT COMMENT» («не обсуждать»).
              • 0
                У меня Firefox 17.0.1, в оригинальной статье я не видел потерь картинок, а в перевод они вставлены прямо оттуда. Я даже не заметил, какой собственно у них формат.
              • 0
                Тикет открыт в 2010 году, и несмотря на «DO NOT COMMENT» его обсуждение продолжается там и в 2013 году
                • 0
                  И в том же обсуждении люди говорят, что пока спецификация webp не устаканится, нет смысла её реализовывать.
            • 0
              мило) «представлен в другой половине 2008 года» ))
              • 0
                «не первой, а другой»
                • 0
                  исправил, спасибо
                • 0
                  поскольку лежащий в основе протокол (TCP) оптимизирован под большие, потоковые загрузки

                  О, боже… Эта фраза слила эту статью в канализацию (это слеш к автору, не к переводчику)
                  • 0
                    (удалил)
                    • +4
                      Хм. Субъективно, последняя Опера куда отзывчивее Хрома.
                      • +5
                        У хрома главная проблема — прожорливость. Сколько бы памяти не было на компе, рано или поздно он сожрет всю и начнет тупить. Опера в этом плане очень экономная.
                        • –7
                          У меня все нормально, 4 гига из 8.
                          • +7
                            наверное — это ирония ;-)?
                            • 0
                              Нет. У меня постоянно под 50 открытых вкладок и хром — один из основных инструментов работы.
                              • +5
                                Opera, 68 открытых вкладок, 2.1гига памяти, ни малейших признаков тормозов. Вкладок больше, памяти в 2 раза меньше. На ноутбуке с 4 гигами памяти это критично.
                                • –2
                                  Да я и не спорил, что опера жрет меньше. Мне хром нравится, а память дешевая. Поставить пару планок, и проблем не видать.
                                  • +6
                                    Память ради браузера ставить? Увольте.
                                    Потом, она все равно кончится рано или поздно.
                                    А если еще и на ультрабуке или последнем макбуке с распаянной памятью сидишь, то это и вовсе невозможно.
                                    • –5
                                      Так надо ноутбуки нормальные покупать. Вы бы еще нетбук купили с 2 гигабайтами, а потом жаловались, что хром+фотошоп+иллюстатор тормозят что-то, когда все вместе запущено. Если мне нужна комфортная работа в той программе, к которой я привык — почему бы не выбрать компьютер, исходя из этих требований? К тому же, тут даже менять ничего не надо — купить планку памяти за 500 рублей. Вам 500 рублей жалко ради комфортной работы?

                                      К тому же, следуя вашей логике, вообще не надо новое железо покупать?
                                      Ставить новый жесткий ради фильмов? Увольте.
                                      Менять процессор ради быстрого рендера? Увольте.
                                      Поменять старый, как дерьмо мамонта комп ради новых программ? Увольте.
                                      • 0
                                        Ключевая фраза «я привык». Но надо понимать, что не каждый привык именно к хрому. И к тому, что настройки (хотя бы через ГУИ) софту не нужны. Я например, привык к работе на 2 Гб без свопа.
                                        • 0
                                          Так я и не агитирую никого. У меня нормально работает хром, о чем я и сообщил. Почему то все подумали что я говорю о «все, у кого тормозит хром — жадные люди, не способные купить новую память». Я, тащемта, немного о другом говорил.
                                          Я как нотбук выбирал? Прикинул, что у меня будет запущено, и сколько надо на это памяти. Я бы просто не купил ноутбук с распаянными 4 гигабайтами, потому что знаю что оно будет тормозить на моих задачах. На инструменте не экономлю принципиально.
                                          • 0
                                            Вы как раз говорили, что нам 500 рублей жалко :)
                                            Выбирайте выражения в следующий раз, чтобы без минусов обходиться.
                                            • 0
                                              Да мне не жалко, пусть минусуют. Высказывания не в тренде, как и мое мнение о политике, поэтому минусы это нормально.
                                        • +1
                                          Что значит «нормальные»? В чьем понимании?
                                          Ящик на 5 кило от Alienware, который без БП лучше не включать?
                                          Меня больше устраивают килограммовые легкие и тонкие ноутбуки, которые пусть и не улучшаются аппаратно, но полностью удовлетворяют моим задачам.
                                          Если есть браузер, который требует в 2-3 раза больше памяти на те же задачи, что у конкурентов, и по этой причине плохо работает на моем ноутбуке, я попросту не буду им пользоваться, а не буду пытаться обновить железо.
                                          И зачем мне «покупать планку за 500 рублей», если я могу забесплатно поставить браузер, который кушает меньше памяти?
                                          • 0
                                            Да я ж вас не агитирую. Мне удобен браузер, и я не вижу проблемы в том, чтобы поставить ради его использования дополнительную память.
                                            • –1
                                              1. Вы высказываетесь неэтично. Вы здесь не один, поэтому не делайте так, пожалуйста.
                                              За базаром надо следить иногда.
                                              2. Не вижу проблемы не использовать браузер, который мне не нравится, и который кушает больше памяти, чем конкуренты. Если браузер не запускается на ноутбуке за 50 тыс.р., то я не буду менять ноутбук, а поменяю браузер.
                                    • 0
                                      А ведь были времена, когда в Опере при 200 открытых вкладках не больше метров 500 отжиралось… Эх, просрали полимеры.
                                      • +1
                                        Ну, на статике в мегабайт за страницу это не проблема в любом браузере.
                                        Дело не в полимерах, а в бизнесе, в интерактивных сайтах и рекламе, вы теперь не посетитель сайта, а потребитель интерактивного контента.
                                    • +1
                                      это не нормально — 4 гига для барузера, даже если 50 вкладок. — это что каждая вкладка занимает 4 000 000/ 50 =80 мегабайт?
                                      большинство ноутов, нетбуков и офисных компов оборудованы 4 гигами — это если они относительно современные — и как работать? А если помимо хрома еще и офис открыть?
                                      Поэтому и подумал, что ирония.
                                      • –3
                                        Ну, так, если в средствах стеснен — то да, лучше оперу.
                                        • 0
                                          То есть все браузеры кроме Google Chrome — для нищебродов? ;) Вы-таки неправы.
                                          Почему вы считаете, что наличие средств должно определять выбор браузера? И почему Ваши личные предпочтения должны стать идеальными для окружающих?

                                          Хром продукт своеобразный. Имея 16ГБ ОЗУ на домашней машине, я им все-таки не пользуюсь. Не нравится.
                                          • –1
                                            Да ладно, не нервничайте.
                                • –6
                                  И причина — в той самой (хваленой) идеологии и архитектуре: на каждую вкладку делать отдельный процесс! Более того, у хрома процессов больше чем вкладок. Именно за это я его не признаю как браузер. Разработчики, верните ключ --single-process!
                                  • +3
                                    У меня, кстати, тоже с этим проблема. На рабочем десктопе с Linux пришлось перейти обратно на Firefox, потому что оставленный работать на долгое время Chrome съедал всю память и остальным процессам ничего не оставалось.
                                  • –1
                                    Хм. Субьективно, последняя опера просто ад кромешный. (пользователь Linux)
                                  • –8
                                    Упал Flash — упали все вкладки, на которых он есть.
                                    • +3
                                      Да? У меня обычно просто ругается на крах плагина, но вкладка остается. Вот когда падает или принудительно закрывается одна вкладка — вместе с ней могут закрыться еще 2-3, с которыми она находилась в одном процессе.
                                      • 0
                                        У меня флеш если крешится, то на всех вкладках всех отдельно открытых окон одновременно, перезагрузка вкладок помогает.
                                        Разница поведения у разных пользователей может быть связана с плагинами, типа AD-Block.
                                        Есть подозрения, что плагины не запускаются как отдельные процессы для каждой вкладки, и могут свою энтропию в поведение всего хрома вносить.
                                        • 0
                                          Ну вкладки-то не падают. Например гмейл, который использует флеш толи для звуков, толи для уведомлений — продолжает работать, и даже перезапускает через какое-то время флеш.
                                          • +1
                                            На некоторых сайтах падение флеша равносильно падению вкладки. (youtube, например)
                                            И когда падает на десятке вкладок флеш, их нужно все перезагрузить, опять начинается кеширование и т.п.
                                    • 0
                                      100-300 мс. небольшая, но уже заметная задержка
                                      300-100мс. запрос в обработке

                                      Я думаю имелось в виду 300-1000 мс.
                                      • 0
                                        По-моему, таблица реакции пользователей на задержку больше относится к интерфейсу приложений, а не сайтам. 1 секунда задержки в какой-то сложной операции (тот же аякс-запрос, например) — это очень быстро. Я бы для сайтов сдвинул все ровно на один пункт вперед.
                                        • 0
                                          В оригинале промежуток от 1с. «Mental context switch», мне кажется, это тогда, когда пользователь кликал-кликал, все мысли были о сайте, и тут задержка в секунду, и у него есть время подумать «кажется, я собирался выгулять собаку». То есть он не перешел еще никуда, но внимание немножко утрачено.
                                          • +1
                                            Ну, если только так. Потому что в противном случае психоз на тему «омайгод, задержка больше одной секунды!» — это из разряда «You need professional help».
                                            • +1
                                              Я, например, если вкладка не грузится, переключаюсь на другую или просто закрываю. Зависит от общей занятости и важности вкладки.
                                              • 0
                                                Это понятно, что если во вкладке фейсбук и ли вконтакт, то там через пару секунд грусть наступает. Но далеко не все сайты открываются так же быстро. Время отклика сильно варьируется в зависимости от того же хостинга.
                                                • –2
                                                  Обычно сайты всё же не такие важные как, скажем, Джира или Твиттер. Зачастую есть альтернативы, например, если это результаты поиска. Такие вкладки просто закрываются, если не загружаются за несколько секунд (а интернет быстрый, то есть это нетипично долго).
                                                  • –2
                                                    Нуууууу, а если это онторнет-могозин с хостингом в Китае или Америце, то что? Там далеко не секунда. Про миллисекунды я вообще говорить не хочу — мне изначально непонятно, как можно исследовать ТАКУЮ скорость реакции пользователя. Теоретически если только.

                                                    • +1
                                                      Разумеется, время загрузки должно быть больше ожидаемого. Если вы сёрфите китайский интернет (или наоборот из Азии российский или европейский), то не будете ждать быстрой загрузки.
                                                      А меряли очень просто: ускорили сайт на N миллисекунд — увеличилась конверсия на несколько процентов.
                                                      • 0
                                                        Это весьма примитивная статистика, не правда ли? То есть, к примеру, если потенциальная аудитория состоит из пользователей фейсбука, то конверсия будет такая, а если из нормальных людей — совсем иная. Иными словами, понятно, что обыватель суть нечто среднее между пользователем фейсбука/вконтакта и среднестатистического сайта БЕЗ миллиарда выделенных серверов, но это, на мой взгляд, лишь подчеркивает субъективность данных.
                                                        • +1
                                                          Это статистика покупок Амазона, если конкретно, реально увеличился доход. Есть несколько других подобных примеров. Они весьма убеждают.
                                                          • –1
                                                            Вооооот, уже понятнее, откуда такие данные. Но Амазон != весь интернет, к сожалению (или к счастью). То есть с реальностью эта статистика имеет очень мало общего, увы. Об том и речь, собственно.
                                                            • +1
                                                              Даже не знаю, что в таком случае может вас убедить. Реальная статистика скорости сайтов весьма удручает на самом деле. Многие из них грузятся больше четырёх секунд! Поэтому сократив время загрузки хотя бы до одной-двух можно получить заметное преимущество. Есть даже программные продукты, которые позволяют это сделать по довольно низкой цене (ниже з/п специалиста). Такая оптимизация по силам и небольшим сайтам.
                                                              • 0
                                                                Попробуйте на практике поработать с недорогими хостингами в США из России — узнаете массу нового. Сразу скажу, что местный хостинг даже не рассматривается в виду объективных причин.
                                                                • 0
                                                                  И под такие хостинги оптимизируют. А вообще это хороший повод задуматься о более приличном варианте.
                                                                  • 0
                                                                    Чудес не бывает, и оптимизация — не панацея. Это со стороны кажется, что именно так дело и обстоит, но на практике все иначе. Как, собственно, и во всех областях человеческой деятельности.
                                                                    • 0
                                                                      А никто не говорил, что это панацея, просто она даёт эффект. Иногда весьма заметный.
                                                                      • 0
                                                                        Никто и не спорил об эффекте изначально — речь шла об актуальности статистики, которая, как выяснилось, очень субъективна.
                                                                        • 0
                                                                          Судя по вашим вопросам, вы её в глаза не видели.
                                                                          • 0
                                                                            Я эту статистику вижу не первый год из разных источников. Так что, мимо.
                                                                • 0
                                                                  да ладно — в России есть довольно недорогие хостинги, если надо приведу примеру, с пингом в 20-30 миллисекунд. Это я правда про VPN — а уж как вы VPN настроите. Да и ping до штатов 120-130 — не весь что конечно, но заставить интернет магазин открываться, практически мгновенно вполне можно. И потом речь идет не о полной загрузки страницы, а о субъективном времени отклика — к примеру если картинки подгружаются, а текст уже виден, можно считать, что пользователь уже зафиксировал загрузку страницы.
                                                                  • 0
                                                                    Дело не в цене, а в качестве и количестве предоставляемых услух. То, за что я плачу 20 баков в США, в России с меня попросят тыщ пять. Я лично выбираю меньшее время отклика, но нормальный сервис.
                                                                    • 0
                                                                      Под качеством я понимаю:
                                                                      1) стабильность
                                                                      2) высокую скорость
                                                                      3) хорошую техподдержку

                                                                      Все это есть — и цены… ну у меня нет проектов с трафиком гигабайтным и хранимыми объемами в десятки гигабайт, поэтому возможно я не замечаю разницы в цене.
                                                                      • 0
                                                                        Ну а я люблю свободу еще. Если мне захочется создать 100 баз — я создам, нужно залить файл гигов на 10 — залью, понадобилось в 3 ночи решить вопрос — решу, и т. д. Нашим хостингам до такого еще очень далеко.
                                                                        • 0
                                                                          Баз сколько хочешь, 10 гигов пожалуйста, автоматически увеличивается место, и доп.плата идет по дням. Удалил 10 гигов — можно обратно дисковую квоту вернуть, что бы не переплачивать.
                                                                          С ТП — да, бывают, что не отвечают оперативно — особенно на выходных или праздниках. Но по будням — очень оперативно.
                                                                          Так что не все так плохо.
                                                                          • 0
                                                                            что это за русский хостинг такой?
                                                                            • 0
                                                                              ispserver.com/ru/products/vps_vds_hosting/index.html в младшем тарифе 5 гигов — но дополнительный гиг 1 евро в месяц
                                                                              Цены не самые низкие — но ТП решает — помогают в настройках — и даже в решении частных проблем с кодом иногда подсказывают решения.
                                        • 0
                                          Занимательно, спасибо.
                                          • +2
                                            Почему тогда в Xроме текущая вкладка лагает при открытии фоновой?
                                            В Опере хоть 10 вкладок одновременно открой, такого не наблюдается
                                            • 0
                                              Похоже, что «особенности» механизма кеширования
                                            • +1
                                              В отличие от этого подхода, в основе Chrome лежит мульти-процессная архитектура, которая предоставляет каждой странице свой отдельный процесс и память, создавая что-то вроде жестко изолированной песочницы для каждой вкладки.

                                              Это только у меня при зависании одной страницы хром умирает со всеми вкладками?
                                              • 0
                                                У меня он просто повисает, и если закрыть «провинившуюся» вкладку, он снова начинает нормально работать.
                                                • 0
                                                  Регулярно вешаю вкладку яваскриптом во время разработки, никогда еще остальные не висели при этом.
                                                  • 0
                                                    Как это вы его вешаете яваскриптом, если не секрет? На ум приходит только бесконечный while.
                                                    • 0
                                                      Типа того. Не досмотрел чего-нибудь где-нибудь и всё, оно погрузилось в раздумья.
                                                • +1
                                                  Скажите, а откуда вы взяли вот эти утверждения:
                                                  1) «100-300 мс — небольшая, но уже заметная задержка» (из таблицы) и
                                                  2) «Неофициальное правило производительности в среде веб-приложений: отображайте ваши страницы, или, по крайней мере, предоставьте визуальный ответ на действие пользователя в течении 250мс».

                                                  По приведенной вами ссылке на Response Times: The 3 Important Limits, я этих чисел не нашла, а хотелось бы почитать подробнее.
                                                  • 0
                                                    Делить промежуток 0.1 — 1 секунды на два — это инициатива автора, я только переводчик. По приведенным ссылкам, в статье, которую вы упомянули, и тех, на которых она ссылается, есть только промежуток 0.1 — 1 (хотя делается оговорка «A delay of 0.2-1.0 seconds does mean that users notice the delay and thus feel the computer is „working“ on the command»). Возможно, он цитировал из памяти, как совокупность раньше прочитанных материалов. К сожалению, я не могу корректировать данные статьи, нарушая целостность оригинала.
                                                  • 0
                                                    Один я подумал, что речь пойдет об оптимизации производительности?

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