фишка в том что ваше лого не загрузится пока не загрузятся ваши скрипты если лого прописано как в а скрипты в просто потому что лого попадет в очередь загрузки позже, а загрузка JS блокирует загрузку всех остальных файлов.
поэтому, кстати, если способ клиентской оптимизации, когда все <script src=> переносятся в конец , что позволяет не тормозить очередь загрузки и быстрее прогружать клиентскую часть страницы (картинки, css, etc) а потом только подгружать скрипты.
попробовал им сжать, там как я понял он еще кроме уменьшения размера классическими методами (укорачивание имен переменных и т.д.) еще «обфусцирует» код?
остается открытым вопрос, сколько времени тратит браузер на раскодирование этой обфускации и будет ли там реальн выигрыш во времени — в реалиях совеременных скоростей интернета лишний килобайт может загрузится быстрее чем браузер распарсит этот скрипт.
как известно, классические методы сжатия, которые убирают комментарии, заменяют имена переменных и т.д., кроме скорости загрузки также увлеичивают производительность JS в браузере: за счет убора всего лишнего и уменьшения имен переменных JS-движок быстрее парсит файлы.
в данном случае еще неплохо было бы привести timeline
дело в том, что большинство браузеров, когда грузят JS файлы блокируют загрузку всех остальных файлов (некоторые, правда, грузят JS параллельно с CSS) и если на странице JS файлов много то могут возникнуть проблемы с загрузкой:
Как известно, протокол HTTP 1.1 позволяет создавать браузеру только 2 соединения с 1 доменом в каждый момент времени (правда единственный браузер, который следует стандартам это IE, FF создает по 6 параллельных соединений с доменом).
так что размер скриптов тут не так важен, как их количество — 2 скрипта по 80 кб загрузятся гораздо быстрее чем 16 по 10кб, просто потому что в случае с 16 скриптами будет происходить упирание в пинг + задержка очереди загрузки в браузере. а 1 скрипт в 167кб, подключенный асинхронным способом, вообще не затормозит загрузку страницы в реалиях нынешних скоростей интернета.
Но вообще да, это не тонны графики тормозят загрузку страницы, это если у вас на странице тонна графики необходимо думать об оптимизации JS иначе может возникнуть проблема что куча JS файлов забила всю очередь загрузки (как я уже говорил если началась загрузка JS загрузка картинок блокируется, кроме тех что уже грузятся) и пользователь полминуты пялится на страницу без картинок. а если у картинок еще не заданы размеры (height и width) то пользователь может еще получить в итоге веселую «прыгающую» страницу.
опять же, использование css sprites наше все в случае с тонной графики, 2-3 большие картинки прогрузятся быстрее чем 20-30 маленьких.
к сожалению, даже перед выкладывание на продакшн, не всегда удается протестировать все мелочи, тем более грамматические ошибки в неосновном языке.
бывает такое что сроки поджимают, бывает такое что русский копирайтер ушел в отпуск и дали переводить местоному, которые сколько то знает русский, всякое случается.
Для этого обычно делают формы контакта с техподдержкой — заметил ляп — посмеялся — написал в поодержку — его исправили.
это как бы известный дем, который намекает что говорить
«которые только могут, что ругать чужой труд, а сами приличный топик написать не способны.» несколько глупо.
возможности гимпа, которые были освещены в этой статье, и близко не сопоставимы к тем возможностям, которые предоставляет фотошоп, так что оппонет просто посмеется над таким аргументом, я думаю.
а, извините, я неправильно вас понял :)
я почему-то подумал что вы имеете в виду что кроме красивостей ничего не можете предложить, а вы оказывается наоборот предлагаете мол и фиг с ними красивостями главное показать контент
вы имели в виду верстальщика а не дизайнера, наверное?
В хороших конторах обычно верстает все-таки не дизайнер, это не его работа.
А если верстальщик знает всякие «фишки» и умеет как-то «изловчатся» что не сразу «понятно, как оно работает» то врядли он будет работать в плохой конторе, которая будет его заставлять рисовать дизайн
Северная Корея да, там внутрення сетка в которой сидит большинство.
Южная корея, Китай — многие сидят на IE6
Хотя в китае тоже напряженка с инетом, но тем не менее участвовал я и в разработке проектов которые имели пару страниц на китайском.
А, точно, еще ведь и про ActiveX забыл. Из за него даже знакомые в англии сидят на IE потому что у них внутренняя система документооборота реализована с ActiveX и переделывать особо не хотят да и времени нет.
поэтому, кстати, если способ клиентской оптимизации, когда все <script src=> переносятся в конец , что позволяет не тормозить очередь загрузки и быстрее прогружать клиентскую часть страницы (картинки, css, etc) а потом только подгружать скрипты.
остается открытым вопрос, сколько времени тратит браузер на раскодирование этой обфускации и будет ли там реальн выигрыш во времени — в реалиях совеременных скоростей интернета лишний килобайт может загрузится быстрее чем браузер распарсит этот скрипт.
как известно, классические методы сжатия, которые убирают комментарии, заменяют имена переменных и т.д., кроме скорости загрузки также увлеичивают производительность JS в браузере: за счет убора всего лишнего и уменьшения имен переменных JS-движок быстрее парсит файлы.
дело в том, что большинство браузеров, когда грузят JS файлы блокируют загрузку всех остальных файлов (некоторые, правда, грузят JS параллельно с CSS) и если на странице JS файлов много то могут возникнуть проблемы с загрузкой:
Как известно, протокол HTTP 1.1 позволяет создавать браузеру только 2 соединения с 1 доменом в каждый момент времени (правда единственный браузер, который следует стандартам это IE, FF создает по 6 параллельных соединений с доменом).
так что размер скриптов тут не так важен, как их количество — 2 скрипта по 80 кб загрузятся гораздо быстрее чем 16 по 10кб, просто потому что в случае с 16 скриптами будет происходить упирание в пинг + задержка очереди загрузки в браузере. а 1 скрипт в 167кб, подключенный асинхронным способом, вообще не затормозит загрузку страницы в реалиях нынешних скоростей интернета.
Но вообще да, это не тонны графики тормозят загрузку страницы, это если у вас на странице тонна графики необходимо думать об оптимизации JS иначе может возникнуть проблема что куча JS файлов забила всю очередь загрузки (как я уже говорил если началась загрузка JS загрузка картинок блокируется, кроме тех что уже грузятся) и пользователь полминуты пялится на страницу без картинок. а если у картинок еще не заданы размеры (height и width) то пользователь может еще получить в итоге веселую «прыгающую» страницу.
опять же, использование css sprites наше все в случае с тонной графики, 2-3 большие картинки прогрузятся быстрее чем 20-30 маленьких.
бывает такое что сроки поджимают, бывает такое что русский копирайтер ушел в отпуск и дали переводить местоному, которые сколько то знает русский, всякое случается.
Для этого обычно делают формы контакта с техподдержкой — заметил ляп — посмеялся — написал в поодержку — его исправили.
«которые только могут, что ругать чужой труд, а сами приличный топик написать не способны.» несколько глупо.
:)
я почему-то подумал что вы имеете в виду что кроме красивостей ничего не можете предложить, а вы оказывается наоборот предлагаете мол и фиг с ними красивостями главное показать контент
В хороших конторах обычно верстает все-таки не дизайнер, это не его работа.
А если верстальщик знает всякие «фишки» и умеет как-то «изловчатся» что не сразу «понятно, как оно работает» то врядли он будет работать в плохой конторе, которая будет его заставлять рисовать дизайн
Южная корея, Китай — многие сидят на IE6
Хотя в китае тоже напряженка с инетом, но тем не менее участвовал я и в разработке проектов которые имели пару страниц на китайском.
А, точно, еще ведь и про ActiveX забыл. Из за него даже знакомые в англии сидят на IE потому что у них внутренняя система документооборота реализована с ActiveX и переделывать особо не хотят да и времени нет.
расширения:
FireBug
Live Http Headers
ABP
FireShot
Тулбар вконтакте
Download helper
TabMixPlus
тема chromifox
все дополнения последней доступной версии