Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 80
Браузеры перепроверяют код, дабы не отобразить его неправельно ^_^
Странно подошли. Требуется, имхо, четко знать время парсинга + рендеринга странички без влияния сторонних факторов. Для этого на самом деле вижу только один вариант — брать WebKit (можно Chromium отдельно), Gecko& etc — быстренько написать легкий wrapper и сделать замеры на рендер одного фрейма каждого из указанных сайтов.
Теперь мы берем ваше время «простоя» и вычитаем из него «полезную нагрузку» рендеринга. Получаем время, которое с вашей точки зрения «отнял у нас браузер». Задержка будет в небольших пределах. Осталось понять что происходит в этот период. Думаю это будет инициализация и работа JS-движков, достаточно большое количество проверок (они еще на этапе парсинга начнутся) и куча полезных операций без которых «ну никак».
Не понял вашего резюме (если это не бенчмарк браузеров).
Есть сомнение в оптимальности подхода? Берем открытые платформы, заглядываем внутрь анализируем, придумываем, потом контрибутируем свои наработки в коммунити.
Есть ощущение всемирного заговора? Аналогично. Берем открытые платформы как в предыдущем варианте, только контрибутируем в прессу :)
В любом случае, спасибо за бенчмарк браузеров и вполне адекватные результаты.
Теперь мы берем ваше время «простоя» и вычитаем из него «полезную нагрузку» рендеринга. Получаем время, которое с вашей точки зрения «отнял у нас браузер». Задержка будет в небольших пределах. Осталось понять что происходит в этот период. Думаю это будет инициализация и работа JS-движков, достаточно большое количество проверок (они еще на этапе парсинга начнутся) и куча полезных операций без которых «ну никак».
Не понял вашего резюме (если это не бенчмарк браузеров).
Есть сомнение в оптимальности подхода? Берем открытые платформы, заглядываем внутрь анализируем, придумываем, потом контрибутируем свои наработки в коммунити.
Есть ощущение всемирного заговора? Аналогично. Берем открытые платформы как в предыдущем варианте, только контрибутируем в прессу :)
В любом случае, спасибо за бенчмарк браузеров и вполне адекватные результаты.
А зачем знать время парсинга? У браузеров была минута-полторы чтобы отрендерить HTML. Явно это не затраты на парсинг. Они чего-то ждут.
Ну вот абсолютные данные:
В первой строке HTML засосался на 23-й секунде, а начал отрисовываться на 88-й.
Да, зря я абсолютные даные сразу не привёл.
Ну вот абсолютные данные:
opera 23 88 safari 33 100 ie 27 102 kmeleon 19 72 chrome 46 142 firefox 24 123
В первой строке HTML засосался на 23-й секунде, а начал отрисовываться на 88-й.
Да, зря я абсолютные даные сразу не привёл.
dougt.wordpress.com/2008/05/24/what-is-a-reflow/
это как с компьютерами в принципе, мощности оных растут в геометрической прогрессии, а зрительно скорость работы и отдача всеравно кажутся медленными :)
> Текст не подготовлен в ХабраРедакторе.
Чудно :)
Я тоже заметил что хабр показывается далеко не во время загрузки. Хотя если страница большая, с множеством комментариев, то обычно всеже во время загрузки.
Чудно :)
Я тоже заметил что хабр показывается далеко не во время загрузки. Хотя если страница большая, с множеством комментариев, то обычно всеже во время загрузки.
ерунда какая. опера почти вровень с ИЕ. невероятно просто!
Если кто не понял — мерялось время начала отрисовки, а не быстродействие. То есть если скармливать браузеру страницу со скоростью 100 байт в секунду, то различия в быстродействии браузеров сводятся на ноль на любом железе. На передний план выходит именно то, через сколько времени относительно загрузки HTML браузер начнёт рендеринг. Хотя конечно данный тест не совсем корректен в свете того, что мы не видим не тамлайне загрузки других частей страницы — CSS, картинок, скриптов, flash. Может тот браузер, у которого начало рендеринга ближе к 100% относительно загрузки страницы просто уже на тот момент успел загрузить всё это и в абсолюте его время худшее (т.е. скажем для него полоска ста процентов равна четырём минутам, а для другого — двум).
браузеры на движке WebKit быстрее всего выдают страницу напоказ)
еще Konquerora не хватает в обзоре…
и вообще интересно было бы посмотреть на этот же тест в линуксе
еще Konquerora не хватает в обзоре…
и вообще интересно было бы посмотреть на этот же тест в линуксе
Возможно, я ошибаюсь. Но много раз замечал по статусной строке браузера, что тормоза происходят в то время, когда грузятся счетчики (особенно этим грешат счетчики от мэйл.ру). Т.е., прогрузка страницы идет нормалььно, а потом вдруг начинает «тормозить». В этот момент в строке статуса — эта самая надпись с адресом счетчика.
И да. Это не относится к Хабру. Так, к слову пришлось.
Машина довольно мощная (C2D E6550, 2Gb RAM), скорость линии тоже в порядке (ADSL 1 Mbps). OS KUbuntu 8.04.1.
И да. Это не относится к Хабру. Так, к слову пришлось.
Машина довольно мощная (C2D E6550, 2Gb RAM), скорость линии тоже в порядке (ADSL 1 Mbps). OS KUbuntu 8.04.1.
Да, я тоже обратил внимание, что браузер «тормозит» из-за ожидания загрузки счетчиков, рекламных баннеров и тому подобных ресурсов со сторонних URL'ов. Эти ресурсы иногда расположены на странице во фрейме.
Дык надо давно уже поотключать счётчики и рекламу, ибо толку от них лично вам никакого, а общее торможение добавляется.
Кстати, неплохая реклама вышла бы плагинам, блокирующим нежелательный контент, если бы автор провёл этот же тест на браузерах с установленным отрезалками лишнего. Наверняка всё быстрее бы зашевелилось! :)
Кстати, неплохая реклама вышла бы плагинам, блокирующим нежелательный контент, если бы автор провёл этот же тест на браузерах с установленным отрезалками лишнего. Наверняка всё быстрее бы зашевелилось! :)
Ну да, идея неплохая для будущих тестов :-)
насколько мне известно, все плагины только скрывают рекламу, но все равно тянут её. тут бы скорее протестировать фильтрующие прокси, причем вот какой методой:
1) берется самый актуальный (на текущий момент) список фильтров,
2) броузер с такой проксёй прогоняется по какому-нибудь списку сайтов
3) замеряем результат
повторяем 1-2-3 для всех имеющихся прокси, сравниваем, делаем выводы
почему зашла речь о списках фильтров? потому что сами-то прокси дело нехитрое, а вот обновление/поддержка фильтров — дело хлопотное, и причем бесплатное обычно. Поэтому как я понимаю, для многих прокси эти списки не обновлялись очень давно
1) берется самый актуальный (на текущий момент) список фильтров,
2) броузер с такой проксёй прогоняется по какому-нибудь списку сайтов
3) замеряем результат
повторяем 1-2-3 для всех имеющихся прокси, сравниваем, делаем выводы
почему зашла речь о списках фильтров? потому что сами-то прокси дело нехитрое, а вот обновление/поддержка фильтров — дело хлопотное, и причем бесплатное обычно. Поэтому как я понимаю, для многих прокси эти списки не обновлялись очень давно
Многие нехорошие девелоперы грешат тем, что вставляют счетчик вверх страницы, добавляют кучу скриптов, которые выполняются в сразу, не дожидаясь загрузки страницы. Время начала рендеринга сайта — полностью на совести девелопера.
Согласен, чаще всего тормозят самые маленькие, но внешние элементы дизайна.
У меня скорость загрузки и отрисовки резко увеличилась после установки на FF расширений NoScript и ImgLikeOpera (позволяет настраивать загрузку картинок из кэша). Но всё равно сейчас блужу/браужу в Хроме, ибо зело шустр вопреки странной схожести с русским названием обратного качества ))
Более того. После установки NoScript зашел на «Одноклассники» в режиме максимального запрета скриптов — а движок сайта меня выкидывает и просит подтвердить, что я человек. Вот это был номер ))
У меня скорость загрузки и отрисовки резко увеличилась после установки на FF расширений NoScript и ImgLikeOpera (позволяет настраивать загрузку картинок из кэша). Но всё равно сейчас блужу/браужу в Хроме, ибо зело шустр вопреки странной схожести с русским названием обратного качества ))
Более того. После установки NoScript зашел на «Одноклассники» в режиме максимального запрета скриптов — а движок сайта меня выкидывает и просит подтвердить, что я человек. Вот это был номер ))
А не могла ввести свои коррективы нестабильность низкоскоростного интернет-соединения?
а, собственно, чем полезны результаты этого эксперимента?
Хороший и быстрый анализ :)
Получается, что Гугль все-таки улучшает для нас скорость просмотра инета.
Получается, что Гугль все-таки улучшает для нас скорость просмотра инета.
…как Хромой-то на своих костылях скачет!
Видимо, автора это устраивает. С другой стороны, раньше действительно все сетовали на IE что он дожидался полной загрузки, а сейчас эвон — оказывается IE делал все верно?
Нет. Приоритеты изменились. Когда сотовые телефоны только появились — важным параметром была чувствительность телефона. Если телефон у вас просто сигнал не берёт, то так ли важно сколько он весит и как удобно лежит в руке? Сейчас же чувствительность в обзорах не учитывается, покупателями не оцениваются. Зачем? Все телефоны работают почти везде (ибо станций сейчас больше), так что вес, размер и количество цветов — важнее.
Вот и с браузерами так же: во времена модемов способность показать страницу без полной загрузки (где MS IE, кстати, обыгрывал Netscape 4.x, но проигрывал Netscape 6.x) была чуть ли не основным показателем (собственно на ней Netscape и обыграл всех конкурентов до того, как в битву включился Microsoft), сейчас — это мало кого волнующий фактор. Ну кто сейчас пользуется модемом???
Вот и с браузерами так же: во времена модемов способность показать страницу без полной загрузки (где MS IE, кстати, обыгрывал Netscape 4.x, но проигрывал Netscape 6.x) была чуть ли не основным показателем (собственно на ней Netscape и обыграл всех конкурентов до того, как в битву включился Microsoft), сейчас — это мало кого волнующий фактор. Ну кто сейчас пользуется модемом???
>>Ну кто сейчас пользуется модемом???
Видимо, автор топика :)
Видимо, автор топика :)
два часа от москвы — и люди уже сидят на диалапе :) ну, или, дорогостоящем спутнике )
Проблема проявляется не только на модеме. И на вполне себе хороших распространённых скоростях.
Другое дело что не все замечают. Но кому-то и несколько секунд потраченных на показ контекстного меню не в тягость.
Но насчёт приоритетов согласен. Они поменялись. Жаль.
Другое дело что не все замечают. Но кому-то и несколько секунд потраченных на показ контекстного меню не в тягость.
Но насчёт приоритетов согласен. Они поменялись. Жаль.
занудно
Ну, если проверялась способность браузеров рендерить страницу по мере загрузки, то следовало применить другой метод:
а. Создать HTML страничку размером до 1Мб (без яваскрипта)
б. Загружать её на модеме по вашей методике.
Вы убедитесь в том, что увидите верхнюю часть страницы до того как она (страница) подгрузится полностью (т.е. до того как ваш прокси просигналит)
Если же страница содержит яваскрипт, то браузер грузит его (JS файл) и тормозит рендеринг страницы до окончания загрузки.
Т.е. в вашем «тестировании» с 6/8/15 JS файлами вы фактически замеряли скорость их загрузки, а не скорость рендеринга HTML.
а. Создать HTML страничку размером до 1Мб (без яваскрипта)
б. Загружать её на модеме по вашей методике.
Вы убедитесь в том, что увидите верхнюю часть страницы до того как она (страница) подгрузится полностью (т.е. до того как ваш прокси просигналит)
Если же страница содержит яваскрипт, то браузер грузит его (JS файл) и тормозит рендеринг страницы до окончания загрузки.
Т.е. в вашем «тестировании» с 6/8/15 JS файлами вы фактически замеряли скорость их загрузки, а не скорость рендеринга HTML.
Там не всё так просто — многие виды JavaScript'а могут отработать до загрузки страницы. И отрабатывают. Но браузер всё равно притормаживает этот процесс немного чтобы сгладить проблемы кривых рук (формально JS можно пускать сразу, но на практике если так сделать — ничего работать не будет).
Наверное, это зависит от браузера.
Я разрабатываю в Firefox, и могу сказать точно, что он криворукости не прощает.
Т.е. если поставить скрипт с обращением к элементу, который ещё не успел подгрузиться, то вылезет ошибка.
Тут ещё зависит от того, где расположены тэги подгрузки скриптов <script>
Не зря developer.yahoo.com советует грузить скрипты в конце страницы, где возможно.
Там по ссылке ещё много интересного, разработчики JS должны были это уже видеть.
Я разрабатываю в Firefox, и могу сказать точно, что он криворукости не прощает.
Т.е. если поставить скрипт с обращением к элементу, который ещё не успел подгрузиться, то вылезет ошибка.
Тут ещё зависит от того, где расположены тэги подгрузки скриптов <script>
Не зря developer.yahoo.com советует грузить скрипты в конце страницы, где возможно.
Там по ссылке ещё много интересного, разработчики JS должны были это уже видеть.
В опере есть опция Advanced — Browsing — Loading. По умолчанию там стоит Redraw after 1 second. Поставьте Redraw instantly.
ну, во-первых, браузер может начать отображение (и начинает рендеринг) ДО того, как получен последний байт из HTML.
Во-вторых, процентное соотношение здесь вообще не уместно — возьмите комп в два раза слабее и в два раза сильнее — получите цифры, слабо связанные с цифрой в 2. Тут важно абсолютное время: играет роль как канал, так и пользовательский процессор, операционная система и множество других факторов.
В-третьих, один раз прогонять в силу указанных причин задержек крайне неразумно. Нормальные результаты начинаются с 10-15 раз.
В-четвертых, есть же диаграмма загрузки в том же Firebug / Web Inspector — в ней отлично видно, когда получен HTML, а когда сработан DOMContentLoaded
Во-вторых, процентное соотношение здесь вообще не уместно — возьмите комп в два раза слабее и в два раза сильнее — получите цифры, слабо связанные с цифрой в 2. Тут важно абсолютное время: играет роль как канал, так и пользовательский процессор, операционная система и множество других факторов.
В-третьих, один раз прогонять в силу указанных причин задержек крайне неразумно. Нормальные результаты начинаются с 10-15 раз.
В-четвертых, есть же диаграмма загрузки в том же Firebug / Web Inspector — в ней отлично видно, когда получен HTML, а когда сработан DOMContentLoaded
Согласен, вот только одно замечание: у меня (ff3) страница начинает отображаться намного раньше чем DOMContentLoaded в Firebug (3 секунды против 9 секунд).
Проценты вполне уместны если представлять сколько секунд в 100% — их там 20-30-40, как я писал.
Вот типичный пример: HTML засосался на 23-й секунде, а начал отрисовываться на 88-й. Как бы, полторы минуты вполне достаточно чтобы начать рисовать :-) И проц ни при чём.
Вот типичный пример: HTML засосался на 23-й секунде, а начал отрисовываться на 88-й. Как бы, полторы минуты вполне достаточно чтобы начать рисовать :-) И проц ни при чём.
Но надо было конечно это уточнить, каюс.
елки-палки. Может, стоит изучать мат. часть, прежде чем делать какие бы то ни было предположения?
Если CSS-файлы раположены в начале документа, были загружены быстрее, чем сам HTML, и не было никаких JS-файлов в head — тогда HTML-страница будет отрисована в браузере постепенно, как браузер будет HTML получать из сокета.
Если же множество файлов в head-секции страницы тянутся дольше, чем могли бы, — то при чем здесь HTML вообще? стоит рассмотреть разницу между загрузкой ВСЕХ файлов, необходимых браузеру для отображения страницы на экране, и отображением этой страницы. Вот тут как раз будет играть роль мощность пользовательского компьютера.
В Вашем случае канал перебивает все издержки, связанные с работой браузеров, поэтому говорить о том, что «браузеры утаивают контент» вообще бессмысленно. Тут можно говорить о моделях загрузки страницы в разных браузерах и криворукости разработчиков, которые эти модели не учитывают (в частности, то, что в IE максимум 2 потока к хосту, а CSS/JS-файлы вообще по одному грузятся).
Если рассмотреть более приближенный к нормальным условиям случай, когда канал примерно 100КБ/с, то тут уже скорость обработки браузером информации начинает на что-нибудь влиять.
Если CSS-файлы раположены в начале документа, были загружены быстрее, чем сам HTML, и не было никаких JS-файлов в head — тогда HTML-страница будет отрисована в браузере постепенно, как браузер будет HTML получать из сокета.
Если же множество файлов в head-секции страницы тянутся дольше, чем могли бы, — то при чем здесь HTML вообще? стоит рассмотреть разницу между загрузкой ВСЕХ файлов, необходимых браузеру для отображения страницы на экране, и отображением этой страницы. Вот тут как раз будет играть роль мощность пользовательского компьютера.
В Вашем случае канал перебивает все издержки, связанные с работой браузеров, поэтому говорить о том, что «браузеры утаивают контент» вообще бессмысленно. Тут можно говорить о моделях загрузки страницы в разных браузерах и криворукости разработчиков, которые эти модели не учитывают (в частности, то, что в IE максимум 2 потока к хосту, а CSS/JS-файлы вообще по одному грузятся).
Если рассмотреть более приближенный к нормальным условиям случай, когда канал примерно 100КБ/с, то тут уже скорость обработки браузером информации начинает на что-нибудь влиять.
Может, если у человека дома 33600, то он и отрисовывал это на p2-300?
Надо понимать, что скачвание контента — наименее тяжелая для браузера задача, правильно распарсить, обработать ошибки (если они есть) и отрисовать — намного тяжелее в плане процессорного времени.
Я на своем макбуке и замерять дельту между нажатием на «enter» и полной отрисовкой страницы того-же хабра засечь не смогу — оно просто стремится к нулю :)
Надо понимать, что скачвание контента — наименее тяжелая для браузера задача, правильно распарсить, обработать ошибки (если они есть) и отрисовать — намного тяжелее в плане процессорного времени.
Я на своем макбуке и замерять дельту между нажатием на «enter» и полной отрисовкой страницы того-же хабра засечь не смогу — оно просто стремится к нулю :)
эм… а что ты хочешь увидеть до загрузки стилей?
img-fotki.yandex.ru/get/3313/sairi-na-tenshi.11/0_1ef7d_5d841f0e_orig
img-fotki.yandex.ru/get/3313/sairi-na-tenshi.11/0_1ef7d_5d841f0e_orig
вот вчера статейка пробегала www.thevista.ru/page.php?id=10756&comments=1 «Проблемы при оценке производительности браузеров»
Судя по вот этому посту homm.habrahabr.ru/blog/51031/ — не то что браузеры не торопятся, разработчики не хотят.
не знаю как в других, но вот насчет оперы:
инструменты — настройки — обозреватель — перерисовывать страницу — непрерывно
и опера начнет показывать страничку по мере ее загрузки (у меня например) но это неприколько, потому как она начинает жутко извиваться, двигаться и вообще вести себя неадекватно… так что я лучше подожду пока она загрузит основные элементы и отрисует их
инструменты — настройки — обозреватель — перерисовывать страницу — непрерывно
и опера начнет показывать страничку по мере ее загрузки (у меня например) но это неприколько, потому как она начинает жутко извиваться, двигаться и вообще вести себя неадекватно… так что я лучше подожду пока она загрузит основные элементы и отрисует их
Firefox -> about:config
Баловаться с nglayout.initialpaint.delay и content.notify.interval.
У меня например Хабр точно ускорился — комменты показываются по мере загрузки.
Баловаться с nglayout.initialpaint.delay и content.notify.interval.
У меня например Хабр точно ускорился — комменты показываются по мере загрузки.
А зачем мне «непрерывно»? «Неприкольно» тоже не надо. Имея на руках ХТМЛ, просто хочу его видеть. Пусть и не до полной загрузки, но хотя бы без сильных опозданий.
совершенно необъективное исследование, считаю.
например, на хабре js грузятся В НАЧАЛЕ страницы. и что вы хотите? ответ очевиден (-:
например, на хабре js грузятся В НАЧАЛЕ страницы. и что вы хотите? ответ очевиден (-:
imho, результаты не могут быть взяты на веру, так как у вас слишком много случайных факторов (медленный канал со скачками скорости, нагрузка на сервер и разница в скорости выдачи им результатов, другие процессы на вашей машине с браузером)
и к тому же
" Прогонял каждый сайт по одному разу "
Бенчмарк подразумевает многократные повторения и сбор статистической информации.
В то же время сама тема интересная, но измерения надо производить тогда уж на той же машине, где крутятся браузеры, чтобы убрать фактор случайностей в канале и на серверах, повторять на одном и том же контенте и многократно. И явно ловить момент окончания рендеринга и от него отсчитывать милисекунды до показа, потому что именно это время будет бесполезным.
В любом случае, пользователь не готов видеть чистый не отрендереный html, который дёргается и извивается по мере загрузки стилей и скриптов, пользователя это напугает и он начнёт звонить администратору с криками «Алярма! Алярма! Вирусы!»
и к тому же
" Прогонял каждый сайт по одному разу "
Бенчмарк подразумевает многократные повторения и сбор статистической информации.
В то же время сама тема интересная, но измерения надо производить тогда уж на той же машине, где крутятся браузеры, чтобы убрать фактор случайностей в канале и на серверах, повторять на одном и том же контенте и многократно. И явно ловить момент окончания рендеринга и от него отсчитывать милисекунды до показа, потому что именно это время будет бесполезным.
В любом случае, пользователь не готов видеть чистый не отрендереный html, который дёргается и извивается по мере загрузки стилей и скриптов, пользователя это напугает и он начнёт звонить администратору с криками «Алярма! Алярма! Вирусы!»
Прокси использовался именно «локальный».
Повторения для бенчмарков вообще нужны. Но кокретно моему — нет. Потому что все результаты примерно одинаковы (я ведь не сравниваю какой бро круче). Неужели данных 18 прогонов вам недостаточно — они ж все одинаковые. На что вы надеетесь после повторений, на чудо? Ну так его не произойдёт. Можете убедиться при желании :-) Я тратить силы излишне не захотел.
Повторения для бенчмарков вообще нужны. Но кокретно моему — нет. Потому что все результаты примерно одинаковы (я ведь не сравниваю какой бро круче). Неужели данных 18 прогонов вам недостаточно — они ж все одинаковые. На что вы надеетесь после повторений, на чудо? Ну так его не произойдёт. Можете убедиться при желании :-) Я тратить силы излишне не захотел.
без загрузки всех скриптов и стилей из блока head вряд ли разумно показывать страницу, в этом здравый смысл head-блока.
по крайней мере стили в head наверняка потребуют тотального reflow.
по крайней мере стили в head наверняка потребуют тотального reflow.
А мне понравилось обозначение браузеров как химических элементов.
Интересный факт в тему:
на Ubuntu 8.10 стоит апач, пхп, мускул. Все это используется для разработки сайтов на Drupal. Даже на глаз заметно, при разработке сайта (работает локально установленный апач), опера работает много быстрее firefox. Что обидно, так как сильно привык использовать огнелиса. Так и живу сейчас: для серфинга использую firefox (на внешних сайтах притормаживание огнелиса не так сильно заметно), а при разработке сайтов юзается опера.
на Ubuntu 8.10 стоит апач, пхп, мускул. Все это используется для разработки сайтов на Drupal. Даже на глаз заметно, при разработке сайта (работает локально установленный апач), опера работает много быстрее firefox. Что обидно, так как сильно привык использовать огнелиса. Так и живу сейчас: для серфинга использую firefox (на внешних сайтах притормаживание огнелиса не так сильно заметно), а при разработке сайтов юзается опера.
основная беда кроется в обработке «tag soup», если бы Html изначально был более строг к правилам, то всё бы было конечно же значительно быстрее. а пока движок обработает все возможные комбинации «что же там имел этот школьник с кучей не закрытых тегов», то конечно же это будет тормозить.
нахождение счётчиков вообще считаю дурным тоном. мало того что они действительно тормзят загрузку, к тому же ещё и являются визуальным мусором.
нахождение счётчиков вообще считаю дурным тоном. мало того что они действительно тормзят загрузку, к тому же ещё и являются визуальным мусором.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Торопятся ли браузеры показать нам веб?