Золотое правило производительности

От переводчика: Это перевод заметки товарища по имени Steve Souders, который очень плотно занимается вопросами производительности веб-сайтов и даже написал пару неплохих книг на эту тему.

Вчера я проводил семинар в Google Ventures для некоторых из инвестируемых ими компаний. Я не знал насколько подготовленной в вопросах производительности будет аудитория, так что я сделал обзор вопросов, связанных с производительностью, начиная с первых моих выступлений в 2007 году. Уже несколько лет я не рассказывал о методах улучшения производительности, описаных в моем блоге "High Performance Web Sites". Я прошелся по таким вещам, как Меньше HTTP-запросов, Добавление заголовка Expires и Gzip.

Но мне надо было вернуться еще дальше. Думая о тех временах, когда еще не существовало конференции Velocity и самого понятия WPO, я решил, что должен пояснить почему я занялся именно клиентской оптимизацией. Я нашел слайды, поясняющие «Золотое правило производительности»: 80-90% времени ожидания пользователем занимает работа браузера.

На слайдах были данные по времени отработки сервера и клиента для популярных сайтов, но данные были устаревшими и ограниченными, так что я решил обновить их. Вот, что получилось.



Для начала пример «водопада», показывающего распределение времени сервер/клиент для сайта LinkedIn. Серверное время – это время, необходимое серверу для отдачи первого байта клиенту. Оно включает в себя несколько процессов: выборка по БД, вызовы удаленных веб сервисов, собирание HTML-страницы из шаблонов и т.д. Клиентское время — это все остальное. Оно включает в себя очевидные фазы, такие как выполнение JavaScript'а и рендер страницы. Так же в него входит время, затрачиваемое на загрузку всех необходимых ресурсов. Я включаю это время в клиентское, потому что фронтэнд-разработчики могут уменьшать его, применяя асинхронную загрузку скриптов, объединение скриптов и таблиц стилей и разнесение ресурсов по разным доменам.



Для получения результатов, имеющих отношение к реальности, я сделал выборку по сайтам, входящим в Топ-10. Среднее клиентское время составило 76%, что чуть ниже, чем заявлено в золотом правиле. Но не забывайте, что эти сайты оптимизированы по-максимуму и два из них – поисковые страницы (не результаты, а именно страница запроса), на которых очень мало лишних ресурсов.



Для более типичной картины я просмотрел 10 сайтов, находящихся в рейтинге ближе к 10,000-отметке. Клиентское время здесь составило 92%, что намного больше, чем время сайтов из Топ-10 и даже больше, чем время, заявленное в золотом правиле.



Чтобы донести это правило до участников семинара, я показал графики для их сайтов. Клиентское время составило 84%. Это позволило мне добиться от них согласия с тем, что самая большая проблема в производительности это клиент, и что именно на клиентской оптимизации надо сосредоточиться.



После этого я понял, что у меня есть информация из HTTP Archive. Я не показываю конкретные данные, потому что считаю, что реальные пользовательские данные более репрезентативны, но я посчитал среднее время для всех 50,000 сайтов, который были обработаны архивом. Оно составило 87%.



Было очень приятно, что обновленная информация только подтверждает правило, сформированное в 2007-ом году и мотивирует дальше заниматься вопросами клиентской оптимизации. Если вы радеете за доступность и расширяемость вашего сервиса – обратите свое внимание на серверную оптимизацию. Но если вам не все равно как долго пользователи ждут загрузки вашего сайта – сфокусируйтесь на клиентской оптимизации.

Оригинал.

От переводчика: Я перевел эту очевидную для кого-то заметку с одной целью – напомнить, что какие бы вы ни преследовали цели в вашем проекте и какими бы вы ни были крутыми, ваш сайт должен работать быстро для конечного пользователя, иначе он просто не дождется загрузки и уйдет к конкурентам.
Поделиться публикацией
Ой, у вас баннер убежал!

Ну. И что?
Реклама
Комментарии 47
    0
    А где ссылка на оригинал?
      +1
      Слона-то я и не приметил. Спасибо. Проставил.
        0
        И топик перевод тоже?
          +1
          К сожалению, в recovery mode нельзя написать топик-перевод.
      +2
      Эх, эти бы слова, да корпоративным решениям в уши… Почему-то в энтерпрайзе ну никак не заботятся о производительности, зачастую весь упор в стабильность/надежность. Что за люди?..
        +10
        Это как просить в доме быстрый лифт, который иногда пробивает крышу и улетает в космос. :)
          –1
          Ну как раз количество этих «иногда» и характеризует качество решения — нет?)
            +7
            Для энтерпрайза должно быть «никогда». ) Помню, кто-то критиковал рекламу MS «не более 2 дней отказа в год» сравнивая ее с «не более двух пожаров в офисе». Довольно хорошая формулировка.
              +3
              «Должно быть», и «есть» — разные вещи. Покажите хоть один продукт без факапа? Даже супер-пупер надежный Оракл лег под Сбербанком.
                0
                у Сбербанка все ляжут: и люди, и БД.
          –2
          «Тише едешь дальше будешь»?

          Что вы бы предпочли: чтобы введенные/полученные вами данные отправились быстро или чтобы они были переданы без ошибок?
            +3
            Почему от этого должны страдать конечные пользователи? Книгу Алана Купера читали? Очень рекомендую.
              0
              Психбольница в руках пациентов?
                0
                За что минус? Это название книги.
            +2
            Ну некоторые и заботятся.
            Чуть больше 2х лет назад мы приняли решение, что на клиенте вообще не должно быть никакой логики.
            Это относится и к скорости и к сложности поддержки.
              +3
              Это в свете нынешних мощностей браузеров-то? Ну-ну… Далеко пойдете.
                –1
                Мощность браузера компенсируется удобством отладки и написания кода на C# по сравнению с JS
                  +6
                  Т.е. «все для программистов», так? Вы для себя решения пишите, или для пользователей? Клиенту абсолютно неважен ваш стек технологий, ему важно удобство пользования вашим софтом. Все ваши проблемы по отладке — это ваши проблемы, и за их решение вы берет деньги. А ломить огромные суммы (именно столько стоит весь энтерпрайз), и при этом ложить на клиента — это кидалово.
                    0
                    Удобство программиста = стоимость и надежность ПО.
                    Клиентом обычно выступает заказчик а не пользователь
                    Заказчику важно быстро, не дорого, надежно.
                    При этом, если пользователь не получает особых проблем — то все в плюсе.
                    Хотя, пользователь, конечно проблемы получает.
                    Ентерпрайз пользователи они такие — для них любой новый продукт это плохо, ему надо обучаться.
                      +1
                      ОК, я понял вашу позицию. Вам этот линк тоже будет полезен.
                  0
                  Статья красиво демонстрирует недостаточность мощности браузера :)
                    0
                    Статья демонстрирует только запущенность вопроса клиентской оптимизации.
                      0
                      А заодно и запущенность архитектурных решений в плане распределения задач между сервером и клиентом.
              0
              Заголовок не совсем соответствует действительности.
              Все же первостепенно: производительность на стороне сервера. Если у вас страница генерируется 10 секунд, то вам уже будет пофиг как долго загружается страница вообще. Если скорость отдачи контента низкая, то уже не актуально, как он хорошо клиентски оптимизирован.
              Да и в моей практике наблюдаю проблему низкой скорости генерации страниц, а не того, что у меня потом долго страница генерится.
                +3
                Ну все-таки разговор не об абсолютных величинах. А соотношении. То есть, если принять что сервак в норме отдаст страницу за 1 секунду, а на клиенте она будет обрабатываться 9 секунд (10%/90%), то лучше оптимизировать клиент на, допустим, ~10% и получить 1+8 секунд, чем оптимизировать сервер на те же ~10% и получить 0.9 + 9 секунд.
                  0
                  Тут есть еще такой нюанс, когда работает браузер — то вы как правило уже видите подгружаемый контент, пусть без картинок и т. п. Когда думает сервер — пользователь вообще ничего не видит.
                  Да и когда сервер думает секунду, а на клиенте рендерится еще 9 — извините, но это пипец.

                  Может быть я не прав, но работаю в среде разработки сайтов и до сих пор острая проблема — это оптимизация производительности на сервере. Это более надежная работа сайта, это меньшая нагрузка на сервер и более дешевый хостинг. А вот проблема оптимизации на клиенте — это задача менее актуальна и пользователь не заметит небольшой разницы…
                    +5
                    И тем не менее, факт налицо. Заходим на страницу Яндекса с очищенным кэшом:
                    сервак отдает страинцу за 102 миллисекунды, клиент рендерит за 563 (domReady) / 702 (onLoad).
                    И тут как ни оптимизируй сервер, а основное время отдачи страницы — клиентское.

                    Вы мыслите как разработчик, для вас оптимизация – уменьшение нагрузки на ваши вычислительные мощности: быстрые запросы к базе, меньшая загрузка канала и так далее. А надо думать об оптимизации как потребитель контента: если вы сделаете на один join-запрос меньше страница отдастся на 2 миллисекунды быстрее, если вы объедините все скрипты, CSSки и засунете картинки в спрайты (или вообще в data:uri), заморочаетесь на написание оптимального по производительности JS'a, минимизируете все ресурсы и пожмете gzip'ом, то это уже даст вам прирост в пару сотен миллисекунд. И это будет гораздо заметнее, чем 2 миллисекунды, полученные от оптимизации запросов.

                    Другое дело, если ваш сервер совсем грустный и лишний join на хабраэффекте положит вам сайт, но это уже разговор не об оптимизации, а о неправильной архитектуре приложения.
                      +1
                      то вы как правило уже видите подгружаемый контент, пусть без картинок и т. п.

                      Далеко-далеко не факт. Особенно если контент сайта графический. Но и без этого зачастую браузер не начинает рендерить толком (кроме title) пока, как минимум, не получит страницу или ресурсы на которые она ссылается полностью. Сталкивался с такой проблемой, когда, например, сервер откуда тянутся скрипты Google Analitycs не отвечает. Не начинается рендер пока запрос по таймауту не отвалится.

                      Я бы сказал так: обеспечение приемлемого времени отклика сервера даже при пиковых нагрузках — необходимое условие, чтобы посетитель не ушёл (исключая случаи когда ему именно этот сервис нужен, типа gosulugi). Необходимое, но не достаточное. Обеспечение приемлемого времени рендеринга основного контента страницы — второе необходимое условие. Вернее это два слагаемых одного необходимого условия — обеспечение приемлемого времени от начала запроса (действий пользовател — нажал ентер, кликнул по ссылке) до конца рендеринга основного контента и доступа к основной функциональности.
                  +2
                  Вообще, графики могут сильно меняться в зависимости от того на каком клиенте смотреть страницу.
                  Старый дешевый планшет
                  Нетбук с атомом
                  Рабочая станция на последнем i7 c разгоном и наворотами

                  Другое дело что при разработке надо учитывать «целевую аудиторию» и соответственно нагружать клиента
                    +14
                    Смотрю на твиттер, который даже из кеша у меня открывается 5-8 секунд… 3 МБ переданных данных… #АГОНЬ!
                      0
                      ну как же, очень ведь важно обработать такую прорву данных, как последние двадцать твитов из вашей твит-ленты
                      +2
                      Первая мысль после запуская Хабра и Контакта на перебранном компе (+ к поколению процессора, + 2 Гб ОЗУ) — «Что они такое сделали с сайтами, что апгрейда компа НАСТОЛЬКО заметен в скорости работы???».

                      Так что статья очень полезная — наглядно демонстрирует проблему.
                        0
                        Аналогичная мысль была про Хабр после апгрейда, причём даже ОЗУ не менялось, проц стал многоядерным и видяха +N поколений.
                          0
                          Не знаю, не знаю, у меня хабр сейчас быстро загрузился и на телефоне с процессором 1 Ггц и 512 МБ памяти.
                            +1
                            Я не о том, что скорость до апгрейда была неприемлемой :)

                            Апгрейд компа привел к заметному относительному росту скорости загрузки. Это говорит о том, что воспринимаемая человеком скорость загрузки определяется в данном случае не сервером и не каналом связи, а производительностью клиентской машины. Причем нагрузка на эту машину падает ого-го какая.

                            Разработчики сайтов так увлеклисть скриптами, стилями и прочей интерактивностью, что умудрились неслабо перегрузить компьютеры клиентов.
                              +2
                              Скорее дело не в нагрузке (хотя и этого хватает), а в последовательной загрузке.

                              Например, браузер не покажет страницу, пока не загрузится внедрённый скрипт, так как там может быть document.write().

                              Или страница не будет отрисована, пока не загрузятся стили и скрипты после них в <head> так как скрипт может изменить стили.

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

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

                              Разработчики эти моменты часто не учитывают. Именно такими вопросами занимается Стив Саудерс.
                                0
                                Спасибо за пояснение :) Вопросы последовательной загрузки я как-то упустил из виду.

                                А в дополнение к нагрузке на вычислительные ресурсы и тормозам из-за неоптимального хода загрузки стоит упомянуть размер загружаемого контента. Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме), ограничениях на объем трафика и его тарификации. Льют сотни килобайт ради пары страниц (то есть, примерно 2-5 кбайт для сайта без информативной графики) полезной информации.
                                  0
                                  Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме)

                                  Факт. Самый яркий пример — отсутствие height на картинках лотов в ebay, из-за чего страница поиска все время «ползет», пока на 100% не загрузится. Посадить бы их программистов на диалап на недельку, сразу бы все вычистили )
                                    0
                                    Мы в компании часто ставим себе на рабочие места наш же софт, попробовать, что же вышло :)

                                    А вообще опытная эксплуатация и подбор условий тестирования — то, что нужно. И тестовые условия (канал, монитор, мощность процессора и так далее) лучше выбирать посуровее — тогда у большинства пользователей все будет Ок :)
                                      0
                                      С height есть одна засада: если делать max-width:100%, то картинки не будут масштабироваться пропорционально уменьшению ширины, если не вмещаются.
                                        0
                                        Именно в этом конкретном примере потребуется аж один дополнительный столбец в описании лота — высота картинки или ее соотношение сторон, чтобы генерировать сразу тег img c нужными размерами. Просто это никому не надо, а на 100Mb интернете и не заметно.
                                      0
                                      Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме), ограничениях на объем трафика и его тарификации.

                                      Я бы не винил огульно разработчиков. Такие вещи как максимальный объём страницы и всех ресурсов к ней должны быть в ТЗ на основании маркетингового исследования целевой аудитории сайта — какие у них каналы, какие возможности девайсов и т. п. Удовлетворить всех практически невозможно и потому приходится игнорировать некоторых ради удобства остальных.
                                        0
                                        Да, будет офигенно, если такой пункт появится в ТЗ (хотя бы внутреннем, для программистов и верстальщиков). А в своем предыдущем комментарии под «разработчиками» я имел в виду команду в сборе (и маркетологов, промахнувшихся мимо сотовых каналов, тоже).
                              –1
                              Есть же очевидное на первый взгляд решение — собирать запросы картинок, файлов скриптов и стилей в один «пакетный» запрос (отправлять на сервер имена сразу всех файлов которые нужны странице), в ответ на что сервер склеивал бы все в один большой файл и отсылал. Этим самым можно было бы преодолеть сетевые лаги.
                              Да, это не совсем вписывается в существующий http-протокол, но что мешает реализовать это как альтернативу в последних версиях серверов и браузеров? Типа как SPEEDY
                                0
                                Надо учитывать много факторов — не все так просто как кажется.
                                  0
                                  Лучше придумать заново, чем возиться со старыми костылями. Например почему загрузка js файлов браузером блокирует загрузку остальных элементов страницы. И т.п. Если посмотреть со стороны в этом нет смысла
                                –1
                                Хорошая статья. Стив и переводчик молодцы. Именно поэтому мы сделал автоматический продукт для ускорения любых PHP сайтов.

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

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