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

[@medved13]

Слона-то я и не приметил. Спасибо. Проставил.

[@JiLiZART]

И топик перевод тоже?

[@medved13]

К сожалению, в recovery mode нельзя написать топик-перевод.

[@creage]

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

[@dzugaru]

Это как просить в доме быстрый лифт, который иногда пробивает крышу и улетает в космос. :)

[@creage]

Ну как раз количество этих «иногда» и характеризует качество решения — нет?)

[@dzugaru]

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

[@creage]

«Должно быть», и «есть» — разные вещи. Покажите хоть один продукт без факапа? Даже супер-пупер надежный Оракл лег под Сбербанком.

[@OlegTar]

у Сбербанка все ляжут: и люди, и БД.

[@Ataraxer]

«Тише едешь дальше будешь»?

Что вы бы предпочли: чтобы введенные/полученные вами данные отправились быстро или чтобы они были переданы без ошибок?

[@creage]

Почему от этого должны страдать конечные пользователи? Книгу Алана Купера читали? Очень рекомендую.

[@Alexufo]

Психбольница в руках пациентов?

[@Alexufo]

За что минус? Это название книги.

[@pil0t]

Ну некоторые и заботятся.
Чуть больше 2х лет назад мы приняли решение, что на клиенте вообще не должно быть никакой логики.
Это относится и к скорости и к сложности поддержки.

[@creage]

Это в свете нынешних мощностей браузеров-то? Ну-ну… Далеко пойдете.

[@pil0t]

Мощность браузера компенсируется удобством отладки и написания кода на C# по сравнению с JS

[@creage]

Т.е. «все для программистов», так? Вы для себя решения пишите, или для пользователей? Клиенту абсолютно неважен ваш стек технологий, ему важно удобство пользования вашим софтом. Все ваши проблемы по отладке — это ваши проблемы, и за их решение вы берет деньги. А ломить огромные суммы (именно столько стоит весь энтерпрайз), и при этом ложить на клиента — это кидалово.

[@pil0t]

Удобство программиста = стоимость и надежность ПО.
Клиентом обычно выступает заказчик а не пользователь
Заказчику важно быстро, не дорого, надежно.
При этом, если пользователь не получает особых проблем — то все в плюсе.
Хотя, пользователь, конечно проблемы получает.
Ентерпрайз пользователи они такие — для них любой новый продукт это плохо, ему надо обучаться.

[@creage]

ОК, я понял вашу позицию. Вам этот линк тоже будет полезен.

[@JerryJJ]

Статья красиво демонстрирует недостаточность мощности браузера :)

[@creage]

Статья демонстрирует только запущенность вопроса клиентской оптимизации.

[@JerryJJ]

А заодно и запущенность архитектурных решений в плане распределения задач между сервером и клиентом.

[@horses]

Заголовок не совсем соответствует действительности.
Все же первостепенно: производительность на стороне сервера. Если у вас страница генерируется 10 секунд, то вам уже будет пофиг как долго загружается страница вообще. Если скорость отдачи контента низкая, то уже не актуально, как он хорошо клиентски оптимизирован.
Да и в моей практике наблюдаю проблему низкой скорости генерации страниц, а не того, что у меня потом долго страница генерится.

[@medved13]

Ну все-таки разговор не об абсолютных величинах. А соотношении. То есть, если принять что сервак в норме отдаст страницу за 1 секунду, а на клиенте она будет обрабатываться 9 секунд (10%/90%), то лучше оптимизировать клиент на, допустим, ~10% и получить 1+8 секунд, чем оптимизировать сервер на те же ~10% и получить 0.9 + 9 секунд.

[@horses]

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

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

[@medved13]

И тем не менее, факт налицо. Заходим на страницу Яндекса с очищенным кэшом:
сервак отдает страинцу за 102 миллисекунды, клиент рендерит за 563 (domReady) / 702 (onLoad).
И тут как ни оптимизируй сервер, а основное время отдачи страницы — клиентское.

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

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

[@VolCh]

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

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

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

[@pil0t]

Вообще, графики могут сильно меняться в зависимости от того на каком клиенте смотреть страницу.
Старый дешевый планшет
Нетбук с атомом
Рабочая станция на последнем i7 c разгоном и наворотами

Другое дело что при разработке надо учитывать «целевую аудиторию» и соответственно нагружать клиента

[@ganqqwerty]

ну как же, очень ведь важно обработать такую прорву данных, как последние двадцать твитов из вашей твит-ленты

[@JerryJJ]

Первая мысль после запуская Хабра и Контакта на перебранном компе (+ к поколению процессора, + 2 Гб ОЗУ) — «Что они такое сделали с сайтами, что апгрейда компа НАСТОЛЬКО заметен в скорости работы???».

Так что статья очень полезная — наглядно демонстрирует проблему.

[@VolCh]

Аналогичная мысль была про Хабр после апгрейда, причём даже ОЗУ не менялось, проц стал многоядерным и видяха +N поколений.

[@JerryJJ]

Я не о том, что скорость до апгрейда была неприемлемой :)

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

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

[@JerryJJ]

Спасибо за пояснение :) Вопросы последовательной загрузки я как-то упустил из виду.

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

[@Nomad1]

Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме)

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

[@JerryJJ]

Мы в компании часто ставим себе на рабочие места наш же софт, попробовать, что же вышло :)

А вообще опытная эксплуатация и подбор условий тестирования — то, что нужно. И тестовые условия (канал, монитор, мощность процессора и так далее) лучше выбирать посуровее — тогда у большинства пользователей все будет Ок :)

[@Nomad1]

Именно в этом конкретном примере потребуется аж один дополнительный столбец в описании лота — высота картинки или ее соотношение сторон, чтобы генерировать сразу тег img c нужными размерами. Просто это никому не надо, а на 100Mb интернете и не заметно.

[@VolCh]

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

Я бы не винил огульно разработчиков. Такие вещи как максимальный объём страницы и всех ресурсов к ней должны быть в ТЗ на основании маркетингового исследования целевой аудитории сайта — какие у них каналы, какие возможности девайсов и т. п. Удовлетворить всех практически невозможно и потому приходится игнорировать некоторых ради удобства остальных.

[@JerryJJ]

Да, будет офигенно, если такой пункт появится в ТЗ (хотя бы внутреннем, для программистов и верстальщиков). А в своем предыдущем комментарии под «разработчиками» я имел в виду команду в сборе (и маркетологов, промахнувшихся мимо сотовых каналов, тоже).

[@squint]

Есть же очевидное на первый взгляд решение — собирать запросы картинок, файлов скриптов и стилей в один «пакетный» запрос (отправлять на сервер имена сразу всех файлов которые нужны странице), в ответ на что сервер склеивал бы все в один большой файл и отсылал. Этим самым можно было бы преодолеть сетевые лаги.
Да, это не совсем вписывается в существующий http-протокол, но что мешает реализовать это как альтернативу в последних версиях серверов и браузеров? Типа как SPEEDY

[@toxicdream]

Надо учитывать много факторов — не все так просто как кажется.

[@squint]

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

[@sunnybear]

Хорошая статья. Стив и переводчик молодцы. Именно поэтому мы сделал автоматический продукт для ускорения любых PHP сайтов.