Комментарии 33
на самом деле мы стоим на пороге чего-того нового.
у всех уже мозг разрывается от идей и количества реализующихся проектов.
все прокачались на столько что кажется у каждого в голове есть хорошие мысли.
это как на рынке, когда он стогнирует все начинают капашиться и в итоге побеждают те, что сделали ставку на улучшение качества поставляемых услуг/продуктов на рынок.
у всех уже мозг разрывается от идей и количества реализующихся проектов.
все прокачались на столько что кажется у каждого в голове есть хорошие мысли.
это как на рынке, когда он стогнирует все начинают капашиться и в итоге побеждают те, что сделали ставку на улучшение качества поставляемых услуг/продуктов на рынок.
+4
Круто, даже нет слов!
Спасибо за проделанную работу!
Спасибо за проделанную работу!
0
Относительно javascript, миллионы пользователей одной популярной социальной сети невозможность даже зарегистрироваться без javascript не остановила.
+4
Тоже пользуюсь YSlow. Достигал максимума в 86 на небольшом проекте.
Кстати эта страничка — F(59)
Кстати эта страничка — F(59)
+1
без CDN там трудно подняться выше 80 с небольшим: (
кроме того, разного рода счётчики (не говоря уж о рекламе) тоже портят жизнь
на нашем крупном проекте — местами до 83
кроме того, разного рода счётчики (не говоря уж о рекламе) тоже портят жизнь
на нашем крупном проекте — местами до 83
+1
covex.in.nnov.ru/ — с включенным сжатием, одним баннером, одним счётчиком и другими настройками кэширования для генерации thrumbnails (аватарки и пр.) — один раз показал A(93). Правда для этого надо CDN настроить (сейчас там многое отключено — чтобы легче было дозрабатывать=)
Эта оценка — скорее ориентир. Она показывает что можно исправить. А действительно ли нужно это исправлять — это решать разработчику.
Эта оценка — скорее ориентир. Она показывает что можно исправить. А действительно ли нужно это исправлять — это решать разработчику.
+1
а можно попросить перенести в блог «Клиентская оптимизация»? Я бы заодно и на webo.in переопубликовал :)
+1
да, по поводу HolyWar «один JS файл <-> много JS файлов» — есть компромисс. Если у нас есть 1 главный (jQuery, например) и несколько зависимых, то можно из главного динамически подгружать зависимые через getScript (подзаточив, чтобы кеширование нормально осуществлял).
Либо, если все более-менее независимое, можно до 4 потоков по комбинированному window.onload грузить (тут главное, чтобы они были независимые, ибо у некоторых браузеров проблемы с последовательностью их выполнения после параллельной загрузки).
Либо, если все более-менее независимое, можно до 4 потоков по комбинированному window.onload грузить (тут главное, чтобы они были независимые, ибо у некоторых браузеров проблемы с последовательностью их выполнения после параллельной загрузки).
0
Ну если исходить из того, что «чем меньше запросов к серверу, тем лучше» — то никакого компромиса быть не должно (хотя, это наверное и есть холивар =))
У меня после загрузки HTML есть только список компонент (фактически — список требуемых JS файлов). Часто оказывается, что очень много + иногда один компонент использует функциональность другого. Тут требуется последовательная загрузка =(
Например, на странице «Запись блога целиком» есть дерево коментариев с кнопками «ответить», «удалить»; есть форма ответа на комментарий (много кнопок типа «выделить жирным» + сама форма + валидатор формы). На такой странице требуется загрузить 3 объединённых файла JS (с учётом органичений на 255 символов). Тут сложно грузить компоненты по одному =)
У меня после загрузки HTML есть только список компонент (фактически — список требуемых JS файлов). Часто оказывается, что очень много + иногда один компонент использует функциональность другого. Тут требуется последовательная загрузка =(
Например, на странице «Запись блога целиком» есть дерево коментариев с кнопками «ответить», «удалить»; есть форма ответа на комментарий (много кнопок типа «выделить жирным» + сама форма + валидатор формы). На такой странице требуется загрузить 3 объединённых файла JS (с учётом органичений на 255 символов). Тут сложно грузить компоненты по одному =)
0
Если Вы внимательно ознакомитесь с технологией window.onload, то поймете, что никакого противоречия нет: все внешние файлы, обеспечивающие дополнительную функциональность, грузятся после основного содержания страницы.
Загрузку множества файлов я привел только как вариант. В YUI есть замечательная функция по подгрузке зависимостей. Только сама YUI при этом весит — дай боже. Т.е. можно реализовать и цепочную загрузку вместо параллельной — было бы желание :)
Загрузку множества файлов я привел только как вариант. В YUI есть замечательная функция по подгрузке зависимостей. Только сама YUI при этом весит — дай боже. Т.е. можно реализовать и цепочную загрузку вместо параллельной — было бы желание :)
0
> после основного содержания страницы
ну мы так и делаем (если Вы имеете ввиду вот это dean.edwards.name/weblog/2006/06/again/), а перед запуском я специально посмотрел в YUI — чтобы сделать загрузку JS (иначе были косяки с последовательной загрузкой в IE и Opera =)
Просто дополнительных JS и CSS файлов бывает ну очень уж много (у нас в основном они небольшие — 1-2Kb) — и скорости их загрузки по одному и все сразу очень отличаются (я специально проверял).
Тут скорее вопрос в реализации: у кого-то компоненты, работающие друг с другом (или как-то объединённые по смыслу) в принципе могут находится в одном файле. У нас же — один компонент — это один файл.
ну мы так и делаем (если Вы имеете ввиду вот это dean.edwards.name/weblog/2006/06/again/), а перед запуском я специально посмотрел в YUI — чтобы сделать загрузку JS (иначе были косяки с последовательной загрузкой в IE и Opera =)
Просто дополнительных JS и CSS файлов бывает ну очень уж много (у нас в основном они небольшие — 1-2Kb) — и скорости их загрузки по одному и все сразу очень отличаются (я специально проверял).
Тут скорее вопрос в реализации: у кого-то компоненты, работающие друг с другом (или как-то объединённые по смыслу) в принципе могут находится в одном файле. У нас же — один компонент — это один файл.
0
НЛО прилетело и опубликовало эту надпись здесь
где стоит сервер, влияет только на время ответа/время загрузки. Время ответа у пользователей может сильно разнится, очень сильно. Для его проверки существует пара специальных сервисов, «простукивающих» сервер с десятков точек по всему миру.
Для времени загрузки все намного проще — у нас есть канал, который пропускает данные с определенной скоростью. Если мы будем ориентироваться на модельную ситуацию, а не на текущий трафик в интернете, то все будет предельно просто.
Для времени загрузки все намного проще — у нас есть канал, который пропускает данные с определенной скоростью. Если мы будем ориентироваться на модельную ситуацию, а не на текущий трафик в интернете, то все будет предельно просто.
0
сервер в москве стоит
0
отличная подробная и полезная статья, спасибо
-1
За примеры для nginx спасибо. У меня возник вопрос относительно разделения css файлов. У меня есть общий css, где прописаны основные стили, но есть еще несколько css файлов(blue.css, red.css и т.д.), с помощью которых реализуется цветовое отображение страницы, данные файлы содержат буквально пару строк. В зависимости от параметров выбранных при создании страницы подгружается нужный css. Как такая реализация отразиться на скорости загрузки?
+1
хреново. Лучше все в один файл включить, если там по паре строк
+2
Это всё равно будет медленнее работать. Быть может и не на много, но всё равно медленнее.
Имхо, в клиентской оптимизации важна каждая детать — тут нужно экономить на спичках. И экономить нужно на всём — тогда результат будет оптимальным.
Мой вариант — автоматическая сборка CSS-файлов =)
Приведу пример:
s.img.nnow.ru/jas/ver, debug.css; Firefox3.css; colors, bw.css; JooS.css
s.img.nnow.ru/jas/ver, debug.css; Firefox3.css; colors, default.css; JooS.css
(ссылки без пробелов)
Здесь — colors, bw.css и colors, default.css — это чисто PHP файлы (там нет ни строчки CSS). В них содержатся конструкции вида <? self:: setParam(«colors.bodyFont», «#000000»); ?>
В JooS.css — эти параметры читаются и выводятся в нужном месте конструкцией <? echo self:: getParam(«colors.bodyFont»); ?>
Таким образом у нас скоро получатся разные CSS файлы для разных скинов сайта.
Имхо, в клиентской оптимизации важна каждая детать — тут нужно экономить на спичках. И экономить нужно на всём — тогда результат будет оптимальным.
Мой вариант — автоматическая сборка CSS-файлов =)
Приведу пример:
s.img.nnow.ru/jas/ver, debug.css; Firefox3.css; colors, bw.css; JooS.css
s.img.nnow.ru/jas/ver, debug.css; Firefox3.css; colors, default.css; JooS.css
(ссылки без пробелов)
Здесь — colors, bw.css и colors, default.css — это чисто PHP файлы (там нет ни строчки CSS). В них содержатся конструкции вида <? self:: setParam(«colors.bodyFont», «#000000»); ?>
В JooS.css — эти параметры читаются и выводятся в нужном месте конструкцией <? echo self:: getParam(«colors.bodyFont»); ?>
Таким образом у нас скоро получатся разные CSS файлы для разных скинов сайта.
+2
По поводу 255 символов- md5 может спасти отца русской демократии, плюс можно посимвольно резать и раскладывать по папочкам.
Меня все-таки смущает парадигма вызова кода, посредством анализа DOM, так как это, во-первых, вызывает лишнее беганье по документу, а, во-вторых, попахивает уличной магией.
У меня для этих целей, есть папочка ui, в которой хранятся прикладные скрипты, которые содержат директивы «import какой-то класс», и вся эта беда собирается в момент компиляции шаблона.
На самом деле, давно планирую сделать, сборку всех скриптов на страницы, и следую твоим заветам, вставлять один вызов в подвал тега «body».
Наверное, сегодня и займусь, спасибо за побуждающую к действиям статью.
Меня все-таки смущает парадигма вызова кода, посредством анализа DOM, так как это, во-первых, вызывает лишнее беганье по документу, а, во-вторых, попахивает уличной магией.
У меня для этих целей, есть папочка ui, в которой хранятся прикладные скрипты, которые содержат директивы «import какой-то класс», и вся эта беда собирается в момент компиляции шаблона.
На самом деле, давно планирую сделать, сборку всех скриптов на страницы, и следую твоим заветам, вставлять один вызов в подвал тега «body».
Наверное, сегодня и займусь, спасибо за побуждающую к действиям статью.
0
> md5 может спасти отца русской демократии
Не спасёт — на странице придётся формировать этот md5, а на сервере расшифровывать, а потом выбрать один из подходящих результатов. Получается, что этот вариант хуже, чем определение даты «текущее время+одни сутки» через sleep(86400); echo date(«d.m.Y») =)
> Меня все-таки смущает парадигма вызова кода, посредством анализа DOM
А в это время пользователь изучает уже загруженную страницу. Пока он соображает — пройдёт достаточно времени, чтобы получить результат функции cssQuery(«.js»).
Правда, практика показывает, что IE7 в этот момент начинает тупить (но это длится меньше секунды =)
Не спасёт — на странице придётся формировать этот md5, а на сервере расшифровывать, а потом выбрать один из подходящих результатов. Получается, что этот вариант хуже, чем определение даты «текущее время+одни сутки» через sleep(86400); echo date(«d.m.Y») =)
> Меня все-таки смущает парадигма вызова кода, посредством анализа DOM
А в это время пользователь изучает уже загруженную страницу. Пока он соображает — пройдёт достаточно времени, чтобы получить результат функции cssQuery(«.js»).
Правда, практика показывает, что IE7 в этот момент начинает тупить (но это длится меньше секунды =)
0
да что-то я ступил, по поводу md5.
в итоге тупо нарезал по папкам по n символов: /jui/dict._/searc/h, reg/_.form.js — как-то так (для наглядности n=5), разбивать на разные script src мне не с руки, так как у меня скрипт сборщик обрабатывает внутренние инструкции в javascript файлах.
Т.е. у меня есть папка /j/, в которой лежат базовые классы и ui, в котором лежат прикладные скрипты (в данном случае поиск по словарю и проверка формы регистрации), в ui скриптах есть конструкция import (f.ex. import jsHttpRequest), если сборщик их находит-- читает соотв. класс из /j/ и пишет в итоговый скрипт.
в итоге тупо нарезал по папкам по n символов: /jui/dict._/searc/h, reg/_.form.js — как-то так (для наглядности n=5), разбивать на разные script src мне не с руки, так как у меня скрипт сборщик обрабатывает внутренние инструкции в javascript файлах.
Т.е. у меня есть папка /j/, в которой лежат базовые классы и ui, в котором лежат прикладные скрипты (в данном случае поиск по словарю и проверка формы регистрации), в ui скриптах есть конструкция import (f.ex. import jsHttpRequest), если сборщик их находит-- читает соотв. класс из /j/ и пишет в итоговый скрипт.
0
Я, кстати, тоже думал разбивать файлы по каталогам — чтобы разделителем был не «точка с запятой», как щас, а слэш. Но тогда оказалось, что название нового файла может совпасть с названием уже существующего каталога. И дальше мысль остановилась =)
Пожалуй надо сделать тоже самое — так, наверна, старые файлы будет проще удалять =)
А про import: тут, имхо, самое главное — это чтобы одно и тоже не грузилось. Т.е. чтобы граф зависимостей одного файла от других можно было представить в виде дерева (для любого узела есть только один вход и могут быть много выходов).
Кстати, если делать анализ DOM на сервере, то нельзя будет реализовать подгрузку/создание «активного» HTML-кода на странице (здесь «активный» — это требующий загрузки JS).
Пожалуй надо сделать тоже самое — так, наверна, старые файлы будет проще удалять =)
А про import: тут, имхо, самое главное — это чтобы одно и тоже не грузилось. Т.е. чтобы граф зависимостей одного файла от других можно было представить в виде дерева (для любого узела есть только один вход и могут быть много выходов).
Кстати, если делать анализ DOM на сервере, то нельзя будет реализовать подгрузку/создание «активного» HTML-кода на странице (здесь «активный» — это требующий загрузки JS).
0
Спасибо, хорошая статья.
-1
Насчет настроек nginx:
1. Лучше писать так:
location = /favicon.ico {
2. Для прозрачного gif есть специальный модуль ngx_http_empty_gif_module
3. Зачем у вас 3 отдельных домена, ещё и в 2 разных доменных зонах? Обычно под картинки выделяют отдельный домен, когда есть несколько серверов. А у вас?
1. Лучше писать так:
location = /favicon.ico {
2. Для прозрачного gif есть специальный модуль ngx_http_empty_gif_module
3. Зачем у вас 3 отдельных домена, ещё и в 2 разных доменных зонах? Обычно под картинки выделяют отдельный домен, когда есть несколько серверов. А у вас?
+3
> 1 и 2
Согласен. Спасибо.
> 3. Зачем у вас 3 отдельных домена
Вторая доменная зона — для «безкуковых доменов». Если бы всё находилось на одном домене, то в каждом запросе к картинке посылался бы как минимум кук сессии.
На счёт «обычно» я не согласен. Пусть даже есть несколько серверов — но это не значит, что запросы к картинкам и, собственно, к сайту нужно настраивать в два физических сервера.
У нас обычно один nginx на все запросы — а внутри него настроено на какой сервер должен быть перенаправлен запрос или в какой папке лежат статичные файлы.
Согласен. Спасибо.
> 3. Зачем у вас 3 отдельных домена
Вторая доменная зона — для «безкуковых доменов». Если бы всё находилось на одном домене, то в каждом запросе к картинке посылался бы как минимум кук сессии.
На счёт «обычно» я не согласен. Пусть даже есть несколько серверов — но это не значит, что запросы к картинкам и, собственно, к сайту нужно настраивать в два физических сервера.
У нас обычно один nginx на все запросы — а внутри него настроено на какой сервер должен быть перенаправлен запрос или в какой папке лежат статичные файлы.
+2
>Если бы всё находилось на одном домене, то в каждом запросе к картинке посылался бы как минимум кук сессии.
Ну а так происходит резолв ещё одного домена, тоже не очень.
ОК, а зачем разделять на разные домены картинки и CSS?
З.Ы. Буду благодарен за ап кармы, хочу одну интересную ссылку на тему Jabber-а опубликовать.
Ну а так происходит резолв ещё одного домена, тоже не очень.
ОК, а зачем разделять на разные домены картинки и CSS?
З.Ы. Буду благодарен за ап кармы, хочу одну интересную ссылку на тему Jabber-а опубликовать.
+2
про резолв домена: очень много тонкостей, на самом деле. Т.е. если пользователи заходят постоянно на сайт, резолв закеширован — поэтому отдельный безкуковый домен быстрее.
Если пользователи заходят всего один раз — им вообще все в одном файле выдавать (даже картинки в base64 :)
Если пользователи заходят всего один раз — им вообще все в одном файле выдавать (даже картинки в base64 :)
+1
> а зачем разделять на разные домены картинки и CSS?
В тот момент, когда на нашей странице нужно загружать дополнительные JS и CSS файлы картинки ещё не загружены. И чтобы загрузка JS, CSS и IMG друг друга не блокировала, чтобы загрузка шла параллельно — сделаны разные домены.
В тот момент, когда на нашей странице нужно загружать дополнительные JS и CSS файлы картинки ещё не загружены. И чтобы загрузка JS, CSS и IMG друг друга не блокировала, чтобы загрузка шла параллельно — сделаны разные домены.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Клиентская оптимизация и этапы разработки