Comments 33
на самом деле мы стоим на пороге чего-того нового.
у всех уже мозг разрывается от идей и количества реализующихся проектов.
все прокачались на столько что кажется у каждого в голове есть хорошие мысли.
это как на рынке, когда он стогнирует все начинают капашиться и в итоге побеждают те, что сделали ставку на улучшение качества поставляемых услуг/продуктов на рынок.
у всех уже мозг разрывается от идей и количества реализующихся проектов.
все прокачались на столько что кажется у каждого в голове есть хорошие мысли.
это как на рынке, когда он стогнирует все начинают капашиться и в итоге побеждают те, что сделали ставку на улучшение качества поставляемых услуг/продуктов на рынок.
Круто, даже нет слов!
Спасибо за проделанную работу!
Спасибо за проделанную работу!
Относительно javascript, миллионы пользователей одной популярной социальной сети невозможность даже зарегистрироваться без javascript не остановила.
Тоже пользуюсь YSlow. Достигал максимума в 86 на небольшом проекте.
Кстати эта страничка — F(59)
Кстати эта страничка — F(59)
без CDN там трудно подняться выше 80 с небольшим: (
кроме того, разного рода счётчики (не говоря уж о рекламе) тоже портят жизнь
на нашем крупном проекте — местами до 83
кроме того, разного рода счётчики (не говоря уж о рекламе) тоже портят жизнь
на нашем крупном проекте — местами до 83
covex.in.nnov.ru/ — с включенным сжатием, одним баннером, одним счётчиком и другими настройками кэширования для генерации thrumbnails (аватарки и пр.) — один раз показал A(93). Правда для этого надо CDN настроить (сейчас там многое отключено — чтобы легче было дозрабатывать=)
Эта оценка — скорее ориентир. Она показывает что можно исправить. А действительно ли нужно это исправлять — это решать разработчику.
Эта оценка — скорее ориентир. Она показывает что можно исправить. А действительно ли нужно это исправлять — это решать разработчику.
а можно попросить перенести в блог «Клиентская оптимизация»? Я бы заодно и на webo.in переопубликовал :)
да, по поводу HolyWar «один JS файл <-> много JS файлов» — есть компромисс. Если у нас есть 1 главный (jQuery, например) и несколько зависимых, то можно из главного динамически подгружать зависимые через getScript (подзаточив, чтобы кеширование нормально осуществлял).
Либо, если все более-менее независимое, можно до 4 потоков по комбинированному window.onload грузить (тут главное, чтобы они были независимые, ибо у некоторых браузеров проблемы с последовательностью их выполнения после параллельной загрузки).
Либо, если все более-менее независимое, можно до 4 потоков по комбинированному window.onload грузить (тут главное, чтобы они были независимые, ибо у некоторых браузеров проблемы с последовательностью их выполнения после параллельной загрузки).
Ну если исходить из того, что «чем меньше запросов к серверу, тем лучше» — то никакого компромиса быть не должно (хотя, это наверное и есть холивар =))
У меня после загрузки HTML есть только список компонент (фактически — список требуемых JS файлов). Часто оказывается, что очень много + иногда один компонент использует функциональность другого. Тут требуется последовательная загрузка =(
Например, на странице «Запись блога целиком» есть дерево коментариев с кнопками «ответить», «удалить»; есть форма ответа на комментарий (много кнопок типа «выделить жирным» + сама форма + валидатор формы). На такой странице требуется загрузить 3 объединённых файла JS (с учётом органичений на 255 символов). Тут сложно грузить компоненты по одному =)
У меня после загрузки HTML есть только список компонент (фактически — список требуемых JS файлов). Часто оказывается, что очень много + иногда один компонент использует функциональность другого. Тут требуется последовательная загрузка =(
Например, на странице «Запись блога целиком» есть дерево коментариев с кнопками «ответить», «удалить»; есть форма ответа на комментарий (много кнопок типа «выделить жирным» + сама форма + валидатор формы). На такой странице требуется загрузить 3 объединённых файла JS (с учётом органичений на 255 символов). Тут сложно грузить компоненты по одному =)
Если Вы внимательно ознакомитесь с технологией window.onload, то поймете, что никакого противоречия нет: все внешние файлы, обеспечивающие дополнительную функциональность, грузятся после основного содержания страницы.
Загрузку множества файлов я привел только как вариант. В YUI есть замечательная функция по подгрузке зависимостей. Только сама YUI при этом весит — дай боже. Т.е. можно реализовать и цепочную загрузку вместо параллельной — было бы желание :)
Загрузку множества файлов я привел только как вариант. В YUI есть замечательная функция по подгрузке зависимостей. Только сама YUI при этом весит — дай боже. Т.е. можно реализовать и цепочную загрузку вместо параллельной — было бы желание :)
> после основного содержания страницы
ну мы так и делаем (если Вы имеете ввиду вот это 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) — и скорости их загрузки по одному и все сразу очень отличаются (я специально проверял).
Тут скорее вопрос в реализации: у кого-то компоненты, работающие друг с другом (или как-то объединённые по смыслу) в принципе могут находится в одном файле. У нас же — один компонент — это один файл.
UFO just landed and posted this here
где стоит сервер, влияет только на время ответа/время загрузки. Время ответа у пользователей может сильно разнится, очень сильно. Для его проверки существует пара специальных сервисов, «простукивающих» сервер с десятков точек по всему миру.
Для времени загрузки все намного проще — у нас есть канал, который пропускает данные с определенной скоростью. Если мы будем ориентироваться на модельную ситуацию, а не на текущий трафик в интернете, то все будет предельно просто.
Для времени загрузки все намного проще — у нас есть канал, который пропускает данные с определенной скоростью. Если мы будем ориентироваться на модельную ситуацию, а не на текущий трафик в интернете, то все будет предельно просто.
сервер в москве стоит
отличная подробная и полезная статья, спасибо
За примеры для nginx спасибо. У меня возник вопрос относительно разделения css файлов. У меня есть общий css, где прописаны основные стили, но есть еще несколько css файлов(blue.css, red.css и т.д.), с помощью которых реализуется цветовое отображение страницы, данные файлы содержат буквально пару строк. В зависимости от параметров выбранных при создании страницы подгружается нужный 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 файлы для разных скинов сайта.
Имхо, в клиентской оптимизации важна каждая детать — тут нужно экономить на спичках. И экономить нужно на всём — тогда результат будет оптимальным.
Мой вариант — автоматическая сборка 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 файлы для разных скинов сайта.
По поводу 255 символов- md5 может спасти отца русской демократии, плюс можно посимвольно резать и раскладывать по папочкам.
Меня все-таки смущает парадигма вызова кода, посредством анализа DOM, так как это, во-первых, вызывает лишнее беганье по документу, а, во-вторых, попахивает уличной магией.
У меня для этих целей, есть папочка ui, в которой хранятся прикладные скрипты, которые содержат директивы «import какой-то класс», и вся эта беда собирается в момент компиляции шаблона.
На самом деле, давно планирую сделать, сборку всех скриптов на страницы, и следую твоим заветам, вставлять один вызов в подвал тега «body».
Наверное, сегодня и займусь, спасибо за побуждающую к действиям статью.
Меня все-таки смущает парадигма вызова кода, посредством анализа DOM, так как это, во-первых, вызывает лишнее беганье по документу, а, во-вторых, попахивает уличной магией.
У меня для этих целей, есть папочка ui, в которой хранятся прикладные скрипты, которые содержат директивы «import какой-то класс», и вся эта беда собирается в момент компиляции шаблона.
На самом деле, давно планирую сделать, сборку всех скриптов на страницы, и следую твоим заветам, вставлять один вызов в подвал тега «body».
Наверное, сегодня и займусь, спасибо за побуждающую к действиям статью.
> 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 в этот момент начинает тупить (но это длится меньше секунды =)
да что-то я ступил, по поводу 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/ и пишет в итоговый скрипт.
Я, кстати, тоже думал разбивать файлы по каталогам — чтобы разделителем был не «точка с запятой», как щас, а слэш. Но тогда оказалось, что название нового файла может совпасть с названием уже существующего каталога. И дальше мысль остановилась =)
Пожалуй надо сделать тоже самое — так, наверна, старые файлы будет проще удалять =)
А про import: тут, имхо, самое главное — это чтобы одно и тоже не грузилось. Т.е. чтобы граф зависимостей одного файла от других можно было представить в виде дерева (для любого узела есть только один вход и могут быть много выходов).
Кстати, если делать анализ DOM на сервере, то нельзя будет реализовать подгрузку/создание «активного» HTML-кода на странице (здесь «активный» — это требующий загрузки JS).
Пожалуй надо сделать тоже самое — так, наверна, старые файлы будет проще удалять =)
А про import: тут, имхо, самое главное — это чтобы одно и тоже не грузилось. Т.е. чтобы граф зависимостей одного файла от других можно было представить в виде дерева (для любого узела есть только один вход и могут быть много выходов).
Кстати, если делать анализ DOM на сервере, то нельзя будет реализовать подгрузку/создание «активного» HTML-кода на странице (здесь «активный» — это требующий загрузки JS).
Спасибо, хорошая статья.
Насчет настроек 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 разных доменных зонах? Обычно под картинки выделяют отдельный домен, когда есть несколько серверов. А у вас?
> 1 и 2
Согласен. Спасибо.
> 3. Зачем у вас 3 отдельных домена
Вторая доменная зона — для «безкуковых доменов». Если бы всё находилось на одном домене, то в каждом запросе к картинке посылался бы как минимум кук сессии.
На счёт «обычно» я не согласен. Пусть даже есть несколько серверов — но это не значит, что запросы к картинкам и, собственно, к сайту нужно настраивать в два физических сервера.
У нас обычно один nginx на все запросы — а внутри него настроено на какой сервер должен быть перенаправлен запрос или в какой папке лежат статичные файлы.
Согласен. Спасибо.
> 3. Зачем у вас 3 отдельных домена
Вторая доменная зона — для «безкуковых доменов». Если бы всё находилось на одном домене, то в каждом запросе к картинке посылался бы как минимум кук сессии.
На счёт «обычно» я не согласен. Пусть даже есть несколько серверов — но это не значит, что запросы к картинкам и, собственно, к сайту нужно настраивать в два физических сервера.
У нас обычно один nginx на все запросы — а внутри него настроено на какой сервер должен быть перенаправлен запрос или в какой папке лежат статичные файлы.
>Если бы всё находилось на одном домене, то в каждом запросе к картинке посылался бы как минимум кук сессии.
Ну а так происходит резолв ещё одного домена, тоже не очень.
ОК, а зачем разделять на разные домены картинки и CSS?
З.Ы. Буду благодарен за ап кармы, хочу одну интересную ссылку на тему Jabber-а опубликовать.
Ну а так происходит резолв ещё одного домена, тоже не очень.
ОК, а зачем разделять на разные домены картинки и CSS?
З.Ы. Буду благодарен за ап кармы, хочу одну интересную ссылку на тему Jabber-а опубликовать.
про резолв домена: очень много тонкостей, на самом деле. Т.е. если пользователи заходят постоянно на сайт, резолв закеширован — поэтому отдельный безкуковый домен быстрее.
Если пользователи заходят всего один раз — им вообще все в одном файле выдавать (даже картинки в base64 :)
Если пользователи заходят всего один раз — им вообще все в одном файле выдавать (даже картинки в base64 :)
> а зачем разделять на разные домены картинки и CSS?
В тот момент, когда на нашей странице нужно загружать дополнительные JS и CSS файлы картинки ещё не загружены. И чтобы загрузка JS, CSS и IMG друг друга не блокировала, чтобы загрузка шла параллельно — сделаны разные домены.
В тот момент, когда на нашей странице нужно загружать дополнительные JS и CSS файлы картинки ещё не загружены. И чтобы загрузка JS, CSS и IMG друг друга не блокировала, чтобы загрузка шла параллельно — сделаны разные домены.
P.S. да, у меня сейчас webo.in выдает в YSlow 100 :) — правда, я в CDN webo.in забил. Но гугловый счетчик там есть! Как так сделать — напишу, наверное, в течение недели
Sign up to leave a comment.
Клиентская оптимизация и этапы разработки