Pull to refresh

Comments 85

я всегда считал, что «чтобы все было шоколадно» всё должно быть в UTF-8
Не всегда мы диктуем обстоятельства :)
UFO just landed and posted this here
Вот такой метод мне как раз не нравится… хотя бы тем, что в описанном здесь случае чтобы сделать из ветки дев ветку продакшен достаточно просто поменять одну константу :)
У меня так-же, имеется свой похожий велосипед. Но ничего менять не приходиться. :)

Просто пишу нормальный читабельный CSS код. Скрипт обрабатывает и выдает юзеру «сжатый» и нечитабельный код в одно строку.
Зря, я не увидел в вашем методе удаления из javascript и css комментариев, прочих символов типа перевода строки и пробелов, замены имен переменных и функций в javascript на более короткие и т.д, а ведь они тоже дают солидную экономию в весе. А еще у вас используется нерациональная степень сжатия в gzip — 9, а ведь широко известно, что больше 5 ставить нет смысла. Можете посмотреть в комментариях к функциям: gzencode, gzcompress (тут кроме степени сжатия еще и время).

Я подключаю к файлу index.html один файл frontend.js и один style.css, внутри эти файлы, в зависимости от типа сборки, содержат или подключение остальных файлов или полностью сжатый с помощью google closure compiler и yui compressor код. А уже сервер занимается сжатием в gzip. Сжатие — это единственное, что стоит производить на уровне php, если нет доступа к сжатию с помощью самого сервера.

По поводу изменения версии с dev на product — с помощью билд-скрипта это делается намного удобнее, особенно если назначить целям для сборки каждой версии горячие клавиши.
Ро роводу GZIP не знал — прочел в мане что максимум 9 ) Спасибо за поправку.

А по поводу подключения к index.html — окей, а к другим страницам сайта? Или у Вас все скрипты всегда подключаются ко всем страницам?
Сейчас у меня в приложениях в принципе всего одна точка входа, index.html, ибо занимаюсь в основном RIA. Но такой подход актуален и для CMS, в которых используется шаблонизация, подключение скриптов выносится в шаблон header, и не меняется для всех страниц. Конечно, рецепт не универсальный, но с точки зрения производительности проще собрать все скрипты и css в два файла, не резделяя их на группы для разных страниц, так будет меньше запросов к серверу и у пользователя в кэше сразу будет весь необходимый код. Разделять скрипты на группы я бы стал после разницы в объеме между группами в 100 Кб, например. Отдельный случай — админка CMS, ее нужно рассматривать как вторую точку входа с аналогичным подходом.
ага, понял. Спасибо за подробности. Еще +1 вариант работы со статикой.
Я пришел примерно к такому же подходу.
Полностью поддерживаю. От себя бы добавил насчет скрипта билда. Если используется nginx, то для статики можно и нужно использовать gzip_static модуль. Если в директории ищется style.css файл и при этом есть style.css.gz, то отдан будет последний как сжатый контент, но реально сжатия происходить не будет, nginx его отдаст как есть. Соответственно в dev окружении билд скрипт подобные файлы не генерирует, поэтому проблем с кэшированием контента не имеем.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Очень понравилось параллелить загрузку js через headjs.com. Ощутимо ускоряет загрузку, если много скриптов, как это бывает при использовании плагинов jQuery
Достаточно у себя же (в основном домене) сделать домен третьего уровня и оттуда грузить статику.
У подавляющего большинства этот домен уже есть — «www», т.е. с habrahabr.ru отдавать сайт, с «www.habrahabr.ru» — статику.
С одной стороны — да, с другой 'www' часто делают не отдельным вирт.хостом, а через ServerAlias. То есть фактически этот тот же хост получается.
Может быть браузеру это все равно, могу ошибаться.

Не понял за что минусуют ваш комментарий, он же по делу…
Браузеру всё равно как прописан хост.

Комментарий минусуют чайники.
Ок.

Откуда у чайников карма и почему они такие злые?! (вопрос риторический)
спасибо за картинку, поставил на телефон ^___^
В Django-проектах пользуюсь django-compressor который в нужном порядке склеит и пережмет скрипты и стили с помощью yui, closure, jsmin или что-то еще.Так-же умеет работать с less. Еще он умеет потом сразу gzip'ом все это сжимать. Причем захватывает не только линкованные скрипты и стили но и те стили и скрипты которые расположены на странице.
В других проектах склеиваю nginx-concat модулем.
В некоторых проектах с невысокой нагрузкой раздаю статику напрямую с github репозитория к которому прикреплен домен.
Возможно кому-то мои методы окажутся полезными.
забыл еще упомянуть про рамдиск который почти везде применяется.
Кстати насчет Github Pages, там сервера nginx, статика при публикации сжимается gzip'ом можно использовать как полноценную CDN(ведь раздается все по сути с rackspace). такие проекты как cachedcommons.org/ используют Github Pages для раздачи =)
ob_gzhandler к сожелению ориентируется только на основании заголовка Accept-Encoding, об этом тоже в хелпе есть. Увы и ах — этого не всегда достаточно, например для конкуер (а также IE5/IE6).
UFO just landed and posted this here
акутально или неактуально — решать владельцу сайта, наша задча — реализовать все как можно более коррктней, чтобы собрать как можно большую аудиторию
— Apache? Нет, давно уже не слышал…
Аналогично.
Скриптами склеил js/css и минимизировал через yuicompressor, загрузил на продакшен, а там «gzip on» в конфиге.
Что посоветуете кроме php-fpm?
А зачем вам что-то, кроме php-fpm?
Не, ну прикольно, конечно. Но всё таки я рад, что пишу на рельсах, что у меня есть Asset Pipeline, и что ничего этого мне делать не надо. :-)
Статику всё же лучше отдавать nginx•ом, а не апачем. Я за склейку и сжатие, включая yuicompressor, перед выкладываем проекта.
Разве yuicompressor еще актуален после появления closure compiler и uglifyjs?
yuicompressor ведь ещё и CSS умеет сжимать, кроме js?
Отвечу одним БОООЛЬШИМ комментом ;)

Про nginx — господа, если на фронтэнде у Вас торчит nginx — это круто, действительно круто, но во-первых вся эта методика подходит и для него, во вторых обычно бэкэнд у него — Апач.
По этому не очень уместно спорить здесь в ключе «Камаз конечно хорошо, но вот бэха! Бэха гораааздо круче» :)
Обычно nginx есть у VDS а не у простых хостингов, а VDS — совсем другая песня — я про это упоминалу уже )

Про YUI & Google Closure — естественно JS как и CSS надо оптимизировать через них (я например использую YUI)
Но здесь я рассказывал немного не об этом, не так ли? Можно было конечно и упомянуть минимизацию, но я считаю чтобы не было сумятицы — котлеты отдельно, мухи отельно.
Минимайзеры — это вообще тема для отедльной статьи.

Так, и вот самое интересное — для меня очень интересное, как господа у которых сборка проекта осуществляется через запуск спец скриптов (например через шелл).
Как применить тотже YUI или другие утилиты — это вполне понятно, непонятно одно — как Вы определяете КАКИЕ файлы для КАКОЙ странички склеивать?
Т.е. во-первых как у Вас подключаются склеиваемые скрипты на страничках, во вторых, как вы узнаете для каокй страницы какие скрипты склеивать?
У меня сделать это както хорошо, чтобы не мозолило глаза — увы — не получилось. Поделитесь опытом? Буду очень признателен.
Если для каждой страницы делать свою склейку, то весь бонус от склейки может сойти на нет. Браузер же кеширует статику. А если она будет меняться от страницы к странице, то при переходах всегда заново грузиться будет. Поэтому надо склеивать по частоте встречаемости. То есть, пусть немного лишнее включается, но зато одно и то же на разных страницах. Чтобы браузер в кеш клал
он в любом случае скэширует — с моей точки зрения не гоже таскать кучу ненужных библиотек если они не используются на странице. Ну ИМХО конечно.
UFO just landed and posted this here
В теории да, на практике нет. Если css файл загрузился при заходе на главную (на самом деле на любую) и содержит все правила необходимы для всего сайта, то при переходе на любую внутреннюю страницу он тут же подхватывается из кэша. Т.е. при таком подходе css гарантированно грузится один раз при первом входе на любую из страниц. А при своем css для каждой страницы все тут же ухудшается, ведь зачастую пользователь идет по дереву сайта и может на пройденные страницы и не вернуться.
Ну так nginx статику отдает сам, а к апачу переадресует запросы только на динамику — вроде такая сейчас распространенная практика. Так что думаю все же для VDS, где есть возможность его поставить, сжатие статики лучше настроить на nginx, иначе эффекта не будет никакого, это надо учитывать.
Согласен. Там действительно проще это сделать.
Однако насчет «не будет эффекта» — не соглашусь — если Апач у Вас ОДИН раз подготовит статику в определнном месте, а потом из этого места ее отдает nginx — ничего в плане быстродействия Вы не потеряете.
А конфиг с таким подходом не усложнится?
Получается апачу надо будет сначала тыкаться туда где лежат зазипованные архивы, затем либо отдавать, если уже оно там есть, либо стучаться к апачу чтобы тот налету заархивировал.

У меня сейчас классически настроено — nginx сам отдает всю статику, которая лежит в определенных папках (js, css, img), для всех других запросов он стучится в апач. Конфиг в таком случае весьма прозрачен — каждый делает своё дело.

Ну как вы поняли, я тоже за подход, когда все при разворачивании на деплой минимизируется и сжимается, а потом берется готовое))

Усложнится совсем на чуть чуть но это даст возможность работаь с сайтом и без nginx — более высока я переносимость, хотя если в этом нет необходимости — то и смысла делать нет.
Я полностью согласен с Вашим методом.
Да, для определенных условий ваш подход несомненно лучше в силу большей универсальности.
Перед выводом контента в PHP неплохо бы формировать заголовок Content-Length, что легко сделать с помощью функции ob_get_length().
Есть же minify. Зачем изобретать велосипед?
minify каждый раз отдет статику через себя, т.е. его надо к кэшу пркручивать, но как Вариант — вполне.

Мне не очень понравился потому как у меня в движке еще масса всего делается при формировании кэша статики да и процесс хотелось бы контролировать. Кроме того по поводу минификации YUI или же Closure Compiller жмет гораздо лучше.
Достаточно сделать небольшой обвес вокруг minify, и в итоге организовать запросы напрямую к кэшу minify и контролировать процесс.
Кстати всем настоятельно советую прочесть книгу "Разгони свой сайт — Методы клиентской оптимизации веб-страниц", которую написал Николай Мациевский. Человек реально разбирается в данной тематике, и в книге все советы подкрепляет тестированием.

Например вот графики с замерами эффективности для gzip из его статьи (в книге тоже есть):


Рисунок 1. Издержки на gzip от степени сжатия


Рисунок 2. Эффективность различных степеней gzip-сжатия
Николай не рассматривает отдачу предварительно сжатой статики.
Это справедливо лишь для контента сжимаемого на лету. В случае предварительно сжатого контента (в nginx модуль gzip_static) это уже не актуально.
Если хотите «разгонать сайт» — первым делом откажитесь от Apache :) А уже потом всё остальное.
Нужно просто с умом к его использованию подходить)
Ну что за глупости? Что значит «с умом подходить»? Куда вы с ним собрались подходить? В равных условиях (железо и нагрузка) апач всегда работает медленнее nginx и lighttpd. Это факт, бенчмарков в интернетах пруд пруди, и от этого никуда не деться.
Вообще есть правило хорошее «Ко всему подхродить с умом» :-D
А по поводу lighthttpd & nginx можно ведь почитать ПОЧЕМУ они так быстро работают :)
Я даже отвечу на вопрос — они ЗАТОЧЕНЫ под конкретное действо, а Апач — универсален.

Поэтому пытаться их сравнивать — не совсем корректно а говрить что nginx круче чем Апач тем более.

Самолет круче машины? ;)
Где Вы нашли слово «круче»? Я говорил, что апач работает медленнее, что по-моему вполне себе уместно в топике под названием «Разгони свой сайт».
машина тоже медленее самолета, не находите? :)

я понял что Вы имели ввиду :) Просто не люблю когда рубят с плеча.

И если для проекта можно обойтись lighthttpd & nginx + у вас есть хостинг позвоялющий это — то да — есть на это резон, но вот говорить так агульно «надо отказаться от апач», это, извините, смешно.
что это за хостинг такой, что не позволяет? VPS от восьми евро в месяц. А владельцам шаредов вряд ли что-то надо разгонять.
Т.е. при шаред хостинге эти методы не дадут возпростания скорости загрузки? :-D
Я ниже отписался HnH по этому поводу.
Да, а может ссылку дадите? А то я видел эти VPS. 300 MHz, 64 мб оперативки, (и то не гарантированно) и все настраивать руками. Я держу один проект на шаред хостинге, плачу 3 евро в месяц, и не имею геморроя (этот же хостинг нормально держал наплывы тысяч людей с хабра на личный сайт). Запарили такие диванные специалисты, у которых бюджет на нормальный VPS и люди, но которые считают своим долгом бросаться такими заявлениями и обсирать шаред хостинг.
Диванные в данном случае — по использованию шаред хостинга.
О модели процессора вообще ни слова. Под какой виртуальной машиной крутится — тоже не вижу (ресурсы гарантированы или на бумаге?). Мутновато.
Откуда столько агрессии то? Я рад за вас и ваш хостинг, но тем не менее дешевый европейский впс по ценам российских шаредов существует.

Вы сомневаетесь в хетзнере? Тогда забирайте звание диванного специалиста и продолжайте хоститься на российских шаредах по три евро в месяц.

Даже ели брать хостинг на не самом дешевом linode по 20 баксов (600руб) (4 ядра, 512 оперативы, 20Гб, XEN, все гарантированно) это оказывается выгоднее мастерхоста (200руб за 3 гб места и неизвестно сколько оперативы и ядер)
Извините, но агрессия в данном случае у вас. В России давно уже не хостился, всякими вебманями платить мне неудобно.
Сомневаться я могу в мощности процессора, которая не указана. Я сейчас у небольшого хостера с мощными машинами, и я не уверен что переезд на VPS мне будет выгоден. Супернагрузки на сервер не ожидается, но большое кол-во посещений — вполне, если выгорит.
И я не претендую на звание специалиста, просто не считаю VPS серебряной пулей.
Хостинг «может не позволять» установить nginx в одном единственном случае — когда вы используете виртуальный хостинг. Вы держите highload сайты на виртуальном хостинге? Любые аналогии хромают, но Ваша с самолётом и машиной, как мне кажется, хромает вдвойне: и apache и nginx фриварные софтины, nginx не требует никаких дополнительных вложений в компьютер, который тянет apache, или танцев с бубном вокруг ОС: это чисто вопрос выбора софта. Про разницу в цене и содержании самолёта и машины, я так понимаю, говорить не стоит. И я не рублю с плеча, с чего вы взяли? Оптимизация, подобная той которую Вы описывали в статье, нужна только при довольно высоких нагрузках. Использовать Apache при таких нагрузках — очевидно не самый лучший выбор, это всё что я хотел сказать, и ничего более.
Оптимизация, та, которую я сказал нужна вне зависимости от сервера — ибо она при любом фронтенеде ускоряет загрузку. И вопрос не в сервере, вопрос именно в методах. Тут не причем ни Апач ни лайт.

Или вы считаете что если сайт не хайлоад, то пусть и волочит якорь и оптимизировать его не надо? Однако пользоввателю есть разница — загрузится страница за 3 секунды или за одну, даже если таких пользователей на Вашем сайте всего 50 ;)
тем не менее, апаче согласно minecraft за январь месяц — это 59% всего веба.
Так что, подозреваю не все так просто правда?
Послушайте, Internet Explorer тоже занимает около 50% рынка браузеров, и что это говорит о скорости работы? Как правильно заметил ionicman apache универсален. Его удобно ставить на виртуальные хостинги с небольшой нагрузкой, ему можно скармливать .htaccess, легко подключать разные модули. Поэтому он и заслужил свою популярность. Ещё раз: я не говорю, что он плохой или хороший, я говорю что он работает медленнее, чем его конкуренты. Ситуация когда появляются более-менее высокие нагрузки на сервер и начинаешь задумываться как ускорить загрузку сайта, в т.ч. и склейкой js и css, но при это остаёшься на apache мне кажется нелепой.
То есть вы людей, которые способны настроить апач, приравниваете к людям которые неспособны изменить браузер по умолчанию?

> Ситуация когда появляются более-менее высокие нагрузки на сервер и начинаешь задумываться как ускорить загрузку сайта, в т.ч. и склейкой js и css, но при это остаёшься на apache мне кажется нелепой.

Склейка js css приносит ровно такой же выигрыш в производительности как для Апача на северной стороне так и для нгинкса. Потому что минимизирует издержки клиента, на установку соединения.

А теперь к теме
Тем не менее почему то очень крупные хостинги использую только апач.
Обращаю Ваше внимание что я тоже Вам не говорил что Апач быстрее.

Я пытался обратить Ваше внимание что все НЕ ТАК ПРОСТО в выборе.

И стандартная базовая схема сейчас это апач бэкэндом и нгинкс / лайт фронтэндом.

Я бы также посоветовал разделять js файлы: на файлы в footer и head. Это конечно увеличит запросов, но пользователю визуально будет казаться, что страница отобразилась быстрее, это связано с тем, что то тех пор пока браузер не подтянет все файлы из head, он не отображает страницу.
Зачем добавлять js-файлы в head?
Думаю автор каммента имел ввиду синхронную и асинхронную загрузку js файлов, точнее их комбинацию.
Да именно это я имел ввиду.
Все же думаю, что пользователю приятно видеть процесс загрузки визуально, а не ждать загрузки одного большого файла. Хотя пост очень полезный, спасибо автору!
При описанном методе склейки можно нарваться на грабли вот какого рода:
если в файлах CSS используются относительные пути, например

background: url("../img/loader-mini.gif") no-repeat scroll center center transparent;

то в случае, когда у вас пути реального скрипта отличаются от пути скрипта который отдает «склееный» файл вы получите CSS который ссылается на неверный путь. И граф.файлы не будут найдены и отображены.
Еще для ускорение попробуйте в css-е использовать инлайновые картинки.
url(data:MIME;base64,CONTENT)
Насчет class Glue и иже с ним — Assetic отправляет все такие велосипеды (включая и мой самопальный :)) на свалку истории. Рекомендую.
Imenem и TrueDrago подсказали, что оптимальный уровень для deflate компрессии не 9, а 6
Смотрю я график и ясно вижу: разница между 1 и 6 в степени сжатия всего ~4%, а разница в производительность почти в два раза. Оптимальный с точки зрения чего? Трафик экономить? Значение по-умолчанию для этой директивы 1 выбрано не случайно.
Sign up to leave a comment.

Articles