Pull to refresh

Торопятся ли браузеры показать нам веб?

Reading time3 min
Views1.6K
Насколько современные браузеры справляются со своей основной обязанностью — отображать сайты, не заставляя пользователей ждать излишне?

Я заметил что очень часто страницы отображаются неразумно долго — вроде уже и заголовок окна появился, а страница всё белеет. Заглядываю в исходный код, тот загружен, даже закрывающий тег HTML есть.

Помнится, когда-то, апологеты партизанских браузеров пеняли IE на то что тот ждёт полной загрузки страницы (с таблицами) прежде чем начать её отображать. Но вот прошли годы, и браузеры забыли свои революционные идеалы. А и были ли они? Кажется всё-таки были. Или «просто» сайты стали сложнее…


В принципе, этот опыт мне подтверждать особо не нужно — для меня это очевидно и на хорошем соединении на работе, и особенно на модеме 33,6 дома. Но захотелось увидеть:
— насколько именно браузеры затягивают с отрисовкой,
— все ли поступают так
— и на всех ли страницах.

К тому же, формальный опыт полезен и чтобы побороть особенности браузеров, которые даже исходный код (Ctrl+U) считывают с сайта заново — пусть они и правы в какой-то степени, но оценить реальность проблемы это мешает.

Das Experiment


И я провёл такой эксперимент: обработал напильником простенький локальный прокси, который, бибикая, сообщает мне когда заканчивается отдача основного документа (index.html) — это первая отметка по секундомеру. Затем, когда начинает отображаться страница, я отмечаю второе время.

Первое время, время загрузки голого HTML я принял за 100%. Время начала отрисовки, которое меня и интересует, отсчитывал относительно этих 100%.

Я использовал три сайта из разных категорий:
на базе WordPress (38 subdocuments: 6 css + 15 img + 8 JS),
старая статья на Хабре (83 subdocs: 4 css + 59 img + 15 js),
статья в Википедии (30 subdocs: 8 css + 16 img + 6 js).

Результат:


       Opera, Safari, ie, K-meleon, Chrome и Fx (Firefox).

Выводы


— все подопытные отрисовывали страницы сильно позже чем им становился доступен исходный код;

— ни один и не думал начинать отрисовку не дожидаясь полной загркзки HTML (всё-таки 20-30-40 секунд — это серьёзный срок) — в таком разрезе, разрыв между «как есть» и «как удобно» становится ещё более существенен;

— все отрисовывали базовый HTML страницы единым залпом, включая уже и CSS (всё без картинок, конечно) — ждали CSS, скрипты? в любом случае, мне такое не по нраву;

— среди основных, исследованных бро исключений нет;

— среди web-страниц исключений, по моим оценкам, тоже немного.

 
Конечно, с длинными текстами на lib.ru браузеры справляются так как мне надо, но всё-таки большинство сайтов next door не такие простые, совсем не такие. Я вот, так получилось, посещаю в основном «небыстрые» сайты; хорошо бы, конечно, узнать точно сколько в инете тех и других.

Технические подробности


Версии браузеров, все под Windows XP:
— Opera 9.6
— Safari 3.2.1
— IE6
— K-Meleon 1.1.5 Gecko/20080406
— Chrome 1.0.154.36
— Firefox/3.0.5 Gecko/2008120122
— звиняйте, других нима

Перед каждой загрузкой чистил кэш. Прогонял каждый сайт по одному разу — считаю этого достаточно да и утомительно это. Прокся мультипоточная.

Опыты производились на крайне низкоскоростном интернет-соединении, без искусственных ограничений :-). Но, считаю, на эксперименте это отрицательно не сказывается — я даже не привожу абсолютных цифр — если у юзер агента не справился с заданием за 30 секунд, то не справится и за 3 (даже наоборот, это помогло управлять секундомером с минимальной погрешностью). Погрешность, по моим подсчётам, составляет менее 2% (0.5 с / 20 с).

UPD: Всё-таки приведу абсолютные данные для второго эксперимента. Без этого результаты не так апокалиптичны (-:

opera	23	88
safari	33	100
ie	27	102
kmeleon	19	72
chrome	46	142
firefox	24	123

В первой строке HTML засосался на 23-й секунде, а начал отрисовываться на 88-й.

Tags:
Hubs:
Total votes 111: ↑94 and ↓17+77
Comments80

Articles