Pull to refresh

Comments 44

Спасибо, интересно. Как-то не приходило в голову сравнивать эти стандарты в таком ключе. В голове засела мысль, что все новое — хорошо. А тут статья с правильным подходом. Доверяй, но проверяй :)
а xhtml отдавался с типом application/xhtml+xml в режиме xml, который ie не поддреживает? Или в режими html с типом text/html?

в режиме HTML, пока что application/xhtml мало, кто поддерживает, чтобы на этом акцентироваться. Хотя для IE8 это могло быть решающим
У меня, если верить алертам, опера рендерит все минимум в два раза быстрее, чем это написано в таблице. Другие браузеры не проверял.
значит, у меня такой маломощный компьютер :) либо такая кривая сборка Opera
У меня опера пишет каждый раз разные результаты. Проверила во втором фоксе — та же фигня.
А результаты по Сафари win у меня в два раза больше — результаты из таблицы соответсвуют результатам загрузки этих страниц из кэша.

Может перепроверить данные на «чистых» браузерах?
а смысл? важно же, что разница есть. А какая она будет у конкретного пользователя — тут мерить и мерить… Разные каналы, разное железо, разные ОС, и т.д. и т.п.
Для чистоты статистики :) Сами результаты не важны, но соотношения результатов разных браузеров друг с другом тут не верны :)
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
У меня открывалось всё быстро, правда, Firefox 3.01 под GNU/Linux падал тоже быстро.
Статья интересная, спасибо. Но есть и неточности:

> Однако, если речь идет про «экономию на спичках», когда нам важен каждый запрос к серверу и каждая миллисекунда, то тут уже стоит задуматься — что же все-таки использовать.

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

Соглашусь, что время загрузки и время рендеринга — довольно абстрактные величины. Их тяжело точно померить (к примеру, YSlow и тот неточно работает). Однако, если мы берем определенный отрезок во времени загрузки страницы и начинаем его сравнивать с другими аналогичными страницами — тут уже и начинается настоящее исследование.

Еще раз: соврешенно не важно, что тут конкретно «время рендеринга», а что — «время загрузки». Мерилась разница произвольно взятого времени для HTML/XHTML и оптимизированного CSS-блока. Получена ощутимая разница (выходящая за пределы погрешности).
После прочтения нескольких строк из середины статьи полез в начало с надеждой увидеть заговоловок а-ля «как НЕ нужно писать сайты»…
С одной стороны вы показали, что методы оптимизации работают.

А с другой, что выигрыш 15 мс в среднем настролько некритичен, что на такую оптимизацию не стоит тратить времени (для обычных страниц, конечно).
конечно же. Но если для оптимизации не нужно дополнительных усилий (я сейчас про определенные стандарты для CSS-правил), то почему ее не применять? По копейкам и рубль набежит
UFO landed and left these words here
а нафиг это надо, всё равно для меня они одинаково грузятся?
Страница в исходном виде рендерилась 1/5 секунды.
На этом, собственно, можно было и закончить, потому что для человека это практически мгновенно.
Может быть, имело смысл рассмотреть более сложный случай?

В докладе, на который вы дали ссылку, люди сэкономили такую же долю байтов, как вы — миллисекунд. Но там это имело смысл, т.к. каждый байт на стороне сервера умножается на миллионы запросов страницы. А вы размер файлов, наоборот, увеличили. Это, извиняюсь за выражение, пессимизация.
Согласен с Вами.
То, чего пользователи фактически не заметят выльется в итоге в мегабайты потраченного трафика.
>>> Заменять мнемонические сущности &имя; или на их действительное представление.

По моему в любой адекватной книжке пишется что так делать не надо.
Предлагая писать действительное представление автор обосновывает это экономией нескольких байт (что само по себе смешно), забывая, что например значки < и > явно написанные в коде могут привести к ошибке в браузере. Хотя даже в случае успешной отработки браузера будет потеря производительности, причем достаточно существенная, ведь при рекурсивном разборе кода страницы браузер наткнется на неоднозначность выражения (то ли тег, то ли просто кавычка) и будет искать закрывающую по всему тексту (ну или по куску, зависит от оптимизаций).
Интересные исследования делаете, спасибо :)

Конкретно по этому есть неоднозначность. С одной стороны прооптимизировали, значит хорошо. С другой — это все же не время рендеринга на сервере, как уже говорили. Поэтому «по спичкам» тут не наоптимизируешь, так как будет работать быстрее на каждом отдельном клиенте, но это не просуммируешь. Следовательно очень много работы приходится делать ради того, чтобы одиночный пользователь увидел страницу на 9мс быстрее.

Такая оптимизация отлино подойдет в сложном веб-приложении с богатым клиентским интерфейсом. Там да, и с DOM работа будет скорее всего быстрее идти, сама страница будет быстрее отрисовываться и т.д.

Как-то сам комментарий отправился.
Хотел ещё сказать, что сам саму разметку предпочитаю делать в XHTML, вот только часто те, кто наполняют сайт, все портачат :)
да, идея подхвачена абсолютно верно. Просто одних теоретических статей с непонятными графиками, мне кажется, не всегда достаточно. Желательно, еще живых примеров подвалить, чтобы народ задумался :)
Такое ощущение что вы не на яндекс заходите, а играете в стрелялки. С таким стремлением вы скоро чайник или кружку разгонять будете :)
`
Польза от увеличения скорости загрузки конечно важна, но не в данном случае.
Так у меня чайник кипятит чашку воды за 40 секунд. Разгон чайников актуален! :)
А еще чашка (кружка) есть «разогнанная» — 0,7л (влазит бутылочка вина, для сравнения ))) )
UFO landed and left these words here
для всех, поддерживающих xhtml браузеров (всё есть в заголовках реквеста, если что), страница должна отдаваться с миме-типом application/xml+xhtml — тогда будет использован специальный «строгий» парсер, который не будет «пытаться исправлять ошибки верстальщика». xhtml может отдаваться как text/html только в целях совместимости с неподдерживаемым его клиентом.
у меня в опере быстрее всего загружается первая версия
Странно, у меня в ФФ2 так же — первая. (каждую ссылку открывал по 5 раз)
> это все копейки для обычных пользователей
> (на ±50мс — кого это волнует?). Однако,
> если речь идет про «экономию на спичках»,
> когда нам важен каждый запрос к серверу
> и каждая миллисекунда, то тут уже стоит задуматься

Хм… Красивое заблуждение. Все ведь понимают, что рендеринг происходить на стороне клиента? Клиент, как известно, перегрузки не заметит и 50мс тормоза — тоже. Сервер тоже ничего не запметит, потому что скорость рендеринга страницы браузерами никак не влияет на скорость взаимодействия браузеров с серверами, то есть ни одна миллисикунда не будет выиграна. Зато увеличение общего веса страницы на один кб приведет к 114гб лишнего траффика в день (по некоторым данным (http://stat.yandex.ru/), на главную Яндекса приходится в среднем 120 394 270 хитов в сутки). И вот эти самые 114гб повлияют на скорость работы сервера, причем повлияют отрицательно.

Нужно оговорится — это будет очень слабое влияние, тем более что практически все мыслимые клиенты поддерживают gzip, но тем не менее — влияние отрицательное.

Рассуждая с точи зрения оптимизации, правильнее разгружать бэкенд за счет фронтэнда, а не наоборот.
я бы сказал, что правильнее зарабатывать деньги, а не делать идеальные проекты :)
Проверял IE8. Любопытное наблюдение, первый заход 390мс. Но! При повторном заходе на страницу рендерится за 50-70мс…

Так же странно ведет себя F5 первый запуск опять сбрасывает до 330-390мс, последующие до 120-140мс.

Скорее всего IE8 как-то иначе подходит к загрузке ресурсов и тест не показывает правильной картины.
скорее всего, IE8 еще не вышел, и делать какие-то выводы преждевременно :)
Это не выводы :) Это задачка для ума :) Любопытно же — почему!
Only those users with full accounts are able to leave comments. Log in, please.