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