Комментарии 44
Спасибо, интересно. Как-то не приходило в голову сравнивать эти стандарты в таком ключе. В голове засела мысль, что все новое — хорошо. А тут статья с правильным подходом. Доверяй, но проверяй :)
а xhtml отдавался с типом application/xhtml+xml в режиме xml, который ie не поддреживает? Или в режими html с типом text/html?
в режиме HTML, пока что application/xhtml мало, кто поддерживает, чтобы на этом акцентироваться. Хотя для IE8 это могло быть решающим
Ну судя по этой табличке все не так плохо www.w3.org/2000/07/8378/xhtml/media-types/results
Проблемы должны быть только у IE (кто бы мог подумать %)
Проблемы должны быть только у IE (кто бы мог подумать %)
У меня, если верить алертам, опера рендерит все минимум в два раза быстрее, чем это написано в таблице. Другие браузеры не проверял.
А результаты по Сафари win у меня в два раза больше — результаты из таблицы соответсвуют результатам загрузки этих страниц из кэша.
Может перепроверить данные на «чистых» браузерах?
Может перепроверить данные на «чистых» браузерах?
НЛО прилетело и опубликовало эту надпись здесь
Действительно, очень шустро!!!
Статья интересная, спасибо. Но есть и неточности:
> Однако, если речь идет про «экономию на спичках», когда нам важен каждый запрос к серверу и каждая миллисекунда, то тут уже стоит задуматься — что же все-таки использовать.
Не надо вводить людей в заблуждение(сам чуть не поверил, пока не включил здравый смысл=)). Время рендеринга страницы и время загрузки страницы — разные вещи.
> Однако, если речь идет про «экономию на спичках», когда нам важен каждый запрос к серверу и каждая миллисекунда, то тут уже стоит задуматься — что же все-таки использовать.
Не надо вводить людей в заблуждение(сам чуть не поверил, пока не включил здравый смысл=)). Время рендеринга страницы и время загрузки страницы — разные вещи.
естественно. Но время рендеринга как раз и мерилось (для большей точности нужно было не по onload выставлять, а перед ).
Соглашусь, что время загрузки и время рендеринга — довольно абстрактные величины. Их тяжело точно померить (к примеру, YSlow и тот неточно работает). Однако, если мы берем определенный отрезок во времени загрузки страницы и начинаем его сравнивать с другими аналогичными страницами — тут уже и начинается настоящее исследование.
Еще раз: соврешенно не важно, что тут конкретно «время рендеринга», а что — «время загрузки». Мерилась разница произвольно взятого времени для HTML/XHTML и оптимизированного CSS-блока. Получена ощутимая разница (выходящая за пределы погрешности).
Соглашусь, что время загрузки и время рендеринга — довольно абстрактные величины. Их тяжело точно померить (к примеру, YSlow и тот неточно работает). Однако, если мы берем определенный отрезок во времени загрузки страницы и начинаем его сравнивать с другими аналогичными страницами — тут уже и начинается настоящее исследование.
Еще раз: соврешенно не важно, что тут конкретно «время рендеринга», а что — «время загрузки». Мерилась разница произвольно взятого времени для HTML/XHTML и оптимизированного CSS-блока. Получена ощутимая разница (выходящая за пределы погрешности).
После прочтения нескольких строк из середины статьи полез в начало с надеждой увидеть заговоловок а-ля «как НЕ нужно писать сайты»…
С одной стороны вы показали, что методы оптимизации работают.
А с другой, что выигрыш 15 мс в среднем настролько некритичен, что на такую оптимизацию не стоит тратить времени (для обычных страниц, конечно).
А с другой, что выигрыш 15 мс в среднем настролько некритичен, что на такую оптимизацию не стоит тратить времени (для обычных страниц, конечно).
НЛО прилетело и опубликовало эту надпись здесь
Почему HTML 4.01 Transitional вместо HTML 4.01 Strict?
а нафиг это надо, всё равно для меня они одинаково грузятся?
Страница в исходном виде рендерилась 1/5 секунды.
На этом, собственно, можно было и закончить, потому что для человека это практически мгновенно.
Может быть, имело смысл рассмотреть более сложный случай?
В докладе, на который вы дали ссылку, люди сэкономили такую же долю байтов, как вы — миллисекунд. Но там это имело смысл, т.к. каждый байт на стороне сервера умножается на миллионы запросов страницы. А вы размер файлов, наоборот, увеличили. Это, извиняюсь за выражение, пессимизация.
На этом, собственно, можно было и закончить, потому что для человека это практически мгновенно.
Может быть, имело смысл рассмотреть более сложный случай?
В докладе, на который вы дали ссылку, люди сэкономили такую же долю байтов, как вы — миллисекунд. Но там это имело смысл, т.к. каждый байт на стороне сервера умножается на миллионы запросов страницы. А вы размер файлов, наоборот, увеличили. Это, извиняюсь за выражение, пессимизация.
>>> Заменять мнемонические сущности &имя; или на их действительное представление.
По моему в любой адекватной книжке пишется что так делать не надо.
Предлагая писать действительное представление автор обосновывает это экономией нескольких байт (что само по себе смешно), забывая, что например значки < и > явно написанные в коде могут привести к ошибке в браузере. Хотя даже в случае успешной отработки браузера будет потеря производительности, причем достаточно существенная, ведь при рекурсивном разборе кода страницы браузер наткнется на неоднозначность выражения (то ли тег, то ли просто кавычка) и будет искать закрывающую по всему тексту (ну или по куску, зависит от оптимизаций).
По моему в любой адекватной книжке пишется что так делать не надо.
Предлагая писать действительное представление автор обосновывает это экономией нескольких байт (что само по себе смешно), забывая, что например значки < и > явно написанные в коде могут привести к ошибке в браузере. Хотя даже в случае успешной отработки браузера будет потеря производительности, причем достаточно существенная, ведь при рекурсивном разборе кода страницы браузер наткнется на неоднозначность выражения (то ли тег, то ли просто кавычка) и будет искать закрывающую по всему тексту (ну или по куску, зависит от оптимизаций).
Интересные исследования делаете, спасибо :)
Конкретно по этому есть неоднозначность. С одной стороны прооптимизировали, значит хорошо. С другой — это все же не время рендеринга на сервере, как уже говорили. Поэтому «по спичкам» тут не наоптимизируешь, так как будет работать быстрее на каждом отдельном клиенте, но это не просуммируешь. Следовательно очень много работы приходится делать ради того, чтобы одиночный пользователь увидел страницу на 9мс быстрее.
Такая оптимизация отлино подойдет в сложном веб-приложении с богатым клиентским интерфейсом. Там да, и с DOM работа будет скорее всего быстрее идти, сама страница будет быстрее отрисовываться и т.д.
Конкретно по этому есть неоднозначность. С одной стороны прооптимизировали, значит хорошо. С другой — это все же не время рендеринга на сервере, как уже говорили. Поэтому «по спичкам» тут не наоптимизируешь, так как будет работать быстрее на каждом отдельном клиенте, но это не просуммируешь. Следовательно очень много работы приходится делать ради того, чтобы одиночный пользователь увидел страницу на 9мс быстрее.
Такая оптимизация отлино подойдет в сложном веб-приложении с богатым клиентским интерфейсом. Там да, и с DOM работа будет скорее всего быстрее идти, сама страница будет быстрее отрисовываться и т.д.
Как-то сам комментарий отправился.
Хотел ещё сказать, что сам саму разметку предпочитаю делать в XHTML, вот только часто те, кто наполняют сайт, все портачат :)
Хотел ещё сказать, что сам саму разметку предпочитаю делать в XHTML, вот только часто те, кто наполняют сайт, все портачат :)
да, идея подхвачена абсолютно верно. Просто одних теоретических статей с непонятными графиками, мне кажется, не всегда достаточно. Желательно, еще живых примеров подвалить, чтобы народ задумался :)
Такое ощущение что вы не на яндекс заходите, а играете в стрелялки. С таким стремлением вы скоро чайник или кружку разгонять будете :)
`
Польза от увеличения скорости загрузки конечно важна, но не в данном случае.
`
Польза от увеличения скорости загрузки конечно важна, но не в данном случае.
НЛО прилетело и опубликовало эту надпись здесь
для всех, поддерживающих xhtml браузеров (всё есть в заголовках реквеста, если что), страница должна отдаваться с миме-типом application/xml+xhtml — тогда будет использован специальный «строгий» парсер, который не будет «пытаться исправлять ошибки верстальщика». xhtml может отдаваться как text/html только в целях совместимости с неподдерживаемым его клиентом.
у меня в опере быстрее всего загружается первая версия
Странно, у меня в ФФ2 так же — первая. (каждую ссылку открывал по 5 раз)
Разработчики Firefox предпочитают аббревиатуру Fx, а не FF. (Первоисточник: www.mozilla.com/en-US/firefox/releases/1.5.0.7.html)
странно, у меня время в ff в 2 раза меньше
> это все копейки для обычных пользователей
> (на ±50мс — кого это волнует?). Однако,
> если речь идет про «экономию на спичках»,
> когда нам важен каждый запрос к серверу
> и каждая миллисекунда, то тут уже стоит задуматься
Хм… Красивое заблуждение. Все ведь понимают, что рендеринг происходить на стороне клиента? Клиент, как известно, перегрузки не заметит и 50мс тормоза — тоже. Сервер тоже ничего не запметит, потому что скорость рендеринга страницы браузерами никак не влияет на скорость взаимодействия браузеров с серверами, то есть ни одна миллисикунда не будет выиграна. Зато увеличение общего веса страницы на один кб приведет к 114гб лишнего траффика в день (по некоторым данным (http://stat.yandex.ru/), на главную Яндекса приходится в среднем 120 394 270 хитов в сутки). И вот эти самые 114гб повлияют на скорость работы сервера, причем повлияют отрицательно.
Нужно оговорится — это будет очень слабое влияние, тем более что практически все мыслимые клиенты поддерживают gzip, но тем не менее — влияние отрицательное.
Рассуждая с точи зрения оптимизации, правильнее разгружать бэкенд за счет фронтэнда, а не наоборот.
> (на ±50мс — кого это волнует?). Однако,
> если речь идет про «экономию на спичках»,
> когда нам важен каждый запрос к серверу
> и каждая миллисекунда, то тут уже стоит задуматься
Хм… Красивое заблуждение. Все ведь понимают, что рендеринг происходить на стороне клиента? Клиент, как известно, перегрузки не заметит и 50мс тормоза — тоже. Сервер тоже ничего не запметит, потому что скорость рендеринга страницы браузерами никак не влияет на скорость взаимодействия браузеров с серверами, то есть ни одна миллисикунда не будет выиграна. Зато увеличение общего веса страницы на один кб приведет к 114гб лишнего траффика в день (по некоторым данным (http://stat.yandex.ru/), на главную Яндекса приходится в среднем 120 394 270 хитов в сутки). И вот эти самые 114гб повлияют на скорость работы сервера, причем повлияют отрицательно.
Нужно оговорится — это будет очень слабое влияние, тем более что практически все мыслимые клиенты поддерживают gzip, но тем не менее — влияние отрицательное.
Рассуждая с точи зрения оптимизации, правильнее разгружать бэкенд за счет фронтэнда, а не наоборот.
Проверял IE8. Любопытное наблюдение, первый заход 390мс. Но! При повторном заходе на страницу рендерится за 50-70мс…
Так же странно ведет себя F5 первый запуск опять сбрасывает до 330-390мс, последующие до 120-140мс.
Скорее всего IE8 как-то иначе подходит к загрузке ресурсов и тест не показывает правильной картины.
Так же странно ведет себя F5 первый запуск опять сбрасывает до 330-390мс, последующие до 120-140мс.
Скорее всего IE8 как-то иначе подходит к загрузке ресурсов и тест не показывает правильной картины.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разогнать главную Яндекса? Реально!