Comments 40
В целом, получается оптимизация ради оптимизации: временные затраты на разработку механизма не оправдываются уменьшением времени загрузки на миллисекунды.
Да и stage6 грузится дольше stage1...
Да и stage6 грузится дольше stage1...
нужно проводить хорошее усреднение. Результаты так и брались.
Насчет оптимизации ради оптимизации не соглашусь. Если использовать разработанный алгоритм на миллионах страниц крупного портала, например, то затраты на разработку окупятся в течение первого же месяца после внедрения.
Насчет оптимизации ради оптимизации не соглашусь. Если использовать разработанный алгоритм на миллионах страниц крупного портала, например, то затраты на разработку окупятся в течение первого же месяца после внедрения.
Не хочется спорить и доказывать, насколько подход оправдан или же не оправдан, но теория далека от практики, поэтому умножать число страниц на сэкономленное время в эксперименте не есть верный расчет. Если честно, не знаю ни одного более-менее крупного сервиса, где бы такой подход использовался. Есть примеры?
какой "такой"? Оптимизация времени загрузки? Yahoo!, Google, Яндекс.
Четвертый, пятый, шестой варианты пока нигде не используются. Третий вариант в какой-то мере использован на ya.ru и google.ru
Четвертый, пятый, шестой варианты пока нигде не используются. Третий вариант в какой-то мере использован на ya.ru и google.ru
Ну вы же представили 6 вариантов, 6-ой самый "оптимизированный" (по крайней мере у вас по табличке), соответственно, разговор идет о нем как о самом "лучшем" решении.
это ноу-хау пока нигде не применено, поскольку еще нигде не встречалось (мне лично). В каком-то виде его пытаются использовать некоторые решения по предзагрузке картинок (Image Preload), однако, они не балансируют кешированный/некешированный объем страницы и размер запрашиваемых файлов.
Я потому и написал, что считаю нужным обратить внимание общественности на этот факт.
Я потому и написал, что считаю нужным обратить внимание общественности на этот факт.
Потому что шкурка выделки не стОит. 21 век все-таки ;)
самое интересное, что ни один из десяток читателей, которые так утверждали (и тысяч, которые так думали), не смог аргументировано доказать свою позицию.
Дело не в выделке, а в подходе. Если кто-то хочет быть первым на рынке это стоит внушительных затрат, это стоимость бренда, а не продаж.
Если кто-то болтается в серединке "длинного хвоста блогосферы", то ему это совершенно ни к чему. Можно так же продолжать выливать на пользователей килобайты хлама они все равно не оценят заботы.
Дело не в выделке, а в подходе. Если кто-то хочет быть первым на рынке это стоит внушительных затрат, это стоимость бренда, а не продаж.
Если кто-то болтается в серединке "длинного хвоста блогосферы", то ему это совершенно ни к чему. Можно так же продолжать выливать на пользователей килобайты хлама они все равно не оценят заботы.
"Если кто-то хочет быть первым на рынке — это стоит внушительных затрат, это стоимость бренда, а не продаж."
"Внушительные" затраты будут израсходованы на покупку пары новых выделенных серверов хорошего провайдера + соотв. персонал по их обслуживанию абы сервис "первого на рынке" был самым надежным, быстрым и стабильным. Но никак не подкручиванием болтов каждой html-странички ради экономии 10-100 мс. Если сюда добавить скорость большинства современных соединений, то экономия совершенно смотрится как попытка выжать из запорожца еще +5 км/час, подталкивая его сзади.
"Дело не в выделке, а в подходе."
Любой подход должен быть оправдан, тем более если разговор идет о каки-то финансах и престиже. Отсюда и получается оптимизация ради оптимизации конечно, нужно во всем стараться сделать максимально оптимальное решение, но не факт, что это решение будет практически применимо кроме как ради ознакомления с технологиями.
"Внушительные" затраты будут израсходованы на покупку пары новых выделенных серверов хорошего провайдера + соотв. персонал по их обслуживанию абы сервис "первого на рынке" был самым надежным, быстрым и стабильным. Но никак не подкручиванием болтов каждой html-странички ради экономии 10-100 мс. Если сюда добавить скорость большинства современных соединений, то экономия совершенно смотрится как попытка выжать из запорожца еще +5 км/час, подталкивая его сзади.
"Дело не в выделке, а в подходе."
Любой подход должен быть оправдан, тем более если разговор идет о каки-то финансах и престиже. Отсюда и получается оптимизация ради оптимизации конечно, нужно во всем стараться сделать максимально оптимальное решение, но не факт, что это решение будет практически применимо кроме как ради ознакомления с технологиями.
дешевле все же оптимизировать, чем покупать железо и подключать высокоскоростной канал.
По поводу скорости соединений рекомендую ознакомиться с
http://webo.in/articles/habrahabr/43-ave…
По поводу скорости соединений рекомендую ознакомиться с
http://webo.in/articles/habrahabr/43-ave…
Вы не понимаете, тут не стоит выбора "чем-чем".
Если вы делаете многопосещаемую домашнюю страничку на фиговеньком хостинге, то вы можете оптимизировать ее сутками, чтобы у людей на модемных соединениях она грузилась не за 30 секунд, а, скажем, за 25.
Если же вы тот же, например, Yahoo! с сервисом Flickr, то вопроса "а не сэкономить ли нам на паре из сотен серверов и не потратить ли время на оптимизацию всего контента сервиса ради увеличения скорости загрузки на 10-100мс... (и то не факт, между прочим)" такого вопроса уже не стоит.
По поводу ссылки. Читал. Да, увеличился средний размер. Да, уже 2008, не 2003 (5 лет, однако). Да, у меня есть безлимитный интернет со скоростью до 10 мбит/с. Еще практически ни один сайт меня не заставил задуматься в контексте "да, долго грузится, видимо, клиентская часть не оптимизирована, а так бы грузилось на 100 мс быстрее" :) Но это факт, которого не избежать, и пытаться затормозить бульдозер руками бессмысленно.
Если вы делаете многопосещаемую домашнюю страничку на фиговеньком хостинге, то вы можете оптимизировать ее сутками, чтобы у людей на модемных соединениях она грузилась не за 30 секунд, а, скажем, за 25.
Если же вы тот же, например, Yahoo! с сервисом Flickr, то вопроса "а не сэкономить ли нам на паре из сотен серверов и не потратить ли время на оптимизацию всего контента сервиса ради увеличения скорости загрузки на 10-100мс... (и то не факт, между прочим)" такого вопроса уже не стоит.
По поводу ссылки. Читал. Да, увеличился средний размер. Да, уже 2008, не 2003 (5 лет, однако). Да, у меня есть безлимитный интернет со скоростью до 10 мбит/с. Еще практически ни один сайт меня не заставил задуматься в контексте "да, долго грузится, видимо, клиентская часть не оптимизирована, а так бы грузилось на 100 мс быстрее" :) Но это факт, которого не избежать, и пытаться затормозить бульдозер руками бессмысленно.
я бы переформулировал следующим образом "для Вас пока не стоит выбора". Западные тенденции рано или поздно докатятся до нас, и лучше быть о них осведомленным, чем с ужасом в один прекрасный день понять, что конкуренты-таки обошли, а как даже не понятно.
Вы уже придумываете факты. Для меня всегда есть выбор, но выбор рациональный.
Вы пользуетесь GMail'ом? Если да, то я уверен, что вы используете не простой html-интерфейс, а стандартный, с кучей скриптов, доп. фишечек-рюшечек, которые весят по сравнению с упрощенным ой как немало.
Вы пользуетесь GMail'ом? Если да, то я уверен, что вы используете не простой html-интерфейс, а стандартный, с кучей скриптов, доп. фишечек-рюшечек, которые весят по сравнению с упрощенным ой как немало.
Автоматизация 6-го метода для крупных, динамически обновляемых порталов, потребует серьезной доработки движка. Эти человеко-ресурсы гораздо целесообразнее вложить в разработку нового функционала и доработку уже существующего. Более экономически оправдано.
Поэтому проще использовать несколько простых методов оптимизации типа gzip и включения css в html, чем гнаться за спортивными рекордами.
Вообще, такая гипер-оптимизация больше подходит для редко обновляемого сайта со статикой. Для корпоративных сайтов, которые ничего более сделать для своих посетителей не могут.
Поэтому проще использовать несколько простых методов оптимизации типа gzip и включения css в html, чем гнаться за спортивными рекордами.
Вообще, такая гипер-оптимизация больше подходит для редко обновляемого сайта со статикой. Для корпоративных сайтов, которые ничего более сделать для своих посетителей не могут.
т.е., вы считаете, что для RuTube легче купить пару серверов, чем сделать предзагрузку preview для роликов?
Я лично считаю это банальной ленью и наплевательским отношением к пользователям.
Я лично считаю это банальной ленью и наплевательским отношением к пользователям.
Каким образом предзагрузка, нагибающая сервер точно таким же образом, решит проблему о покупке 2х новых серверов?
цифра взята наобум. У меня нет данных о загрузке серверов RuTube и их серверной площадке. Однако, чтобы ускорить загрузку страницы потребуются примерно такие усилия (т.е. предзагрузка картинок примерно эквивалентна докупке нового железа в смысле общей производительности, а не уменьшения числа запросов).
Проблема в том, что ситуация, когда страница грузится со всеми картинками за полминуты всех устраивает, и никто ее менять не собирается. А это простая экономия пользовательского времени.
Лично я уже перестал заходить на сайты, которые дольше 5 секунд показывают мне белый экран, ибо для меня это показатель.
Проблема в том, что ситуация, когда страница грузится со всеми картинками за полминуты всех устраивает, и никто ее менять не собирается. А это простая экономия пользовательского времени.
Лично я уже перестал заходить на сайты, которые дольше 5 секунд показывают мне белый экран, ибо для меня это показатель.
Ну как же так, уважаемый: то мы говорим про оптимизацию, а то количество запросов нам не интересно. Т.е. пусть сервером заведуют кто-нибудь-там, их проблемы, зато на клиенте будет быстрее на 100мс?
"Лично я уже перестал заходить на сайты, которые дольше 5 секунд..."
Хм...а я хожу на сайты, от которых мне есть польза, а не которые только быстро показывают "картинку".
"Лично я уже перестал заходить на сайты, которые дольше 5 секунд..."
Хм...а я хожу на сайты, от которых мне есть польза, а не которые только быстро показывают "картинку".
про спрайты я писал уже много раз и рассказывал на РИТ'2008. Их внедрение сложнее в технологическом плане, однако, если создатели RuTube об этом позаботятся - вполне может получится гораздо более существенный прирост производительности.
http://webo.in/articles/rit2008/speed-up…
Начет сайтов не придирайтесь к словам. Если у меня будет на выбор два сайта с примерно одинаковым содержанием, я выберу более быстрый. Хабр пока один такой :)
http://webo.in/articles/rit2008/speed-up…
Начет сайтов не придирайтесь к словам. Если у меня будет на выбор два сайта с примерно одинаковым содержанием, я выберу более быстрый. Хабр пока один такой :)
Разве я говорил что-то про покупку серверов? Хотя и такого варианта не исключаю :)
Скорости растут, как уже неоднократно замечали. Я уверен, что новая "фишка" может принести пользователей больше, чем несколько сэкономленных миллисекунд.
Все сильно зависит от целей и задач, стоящих перед сайтом. И исходя из них нужно решать что делать.
Скорости растут, как уже неоднократно замечали. Я уверен, что новая "фишка" может принести пользователей больше, чем несколько сэкономленных миллисекунд.
Все сильно зависит от целей и задач, стоящих перед сайтом. И исходя из них нужно решать что делать.
Абсолютно неюзабельно. Спасибо.
Я вот попереходил по страницам тестов - результаты для любой одной и той-же страницы могут различаться на два порядка. На локальной машине ещё можно было-бы усреднять результаты, но на боевом сервере любая цифра не несёт никакой информаци, кроме степени удачливости пользователя.
В каком браузере вы тестили? У меня в FF3.0 потоками загружалось на равных или даже немного быстрее, чем вариант 1.
«Ведь отображение страницы начнется только после загрузки всех стилей» — верно не для всех браузеров. Я вот регулярно в опере успеваю заметить страницу до применения стилей.
Просто несколько раз встречалась уже эта мелочь, раздражает : )
Просто несколько раз встречалась уже эта мелочь, раздражает : )
А собственно вопрос: если не брать в рассчет gzip и "пробельную" оптимизацию...
Ведь CSS, Javascript, картинки - все они при нормальных настройках браузера и сервера подгружаются лишь при первом заходе на сайт. А при последующих - у пользователя все уже подгружено и грузится с сервера только сама HTML страничка.
К тому же, у современных браузеров достаточно хорошо развита многопоточность и все внешние файлы начинают грузиться сразу же.
PS Получается - оптимизация на один раз (не беру в рассчет картинки в выводимые в виде контента)
Ведь CSS, Javascript, картинки - все они при нормальных настройках браузера и сервера подгружаются лишь при первом заходе на сайт. А при последующих - у пользователя все уже подгружено и грузится с сервера только сама HTML страничка.
К тому же, у современных браузеров достаточно хорошо развита многопоточность и все внешние файлы начинают грузиться сразу же.
PS Получается - оптимизация на один раз (не беру в рассчет картинки в выводимые в виде контента)
Еще одно характерное заблуждение.
Во-первых, правильная настройка кеширования далеко не везде встречается.
Во-вторых, случается так, что от страницы к странице ресурсы "прыгают" каждый раз новые файлы грузятся (это могут быть и CSS, и JS, разнесенные с целью минимизации трафика, про картинки я вообще молчу).
В-третьих, загрузка сайта у пользователя это очень сложное понятие, оно включает загрузку сайта у каждого пользователя в его браузере, а от 30 до 80% пользователей могут зайти на сайт в первый (и может быть, в последний) раз для них не оптимизировать? Это даже не смотря на то, что не все браузеры корректно кеширование воспринимают (FF3 очень интересно кеширует с настройками по умолчанию).
В-четвертых, я уже молчу про вопросы "сброса кеша" у клиента и кеширования для распределенной системы хостов...
В-пятых, шестых и т.д. — нюансов много
Во-первых, правильная настройка кеширования далеко не везде встречается.
Во-вторых, случается так, что от страницы к странице ресурсы "прыгают" каждый раз новые файлы грузятся (это могут быть и CSS, и JS, разнесенные с целью минимизации трафика, про картинки я вообще молчу).
В-третьих, загрузка сайта у пользователя это очень сложное понятие, оно включает загрузку сайта у каждого пользователя в его браузере, а от 30 до 80% пользователей могут зайти на сайт в первый (и может быть, в последний) раз для них не оптимизировать? Это даже не смотря на то, что не все браузеры корректно кеширование воспринимают (FF3 очень интересно кеширует с настройками по умолчанию).
В-четвертых, я уже молчу про вопросы "сброса кеша" у клиента и кеширования для распределенной системы хостов...
В-пятых, шестых и т.д. — нюансов много
UFO just landed and posted this here
отличное исследование, коечто взял на заметку
Sign up to leave a comment.
Оптимизация размера файлов: уплотняем поток