Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 47
Эх, эти бы слова, да корпоративным решениям в уши… Почему-то в энтерпрайзе ну никак не заботятся о производительности, зачастую весь упор в стабильность/надежность. Что за люди?..
Это как просить в доме быстрый лифт, который иногда пробивает крышу и улетает в космос. :)
«Тише едешь дальше будешь»?
Что вы бы предпочли: чтобы введенные/полученные вами данные отправились быстро или чтобы они были переданы без ошибок?
Что вы бы предпочли: чтобы введенные/полученные вами данные отправились быстро или чтобы они были переданы без ошибок?
Почему от этого должны страдать конечные пользователи? Книгу Алана Купера читали? Очень рекомендую.
Ну некоторые и заботятся.
Чуть больше 2х лет назад мы приняли решение, что на клиенте вообще не должно быть никакой логики.
Это относится и к скорости и к сложности поддержки.
Чуть больше 2х лет назад мы приняли решение, что на клиенте вообще не должно быть никакой логики.
Это относится и к скорости и к сложности поддержки.
Это в свете нынешних мощностей браузеров-то? Ну-ну… Далеко пойдете.
Мощность браузера компенсируется удобством отладки и написания кода на C# по сравнению с JS
Т.е. «все для программистов», так? Вы для себя решения пишите, или для пользователей? Клиенту абсолютно неважен ваш стек технологий, ему важно удобство пользования вашим софтом. Все ваши проблемы по отладке — это ваши проблемы, и за их решение вы берет деньги. А ломить огромные суммы (именно столько стоит весь энтерпрайз), и при этом ложить на клиента — это кидалово.
Удобство программиста = стоимость и надежность ПО.
Клиентом обычно выступает заказчик а не пользователь
Заказчику важно быстро, не дорого, надежно.
При этом, если пользователь не получает особых проблем — то все в плюсе.
Хотя, пользователь, конечно проблемы получает.
Ентерпрайз пользователи они такие — для них любой новый продукт это плохо, ему надо обучаться.
Клиентом обычно выступает заказчик а не пользователь
Заказчику важно быстро, не дорого, надежно.
При этом, если пользователь не получает особых проблем — то все в плюсе.
Хотя, пользователь, конечно проблемы получает.
Ентерпрайз пользователи они такие — для них любой новый продукт это плохо, ему надо обучаться.
ОК, я понял вашу позицию. Вам этот линк тоже будет полезен.
Статья красиво демонстрирует недостаточность мощности браузера :)
Заголовок не совсем соответствует действительности.
Все же первостепенно: производительность на стороне сервера. Если у вас страница генерируется 10 секунд, то вам уже будет пофиг как долго загружается страница вообще. Если скорость отдачи контента низкая, то уже не актуально, как он хорошо клиентски оптимизирован.
Да и в моей практике наблюдаю проблему низкой скорости генерации страниц, а не того, что у меня потом долго страница генерится.
Все же первостепенно: производительность на стороне сервера. Если у вас страница генерируется 10 секунд, то вам уже будет пофиг как долго загружается страница вообще. Если скорость отдачи контента низкая, то уже не актуально, как он хорошо клиентски оптимизирован.
Да и в моей практике наблюдаю проблему низкой скорости генерации страниц, а не того, что у меня потом долго страница генерится.
Ну все-таки разговор не об абсолютных величинах. А соотношении. То есть, если принять что сервак в норме отдаст страницу за 1 секунду, а на клиенте она будет обрабатываться 9 секунд (10%/90%), то лучше оптимизировать клиент на, допустим, ~10% и получить 1+8 секунд, чем оптимизировать сервер на те же ~10% и получить 0.9 + 9 секунд.
Тут есть еще такой нюанс, когда работает браузер — то вы как правило уже видите подгружаемый контент, пусть без картинок и т. п. Когда думает сервер — пользователь вообще ничего не видит.
Да и когда сервер думает секунду, а на клиенте рендерится еще 9 — извините, но это пипец.
Может быть я не прав, но работаю в среде разработки сайтов и до сих пор острая проблема — это оптимизация производительности на сервере. Это более надежная работа сайта, это меньшая нагрузка на сервер и более дешевый хостинг. А вот проблема оптимизации на клиенте — это задача менее актуальна и пользователь не заметит небольшой разницы…
Да и когда сервер думает секунду, а на клиенте рендерится еще 9 — извините, но это пипец.
Может быть я не прав, но работаю в среде разработки сайтов и до сих пор острая проблема — это оптимизация производительности на сервере. Это более надежная работа сайта, это меньшая нагрузка на сервер и более дешевый хостинг. А вот проблема оптимизации на клиенте — это задача менее актуальна и пользователь не заметит небольшой разницы…
И тем не менее, факт налицо. Заходим на страницу Яндекса с очищенным кэшом:
сервак отдает страинцу за 102 миллисекунды, клиент рендерит за 563 (domReady) / 702 (onLoad).
И тут как ни оптимизируй сервер, а основное время отдачи страницы — клиентское.
Вы мыслите как разработчик, для вас оптимизация – уменьшение нагрузки на ваши вычислительные мощности: быстрые запросы к базе, меньшая загрузка канала и так далее. А надо думать об оптимизации как потребитель контента: если вы сделаете на один join-запрос меньше страница отдастся на 2 миллисекунды быстрее, если вы объедините все скрипты, CSSки и засунете картинки в спрайты (или вообще в data:uri), заморочаетесь на написание оптимального по производительности JS'a, минимизируете все ресурсы и пожмете gzip'ом, то это уже даст вам прирост в пару сотен миллисекунд. И это будет гораздо заметнее, чем 2 миллисекунды, полученные от оптимизации запросов.
Другое дело, если ваш сервер совсем грустный и лишний join на хабраэффекте положит вам сайт, но это уже разговор не об оптимизации, а о неправильной архитектуре приложения.
сервак отдает страинцу за 102 миллисекунды, клиент рендерит за 563 (domReady) / 702 (onLoad).
И тут как ни оптимизируй сервер, а основное время отдачи страницы — клиентское.
Вы мыслите как разработчик, для вас оптимизация – уменьшение нагрузки на ваши вычислительные мощности: быстрые запросы к базе, меньшая загрузка канала и так далее. А надо думать об оптимизации как потребитель контента: если вы сделаете на один join-запрос меньше страница отдастся на 2 миллисекунды быстрее, если вы объедините все скрипты, CSSки и засунете картинки в спрайты (или вообще в data:uri), заморочаетесь на написание оптимального по производительности JS'a, минимизируете все ресурсы и пожмете gzip'ом, то это уже даст вам прирост в пару сотен миллисекунд. И это будет гораздо заметнее, чем 2 миллисекунды, полученные от оптимизации запросов.
Другое дело, если ваш сервер совсем грустный и лишний join на хабраэффекте положит вам сайт, но это уже разговор не об оптимизации, а о неправильной архитектуре приложения.
то вы как правило уже видите подгружаемый контент, пусть без картинок и т. п.
Далеко-далеко не факт. Особенно если контент сайта графический. Но и без этого зачастую браузер не начинает рендерить толком (кроме title) пока, как минимум, не получит страницу или ресурсы на которые она ссылается полностью. Сталкивался с такой проблемой, когда, например, сервер откуда тянутся скрипты Google Analitycs не отвечает. Не начинается рендер пока запрос по таймауту не отвалится.
Я бы сказал так: обеспечение приемлемого времени отклика сервера даже при пиковых нагрузках — необходимое условие, чтобы посетитель не ушёл (исключая случаи когда ему именно этот сервис нужен, типа gosulugi). Необходимое, но не достаточное. Обеспечение приемлемого времени рендеринга основного контента страницы — второе необходимое условие. Вернее это два слагаемых одного необходимого условия — обеспечение приемлемого времени от начала запроса (действий пользовател — нажал ентер, кликнул по ссылке) до конца рендеринга основного контента и доступа к основной функциональности.
Далеко-далеко не факт. Особенно если контент сайта графический. Но и без этого зачастую браузер не начинает рендерить толком (кроме title) пока, как минимум, не получит страницу или ресурсы на которые она ссылается полностью. Сталкивался с такой проблемой, когда, например, сервер откуда тянутся скрипты Google Analitycs не отвечает. Не начинается рендер пока запрос по таймауту не отвалится.
Я бы сказал так: обеспечение приемлемого времени отклика сервера даже при пиковых нагрузках — необходимое условие, чтобы посетитель не ушёл (исключая случаи когда ему именно этот сервис нужен, типа gosulugi). Необходимое, но не достаточное. Обеспечение приемлемого времени рендеринга основного контента страницы — второе необходимое условие. Вернее это два слагаемых одного необходимого условия — обеспечение приемлемого времени от начала запроса (действий пользовател — нажал ентер, кликнул по ссылке) до конца рендеринга основного контента и доступа к основной функциональности.
Вообще, графики могут сильно меняться в зависимости от того на каком клиенте смотреть страницу.
Старый дешевый планшет
Нетбук с атомом
Рабочая станция на последнем i7 c разгоном и наворотами
Другое дело что при разработке надо учитывать «целевую аудиторию» и соответственно нагружать клиента
Старый дешевый планшет
Нетбук с атомом
Рабочая станция на последнем i7 c разгоном и наворотами
Другое дело что при разработке надо учитывать «целевую аудиторию» и соответственно нагружать клиента
Первая мысль после запуская Хабра и Контакта на перебранном компе (+ к поколению процессора, + 2 Гб ОЗУ) — «Что они такое сделали с сайтами, что апгрейда компа НАСТОЛЬКО заметен в скорости работы???».
Так что статья очень полезная — наглядно демонстрирует проблему.
Так что статья очень полезная — наглядно демонстрирует проблему.
Аналогичная мысль была про Хабр после апгрейда, причём даже ОЗУ не менялось, проц стал многоядерным и видяха +N поколений.
Я не о том, что скорость до апгрейда была неприемлемой :)
Апгрейд компа привел к заметному относительному росту скорости загрузки. Это говорит о том, что воспринимаемая человеком скорость загрузки определяется в данном случае не сервером и не каналом связи, а производительностью клиентской машины. Причем нагрузка на эту машину падает ого-го какая.
Разработчики сайтов так увлеклисть скриптами, стилями и прочей интерактивностью, что умудрились неслабо перегрузить компьютеры клиентов.
Апгрейд компа привел к заметному относительному росту скорости загрузки. Это говорит о том, что воспринимаемая человеком скорость загрузки определяется в данном случае не сервером и не каналом связи, а производительностью клиентской машины. Причем нагрузка на эту машину падает ого-го какая.
Разработчики сайтов так увлеклисть скриптами, стилями и прочей интерактивностью, что умудрились неслабо перегрузить компьютеры клиентов.
Спасибо за пояснение :) Вопросы последовательной загрузки я как-то упустил из виду.
А в дополнение к нагрузке на вычислительные ресурсы и тормозам из-за неоптимального хода загрузки стоит упомянуть размер загружаемого контента. Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме), ограничениях на объем трафика и его тарификации. Льют сотни килобайт ради пары страниц (то есть, примерно 2-5 кбайт для сайта без информативной графики) полезной информации.
А в дополнение к нагрузке на вычислительные ресурсы и тормозам из-за неоптимального хода загрузки стоит упомянуть размер загружаемого контента. Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме), ограничениях на объем трафика и его тарификации. Льют сотни килобайт ради пары страниц (то есть, примерно 2-5 кбайт для сайта без информативной графики) полезной информации.
Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме)
Факт. Самый яркий пример — отсутствие height на картинках лотов в ebay, из-за чего страница поиска все время «ползет», пока на 100% не загрузится. Посадить бы их программистов на диалап на недельку, сразу бы все вычистили )
Мы в компании часто ставим себе на рабочие места наш же софт, попробовать, что же вышло :)
А вообще опытная эксплуатация и подбор условий тестирования — то, что нужно. И тестовые условия (канал, монитор, мощность процессора и так далее) лучше выбирать посуровее — тогда у большинства пользователей все будет Ок :)
А вообще опытная эксплуатация и подбор условий тестирования — то, что нужно. И тестовые условия (канал, монитор, мощность процессора и так далее) лучше выбирать посуровее — тогда у большинства пользователей все будет Ок :)
Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме), ограничениях на объем трафика и его тарификации.
Я бы не винил огульно разработчиков. Такие вещи как максимальный объём страницы и всех ресурсов к ней должны быть в ТЗ на основании маркетингового исследования целевой аудитории сайта — какие у них каналы, какие возможности девайсов и т. п. Удовлетворить всех практически невозможно и потому приходится игнорировать некоторых ради удобства остальных.
Я бы не винил огульно разработчиков. Такие вещи как максимальный объём страницы и всех ресурсов к ней должны быть в ТЗ на основании маркетингового исследования целевой аудитории сайта — какие у них каналы, какие возможности девайсов и т. п. Удовлетворить всех практически невозможно и потому приходится игнорировать некоторых ради удобства остальных.
Есть же очевидное на первый взгляд решение — собирать запросы картинок, файлов скриптов и стилей в один «пакетный» запрос (отправлять на сервер имена сразу всех файлов которые нужны странице), в ответ на что сервер склеивал бы все в один большой файл и отсылал. Этим самым можно было бы преодолеть сетевые лаги.
Да, это не совсем вписывается в существующий http-протокол, но что мешает реализовать это как альтернативу в последних версиях серверов и браузеров? Типа как SPEEDY
Да, это не совсем вписывается в существующий http-протокол, но что мешает реализовать это как альтернативу в последних версиях серверов и браузеров? Типа как SPEEDY
Надо учитывать много факторов — не все так просто как кажется.
Хорошая статья. Стив и переводчик молодцы. Именно поэтому мы сделал автоматический продукт для ускорения любых PHP сайтов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Золотое правило производительности