Comments 18
За последние девять месяцев объем веб-страницы вырос на 95 килобайт. Это, скорее всего, связано с популярности интернета. На счет Flash — он уступает позиции HTML5.
Не понял, что плохого в редиректах?
Вот у меня RESTful на сайте, я через post-запросы создаю/изменяю ресурсы, и в зависимости от результата делаю редирект.
Вот у меня RESTful на сайте, я через post-запросы создаю/изменяю ресурсы, и в зависимости от результата делаю редирект.
Имеются в виду HTTP, а не .htaccess редиректы. А плохо в них то, что пользователю нужно дать информацию сразу, а не перенаправлять его со страницы на страницу.
Все верно. Вы делаете согласно стандартам для post и put запросов. HTTP Archive врядли выполняет такие запросы. скорее всего имелся ввиду редирект при get запросе к корню сайта.
1. >>Это тоже хорошо для производительности, потому что отдельные файлы с Flash-контентом значительно больше по размеру (в среднем 58 КБ), чем отдельные файлы с любым другим видом контента.
Не понятно про файлы с Flash-контентом. В swf может быть вшито 10 картинок. Вполне логично, что вес 10 картинок больше веса одной картинки. Более того, в нём содержатся скрипты, которые управляют показом. Автор считает, что если вытащить картинки и скрипты из флэша, то суммарный размер будет меньше?
2. >>Кроме того, существует мало способов оптимизировать Flash.
Что значит оптимизировать флэш?
Не понятно про файлы с Flash-контентом. В swf может быть вшито 10 картинок. Вполне логично, что вес 10 картинок больше веса одной картинки. Более того, в нём содержатся скрипты, которые управляют показом. Автор считает, что если вытащить картинки и скрипты из флэша, то суммарный размер будет меньше?
2. >>Кроме того, существует мало способов оптимизировать Flash.
Что значит оптимизировать флэш?
1. Пихать картинки внутрь flash-контейнера — моветон. Пользователь ничего кроме прелоадера не увидит, пока не сольет в один поток все данные. В то же время, если картинки грузятся отдельно можно сразу отобразить интерфейс и грузить картинки в несколько потоков.
А по поводу бОльшего размера — думаю имеется ввиду избыточность самого контейнера .swf. Если мне не изменяет память, самая простая флешка (условно, черный квадрат, который будет при помощи одной строчки AS менять цвет) все равно будет весить не меньше N килобайт, за счет веса самого контейнера. В то же время у js, и css такого балласта нет, а у html близок к нулю (под балластом я подразумеваю doctype и html/head/body)
А по поводу бОльшего размера — думаю имеется ввиду избыточность самого контейнера .swf. Если мне не изменяет память, самая простая флешка (условно, черный квадрат, который будет при помощи одной строчки AS менять цвет) все равно будет весить не меньше N килобайт, за счет веса самого контейнера. В то же время у js, и css такого балласта нет, а у html близок к нулю (под балластом я подразумеваю doctype и html/head/body)
2. С каких это пор лучше грузить картинки в несколько потоков?
Балласт есть у любого формата. У html — внутри html, в заголовках http. У js — в запускающей html-странице. У png, jpg — в заголовках. У swf он тоже есть, но никак не в несколько килобайт(потому что www.simppa.fi/demo/vinyl4k/ — 4052 байта), точнее надо мерить. (Я на днях как раз собираюсь запилить минимальную демку, посмотрим...)
Кроме того, говоря об отображении интерфейса, я думаю, почти весь этот флеш приходится на рекламные баннеры, там интерфейса нет.
Балласт есть у любого формата. У html — внутри html, в заголовках http. У js — в запускающей html-странице. У png, jpg — в заголовках. У swf он тоже есть, но никак не в несколько килобайт(потому что www.simppa.fi/demo/vinyl4k/ — 4052 байта), точнее надо мерить. (Я на днях как раз собираюсь запилить минимальную демку, посмотрим...)
Кроме того, говоря об отображении интерфейса, я думаю, почти весь этот флеш приходится на рекламные баннеры, там интерфейса нет.
По поводу отдельной загрузки картинок — видел, как флеш-шапки в сайтах грузились по минуте из-за встроенных изображений и при этом содержали некоторые элементы навигации. Или являлись простым слайд-шоу из нескольких изображений. В первом случае, при асинхронной загрузке можно было бы быстро дать пользователю перейти куда нужно, а во втором — быстрее отобразить первую картинку, а остальные догружать в фоне.
По поводу балласта у html — три обязательных тега и доктайп, про которые я упомянул. У js балласта нет, поскольку в данном топике рассматривались именно внешние ресурсы, которые тянут за собой страницы. Заголовки у картинок успешно вырезаются оптимизаторами, если гнаться за байтами. А HTTP-заголовки есть у всего, что грузится с сервера, и не особо отличаются для картинки, js-ки и флеша.
По поводу минимального оверхеда swf-контейнера ниже написали, я не прав, сейчас он всего пол-килобайта. Но опять же на высосанном из пальца примере с квадратом — разница в несколько раз.
По поводу природы флешек (баннеры или не баннеры) тут обсуждать нечего — в топике средняя температура по больнице.
По поводу балласта у html — три обязательных тега и доктайп, про которые я упомянул. У js балласта нет, поскольку в данном топике рассматривались именно внешние ресурсы, которые тянут за собой страницы. Заголовки у картинок успешно вырезаются оптимизаторами, если гнаться за байтами. А HTTP-заголовки есть у всего, что грузится с сервера, и не особо отличаются для картинки, js-ки и флеша.
По поводу минимального оверхеда swf-контейнера ниже написали, я не прав, сейчас он всего пол-килобайта. Но опять же на высосанном из пальца примере с квадратом — разница в несколько раз.
По поводу природы флешек (баннеры или не баннеры) тут обсуждать нечего — в топике средняя температура по больнице.
Разве флеш не может подгружать ресурсы асинхронно? Другое дело, что этим никто не заморачивается.
Почему? Делают. И, кстати, при разделении флешки на несколько фреймов первый начинает исполняться как только загрузится (на чём построены все флешовые прелоадеры). Я бы сказал, что флеш при правильном использовании — много более оптимальный способ загрузки/показа картинок — и за счёт того, что не-асинхронную загрузку в нём еще суметь сделать надо, и за счёт векторной природы, которая часто сильно уменьшает размер кода.
1. Ситуации бывают разные, иногда необходимо загрузить сразу всё, а потом уже загружать. Но опрос не в этом. Не понятно, как можно сравнивать flash-контейнер и отдельный файл. Есть flash-игрушка, а есть шапка сайта. Как их можно сравнивать по размеру? Это всё равно, что сравнивать мягкое с теплым и придти к выводу, что сладкое лучше.
2. Скомпилировал пустой swf. Размер 523 байта. Это и есть избыточность контейнера swf. Современные сайты подобной избыточности даже не заметят.
2. Скомпилировал пустой swf. Размер 523 байта. Это и есть избыточность контейнера swf. Современные сайты подобной избыточности даже не заметят.
1. Насколько я понимаю, в данном топике представлена «средняя температура по больнице» в контексте сайтов. Поэтому все флешки так или иначе запрошены из HTML-страничек. В данном случае изначальная цитата ("… потому что отдельные файлы с Flash-контентом значительно больше по размеру (в среднем 58 КБ), чем отдельные файлы с любым другим видом контента...") скорее всего была о том, что некоторый функционал стали реализовывать без флеша в пользу js/css/html, и теперь пользователи будут грузить несколько маленьких файлов (js|css|картинки) вместо одного большого. С одной стороны это хорошо, если вся загрузка предусмотрительно реализована асинхронно (пользователь быстрее получит доступ к интерфейсу), с другой стороны увеличивает нагрузка на сервер и оверхед на коннекты.
2. Согласен. Я уже давно не в теме, и исключительно рад такой информации)
2. Согласен. Я уже давно не в теме, и исключительно рад такой информации)
2. Можно сделать меньше, если не пользоваться говнотулзами от Adobe.
2. Очевидно подразумевается сжатие за счет удаления лишней информации, добавляемой компилятором. Плюс оптимизация скриптов (как google closure compiler для js)
средний размер веб-страниц в интернете увеличился на 15% (на 95 КБ) и теперь составляет 735 КБ.
[...]
Интересно, что при этом средний размер отдельных ресурсов на странице не изменился, то есть графика и скрипты остались в среднем тех же размеров, что и девять месяцев назад. Рост объёма передаваемых данных объясняется увеличением количества самых элементов и увеличением количества HTTP-запросов.
Это потому, что сейчас стало общей практикой подключать библиотеки-монстры ради 1-2 функций. Всякие слайдеры, карусели и т.п.
Sign up to leave a comment.
HTTP Archive: тренды веба за девять месяцев