Pull to refresh

Comments 80

Браузеры перепроверяют код, дабы не отобразить его неправельно ^_^
да даже на быстром соединении (>600 килобайт/секунду) хабр иногда загружается очень медленно.
Заголовок уже появился, а загрузки страницы приходится ждать иногда полминуты.
Посмотрите в код этой страницы:
21 js-файл
4 css
Странно подошли. Требуется, имхо, четко знать время парсинга + рендеринга странички без влияния сторонних факторов. Для этого на самом деле вижу только один вариант — брать WebKit (можно Chromium отдельно), Gecko& etc — быстренько написать легкий wrapper и сделать замеры на рендер одного фрейма каждого из указанных сайтов.

Теперь мы берем ваше время «простоя» и вычитаем из него «полезную нагрузку» рендеринга. Получаем время, которое с вашей точки зрения «отнял у нас браузер». Задержка будет в небольших пределах. Осталось понять что происходит в этот период. Думаю это будет инициализация и работа JS-движков, достаточно большое количество проверок (они еще на этапе парсинга начнутся) и куча полезных операций без которых «ну никак».

Не понял вашего резюме (если это не бенчмарк браузеров).

Есть сомнение в оптимальности подхода? Берем открытые платформы, заглядываем внутрь анализируем, придумываем, потом контрибутируем свои наработки в коммунити.

Есть ощущение всемирного заговора? Аналогично. Берем открытые платформы как в предыдущем варианте, только контрибутируем в прессу :)

В любом случае, спасибо за бенчмарк браузеров и вполне адекватные результаты.
А зачем знать время парсинга? У браузеров была минута-полторы чтобы отрендерить HTML. Явно это не затраты на парсинг. Они чего-то ждут.

Ну вот абсолютные данные:

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/
это как с компьютерами в принципе, мощности оных растут в геометрической прогрессии, а зрительно скорость работы и отдача всеравно кажутся медленными :)
[irony] Это, конечно же, заговор [/irony]
ну в этом есть и доля правды…
экономически невыгодно сразу делать, к примеру, абсолютно защищенную, быструю и надежную систему… выгодно к этому идти годами, через десятки промежуточных этапов :)
Добро пожаловать в NHK
Отдача не кажется медленной. Она такая и есть :-)

Леонид Каганов как-то неплохо пофлеймил на эту тему — сравнивая (совсем) старые текстовые редакторы типа Лексикона с современными по скорости отклика.
мля, Лексикон :))) мне почему-то сразу вспомнился Supaplex… эх… :)
> Текст не подготовлен в ХабраРедакторе.
Чудно :)

Я тоже заметил что хабр показывается далеко не во время загрузки. Хотя если страница большая, с множеством комментариев, то обычно всеже во время загрузки.
ерунда какая. опера почти вровень с ИЕ. невероятно просто!
Если кто не понял — мерялось время начала отрисовки, а не быстродействие. То есть если скармливать браузеру страницу со скоростью 100 байт в секунду, то различия в быстродействии браузеров сводятся на ноль на любом железе. На передний план выходит именно то, через сколько времени относительно загрузки HTML браузер начнёт рендеринг. Хотя конечно данный тест не совсем корректен в свете того, что мы не видим не тамлайне загрузки других частей страницы — CSS, картинок, скриптов, flash. Может тот браузер, у которого начало рендеринга ближе к 100% относительно загрузки страницы просто уже на тот момент успел загрузить всё это и в абсолюте его время худшее (т.е. скажем для него полоска ста процентов равна четырём минутам, а для другого — двум).
Ну меня интересует прежде всего текст. С этой точки зрения, считаю, тест предельно корректен. Когда открываю статью на вики или хабре, я хочу быстрее начать её читать (или ознакомляться с ней). Вот такие мои скромные притязания :-)
браузеры на движке WebKit быстрее всего выдают страницу напоказ)
еще Konquerora не хватает в обзоре…
и вообще интересно было бы посмотреть на этот же тест в линуксе
Ещё можно Arora потестировать. Чисто WebKit-овый браузер. И под Windows легко ставится.
Да и Konqueror, в общем-то, тоже. Искать тут
> браузеры на движке WebKit быстрее всего выдают страницу напоказ)
Теперь, после открытия данных, мы видим, на сколько быстрее :)
Возможно, я ошибаюсь. Но много раз замечал по статусной строке браузера, что тормоза происходят в то время, когда грузятся счетчики (особенно этим грешат счетчики от мэйл.ру). Т.е., прогрузка страницы идет нормалььно, а потом вдруг начинает «тормозить». В этот момент в строке статуса — эта самая надпись с адресом счетчика.
И да. Это не относится к Хабру. Так, к слову пришлось.
Машина довольно мощная (C2D E6550, 2Gb RAM), скорость линии тоже в порядке (ADSL 1 Mbps). OS KUbuntu 8.04.1.
Да, я тоже обратил внимание, что браузер «тормозит» из-за ожидания загрузки счетчиков, рекламных баннеров и тому подобных ресурсов со сторонних URL'ов. Эти ресурсы иногда расположены на странице во фрейме.
Дык надо давно уже поотключать счётчики и рекламу, ибо толку от них лично вам никакого, а общее торможение добавляется.
Кстати, неплохая реклама вышла бы плагинам, блокирующим нежелательный контент, если бы автор провёл этот же тест на браузерах с установленным отрезалками лишнего. Наверняка всё быстрее бы зашевелилось! :)
Ну да, идея неплохая для будущих тестов :-)
насколько мне известно, все плагины только скрывают рекламу, но все равно тянут её. тут бы скорее протестировать фильтрующие прокси, причем вот какой методой:
1) берется самый актуальный (на текущий момент) список фильтров,
2) броузер с такой проксёй прогоняется по какому-нибудь списку сайтов
3) замеряем результат
повторяем 1-2-3 для всех имеющихся прокси, сравниваем, делаем выводы

почему зашла речь о списках фильтров? потому что сами-то прокси дело нехитрое, а вот обновление/поддержка фильтров — дело хлопотное, и причем бесплатное обычно. Поэтому как я понимаю, для многих прокси эти списки не обновлялись очень давно
Не знаю как остальные, но AdBlock Plus не только скрывает. Я смотрел логи запросов к серверу — всё на весьма кошерном уровне.
Многие нехорошие девелоперы грешат тем, что вставляют счетчик вверх страницы, добавляют кучу скриптов, которые выполняются в сразу, не дожидаясь загрузки страницы. Время начала рендеринга сайта — полностью на совести девелопера.
Согласен, чаще всего тормозят самые маленькие, но внешние элементы дизайна.

У меня скорость загрузки и отрисовки резко увеличилась после установки на FF расширений NoScript и ImgLikeOpera (позволяет настраивать загрузку картинок из кэша). Но всё равно сейчас блужу/браужу в Хроме, ибо зело шустр вопреки странной схожести с русским названием обратного качества ))

Более того. После установки NoScript зашел на «Одноклассники» в режиме максимального запрета скриптов — а движок сайта меня выкидывает и просит подтвердить, что я человек. Вот это был номер ))
А не могла ввести свои коррективы нестабильность низкоскоростного интернет-соединения?
Вряд ли. Как видите, результат весьма стабилен — в том отношении что никто не начал отрисовку до загрузки, все начаинают на 200-300-400%.

Если бы я сравнивал загрузку страницы с баннерорезкой и без, то да — тут бы понадобились и повторы, и стабильность.
а, собственно, чем полезны результаты этого эксперимента?
Выводом: не делайте у себя 83 subdocs: 4 css + 59 img + 15 js :)
UFO just landed and posted this here
Хороший и быстрый анализ :)
Получается, что Гугль все-таки улучшает для нас скорость просмотра инета.
…как Хромой-то на своих костылях скачет!
UFO just landed and posted this here
Видимо, автора это устраивает. С другой стороны, раньше действительно все сетовали на IE что он дожидался полной загрузки, а сейчас эвон — оказывается IE делал все верно?
Нет. Приоритеты изменились. Когда сотовые телефоны только появились — важным параметром была чувствительность телефона. Если телефон у вас просто сигнал не берёт, то так ли важно сколько он весит и как удобно лежит в руке? Сейчас же чувствительность в обзорах не учитывается, покупателями не оцениваются. Зачем? Все телефоны работают почти везде (ибо станций сейчас больше), так что вес, размер и количество цветов — важнее.

Вот и с браузерами так же: во времена модемов способность показать страницу без полной загрузки (где MS IE, кстати, обыгрывал Netscape 4.x, но проигрывал Netscape 6.x) была чуть ли не основным показателем (собственно на ней Netscape и обыграл всех конкурентов до того, как в битву включился Microsoft), сейчас — это мало кого волнующий фактор. Ну кто сейчас пользуется модемом???
>>Ну кто сейчас пользуется модемом???
Видимо, автор топика :)
два часа от москвы — и люди уже сидят на диалапе :) ну, или, дорогостоящем спутнике )
Проблема проявляется не только на модеме. И на вполне себе хороших распространённых скоростях.

Другое дело что не все замечают. Но кому-то и несколько секунд потраченных на показ контекстного меню не в тягость.

Но насчёт приоритетов согласен. Они поменялись. Жаль.
Ну, если проверялась способность браузеров рендерить страницу по мере загрузки, то следовало применить другой метод:
а. Создать HTML страничку размером до 1Мб (без яваскрипта)
б. Загружать её на модеме по вашей методике.

Вы убедитесь в том, что увидите верхнюю часть страницы до того как она (страница) подгрузится полностью (т.е. до того как ваш прокси просигналит)

Если же страница содержит яваскрипт, то браузер грузит его (JS файл) и тормозит рендеринг страницы до окончания загрузки.
Т.е. в вашем «тестировании» с 6/8/15 JS файлами вы фактически замеряли скорость их загрузки, а не скорость рендеринга HTML.
Там не всё так просто — многие виды JavaScript'а могут отработать до загрузки страницы. И отрабатывают. Но браузер всё равно притормаживает этот процесс немного чтобы сгладить проблемы кривых рук (формально JS можно пускать сразу, но на практике если так сделать — ничего работать не будет).
Наверное, это зависит от браузера.
Я разрабатываю в Firefox, и могу сказать точно, что он криворукости не прощает.
Т.е. если поставить скрипт с обращением к элементу, который ещё не успел подгрузиться, то вылезет ошибка.

Тут ещё зависит от того, где расположены тэги подгрузки скриптов <script>
Не зря developer.yahoo.com советует грузить скрипты в конце страницы, где возможно.
Там по ссылке ещё много интересного, разработчики JS должны были это уже видеть.
а я разрабатываю на Opera 9, Opera 10, FF2, FF3, Chorme, Safari, IE6, IE7, он криворукости не прощяет! (:
В опере есть опция Advanced — Browsing — Loading. По умолчанию там стоит Redraw after 1 second. Поставьте Redraw instantly.
ну, во-первых, браузер может начать отображение (и начинает рендеринг) ДО того, как получен последний байт из HTML.
Во-вторых, процентное соотношение здесь вообще не уместно — возьмите комп в два раза слабее и в два раза сильнее — получите цифры, слабо связанные с цифрой в 2. Тут важно абсолютное время: играет роль как канал, так и пользовательский процессор, операционная система и множество других факторов.
В-третьих, один раз прогонять в силу указанных причин задержек крайне неразумно. Нормальные результаты начинаются с 10-15 раз.
В-четвертых, есть же диаграмма загрузки в том же Firebug / Web Inspector — в ней отлично видно, когда получен HTML, а когда сработан DOMContentLoaded
Согласен, вот только одно замечание: у меня (ff3) страница начинает отображаться намного раньше чем DOMContentLoaded в Firebug (3 секунды против 9 секунд).
Проценты вполне уместны если представлять сколько секунд в 100% — их там 20-30-40, как я писал.

Вот типичный пример: HTML засосался на 23-й секунде, а начал отрисовываться на 88-й. Как бы, полторы минуты вполне достаточно чтобы начать рисовать :-) И проц ни при чём.

Но надо было конечно это уточнить, каюс.
елки-палки. Может, стоит изучать мат. часть, прежде чем делать какие бы то ни было предположения?

Если CSS-файлы раположены в начале документа, были загружены быстрее, чем сам HTML, и не было никаких JS-файлов в head — тогда HTML-страница будет отрисована в браузере постепенно, как браузер будет HTML получать из сокета.

Если же множество файлов в head-секции страницы тянутся дольше, чем могли бы, — то при чем здесь HTML вообще? стоит рассмотреть разницу между загрузкой ВСЕХ файлов, необходимых браузеру для отображения страницы на экране, и отображением этой страницы. Вот тут как раз будет играть роль мощность пользовательского компьютера.

В Вашем случае канал перебивает все издержки, связанные с работой браузеров, поэтому говорить о том, что «браузеры утаивают контент» вообще бессмысленно. Тут можно говорить о моделях загрузки страницы в разных браузерах и криворукости разработчиков, которые эти модели не учитывают (в частности, то, что в IE максимум 2 потока к хосту, а CSS/JS-файлы вообще по одному грузятся).

Если рассмотреть более приближенный к нормальным условиям случай, когда канал примерно 100КБ/с, то тут уже скорость обработки браузером информации начинает на что-нибудь влиять.
Ну да, про тянучку-JS в HEAD я не подумал.

P. S. Делать выводы-предположения опасно :-)
Может, если у человека дома 33600, то он и отрисовывал это на p2-300?

Надо понимать, что скачвание контента — наименее тяжелая для браузера задача, правильно распарсить, обработать ошибки (если они есть) и отрисовать — намного тяжелее в плане процессорного времени.

Я на своем макбуке и замерять дельту между нажатием на «enter» и полной отрисовкой страницы того-же хабра засечь не смогу — оно просто стремится к нулю :)
процессорного времени — да, но никак ни общего времени. загрузка как правило занимает больше времени чем парсинг, например загрузка идет 5сек, при этом проц свободен, а парсинг займет 0.1сек при нагруженном проце
Проц двухядерный 1.8GHz какой-то.
эм… а что ты хочешь увидеть до загрузки стилей?
img-fotki.yandex.ru/get/3313/sairi-na-tenshi.11/0_1ef7d_5d841f0e_orig
Текст. Ради которого я (в большинстве случаев) и оказаюсь на том-ином сайте.

Причём даже не обязательно для чтения. Для оценки той же — соответствует ли он моим ожиданиям (если я с поиска, пришёл).
Так раньше опера делала. Особенно это было на мобильных устройствах. Скажу Вам: уж лучше дождаться страницы целиком, чем видеть перестройку страницы каждые 50 мс…
не знаю как в других, но вот насчет оперы:
инструменты — настройки — обозреватель — перерисовывать страницу — непрерывно
и опера начнет показывать страничку по мере ее загрузки (у меня например) но это неприколько, потому как она начинает жутко извиваться, двигаться и вообще вести себя неадекватно… так что я лучше подожду пока она загрузит основные элементы и отрисует их
Что то у меня таких ключей вообще нет.
Firefox 3.0.6
Вы будете смеяться, что создавать новые ключи тоже можно.
А зачем мне «непрерывно»? «Неприкольно» тоже не надо. Имея на руках ХТМЛ, просто хочу его видеть. Пусть и не до полной загрузки, но хотя бы без сильных опозданий.
«непрерывно» — и есть «хочу его видеть» + «не о полной загрузки»
я, например, вижу хабр до его полной загрузки, вижу сперва топик без каментов, они появляются позже
совершенно необъективное исследование, считаю.

например, на хабре js грузятся В НАЧАЛЕ страницы. и что вы хотите? ответ очевиден (-:
Ну да, об этом факторе я особо не думал. Но странно что все сайты такие. Плохая, плохая реальность :-)
многие проекты зарабатывают деньги и совершенно не заботятся о скоростях и т.п.
их больше волнует скорость разработки, чтобы быстрее выложить новую версию.

я считаю, лучше выбрать золотую середину.
imho, результаты не могут быть взяты на веру, так как у вас слишком много случайных факторов (медленный канал со скачками скорости, нагрузка на сервер и разница в скорости выдачи им результатов, другие процессы на вашей машине с браузером)
и к тому же
" Прогонял каждый сайт по одному разу "
Бенчмарк подразумевает многократные повторения и сбор статистической информации.

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

В любом случае, пользователь не готов видеть чистый не отрендереный html, который дёргается и извивается по мере загрузки стилей и скриптов, пользователя это напугает и он начнёт звонить администратору с криками «Алярма! Алярма! Вирусы!»
Прокси использовался именно «локальный».

Повторения для бенчмарков вообще нужны. Но кокретно моему — нет. Потому что все результаты примерно одинаковы (я ведь не сравниваю какой бро круче). Неужели данных 18 прогонов вам недостаточно — они ж все одинаковые. На что вы надеетесь после повторений, на чудо? Ну так его не произойдёт. Можете убедиться при желании :-) Я тратить силы излишне не захотел.
хочется надеяться на представительные данные )
а вы пишете о 30-40 секундах на загрузку? так это проблема канала а не браузеров )
без загрузки всех скриптов и стилей из блока head вряд ли разумно показывать страницу, в этом здравый смысл head-блока.

по крайней мере стили в head наверняка потребуют тотального reflow.
А мне понравилось обозначение браузеров как химических элементов.
Интересный факт в тему:
на Ubuntu 8.10 стоит апач, пхп, мускул. Все это используется для разработки сайтов на Drupal. Даже на глаз заметно, при разработке сайта (работает локально установленный апач), опера работает много быстрее firefox. Что обидно, так как сильно привык использовать огнелиса. Так и живу сейчас: для серфинга использую firefox (на внешних сайтах притормаживание огнелиса не так сильно заметно), а при разработке сайтов юзается опера.
Ты, батенька, тож не фонтан после такого высказывания =)
Есть что по делу сказать?
основная беда кроется в обработке «tag soup», если бы Html изначально был более строг к правилам, то всё бы было конечно же значительно быстрее. а пока движок обработает все возможные комбинации «что же там имел этот школьник с кучей не закрытых тегов», то конечно же это будет тормозить.

нахождение счётчиков вообще считаю дурным тоном. мало того что они действительно тормзят загрузку, к тому же ещё и являются визуальным мусором.
Sign up to leave a comment.

Articles