Pull to refresh

Comments 47

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

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

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

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

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

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

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

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

Так что статья очень полезная — наглядно демонстрирует проблему.
Аналогичная мысль была про Хабр после апгрейда, причём даже ОЗУ не менялось, проц стал многоядерным и видяха +N поколений.
UFO landed and left these words here
Я не о том, что скорость до апгрейда была неприемлемой :)

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

Разработчики сайтов так увлеклисть скриптами, стилями и прочей интерактивностью, что умудрились неслабо перегрузить компьютеры клиентов.
UFO landed and left these words here
Спасибо за пояснение :) Вопросы последовательной загрузки я как-то упустил из виду.

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

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

А вообще опытная эксплуатация и подбор условий тестирования — то, что нужно. И тестовые условия (канал, монитор, мощность процессора и так далее) лучше выбирать посуровее — тогда у большинства пользователей все будет Ок :)
UFO landed and left these words here
Именно в этом конкретном примере потребуется аж один дополнительный столбец в описании лота — высота картинки или ее соотношение сторон, чтобы генерировать сразу тег img c нужными размерами. Просто это никому не надо, а на 100Mb интернете и не заметно.
Такое впечатление, что многие разработчики забыли о существовании каналов в 32кбит/с (сотовый модем при не очень уверенном приеме), ограничениях на объем трафика и его тарификации.

Я бы не винил огульно разработчиков. Такие вещи как максимальный объём страницы и всех ресурсов к ней должны быть в ТЗ на основании маркетингового исследования целевой аудитории сайта — какие у них каналы, какие возможности девайсов и т. п. Удовлетворить всех практически невозможно и потому приходится игнорировать некоторых ради удобства остальных.
Да, будет офигенно, если такой пункт появится в ТЗ (хотя бы внутреннем, для программистов и верстальщиков). А в своем предыдущем комментарии под «разработчиками» я имел в виду команду в сборе (и маркетологов, промахнувшихся мимо сотовых каналов, тоже).
Есть же очевидное на первый взгляд решение — собирать запросы картинок, файлов скриптов и стилей в один «пакетный» запрос (отправлять на сервер имена сразу всех файлов которые нужны странице), в ответ на что сервер склеивал бы все в один большой файл и отсылал. Этим самым можно было бы преодолеть сетевые лаги.
Да, это не совсем вписывается в существующий http-протокол, но что мешает реализовать это как альтернативу в последних версиях серверов и браузеров? Типа как SPEEDY
Лучше придумать заново, чем возиться со старыми костылями. Например почему загрузка js файлов браузером блокирует загрузку остальных элементов страницы. И т.п. Если посмотреть со стороны в этом нет смысла
Хорошая статья. Стив и переводчик молодцы. Именно поэтому мы сделал автоматический продукт для ускорения любых PHP сайтов.
Only those users with full accounts are able to leave comments. Log in, please.