Вообще, я говорил и спорил не про сжатие имен css-классов, а про сжатие CSS вообще — что оно необходимо всегда. Однако, данный вариант сжатия поражает кучу геморроя, а профит дает небольшой — в нем я особого смысла не вижу.
А, да в режиме автомата, чтобы не заморачиваться проверкой в скрипте на поддержку клиентом gzip-а, после того как сжали и положили файл, отдайте клиенту несжатый — и все — пусть первый раз будет так.
В следующий раз, когда он обновит страничку, ему придет уже сжатый файл и все будет ок.
По моему очевидное отрицать глупо. Или у Вас аргументы есть? :)
Алгоритм:
Делается директория, в которой лежат сжатые и не сжатые файлы, к сжатым в конце добавлено расширение .gz (ну или любое другое, главное чтобы оно было одинаково и Вы потом указали правильно content-encoding).
Далее с помощью modrewrite и .htaccess определяется лезут ли к файлам, которые могут быть сжаты и есть ли поддержка gzip у клиента.
Если есть — отдаем сжатый файл и выставляем соотвественно content-encoding, если нет — не сжатый.
При первоначальном запуске при попытке отдать сжатый файл проверяем его наличие — если нет — дергаем скрипт (например на php), который сожмет его и добавив определенное расширение (gz) положит рядом с несжатым и отдаст его клиенту — это если автоматом, а если нет, то при выкате на продакшен преджимаем нужные файлы и кладем их рядом с несжатыми, опять добавив то самое расширение.
Это для Apache, если Nginx, то немного по другому.
А ну и самое главное — сжатие и минимизации всего что можно сжать и минимизировать нужна ВСЕМ. Так Вы заботитесь о своих пользователях, давая им максимум удобства и информации в максимально малый промежуток времени.
Часть из этого делается элементарно — та-же стандартная минимизация CSS и JS и их склеивание + GZIP — и делать этот минимум нужно ВСЕГДА.
Быстрый сайт — это сайт, которым приятно пользоваться, это залог того, что клиенты будут Вашими (по статистике, люди уходят с сайта, грузящегося более 3.5-4 секунд — имеется ввиду время от набора адреса и до появления хотя-бы части контента).
Причем сделать это можно практически не напрягаясь и на лету.
Хотя да, если Вам плевать на своих клиентов и на проект и чтобы он «лишь бы был» — то таки да, не заморачивайтесь!
Я ничего не передергивал — посмотрите большинство проектов, что и как грузится — очень много интересного откроете для себя.
Если люди хотят выжать максимум не взирая ни на что, ради забавы или рекордов — быть может.
Если же люди заморачиваются с этим ради продакшена (я хайлоад начал мучать около 4 лет назад — и неплохо о чем народ там думает) — они используют технологии, думая не только о байтах, а комплексно и уж точно не будут променивать 1.5 килобайта ради кучи геморроя — поверьте.
Про виртуальный хостинг Вы сами передергиваете — я сказал, что если Ваш сайт упирается в производительность и Ваш хостинг мешает это как-то улучшить — надо менять хостинг, оставаясь на старом Вы лишаете себя клиентов.
>Подгружать скриптом заранее сжатый zip-ом статический файл я бы точно не стал.
О, а отсюда по-подробней, почему-это? Так делают почти все. Причем у кого-то это динамически жмется (в момент первого обращения — как я Вам и говорил), а у кого-то сборщиками при выкладывании на продашен (тем-же Grunt-ом например).
И реализовать это можно даже если у Вас на виртуалке отключен ZIP.
Ну уж если честно, если на виртуальном хостинге нет GZIP, может подумать о том, чтобы сменить такой хостинг? А то как в анекдоте — у нас есть буквы Ж О П и А, давайте делать из них слово СЧАСТЬЕ!
Окей, даже если не менять, сделать скрипт, который будет на ходу сжимать гзипом и складывать в статику и потом отдавать из нее элементарно на любом языке (некий динамик кэш).
Я уж молчу про то, что обычную статику можно прегзиповать, а если учесть это, у вас остается только html, где экономия очень и очень небольшая получится.
И как написали выше — ога 1.5 кб сэкономили и засобачили изображение или библиотечку метра на 1.5.
При gzip это не даст большого выигрыша вообще, серъезно.
Возможно с БЭМ будет чуть лучше.
зато добавит:
геморра при отладке
гемора при сборке
потенциально трудно отлавливаемые глюки с js
Пример — в своих проектах у нас максимальная длина имен CSS в районе 5-8 символов.
Можно посчитать примерно, что это сократит на 4 символа имя, если принять, что с каждого имени экономим 4 байта и в css оно встречается 2 раза и то, что имя встречается обычно в дом 1 раз, и в среднем 100 классов на странице — это даст 4 * 3 = 1200 байт без учета гзипа, стоит ли оно того?
Спасибо! Действительно не сложно. До этого что читал — там буфер строят какой-то специальный — видимо как раз чтобы не рисовать несколько раз один пиксель. Попробую реализовать.
Немного допиленный (уведомление о количестве подкаченных постов) для CustomButtons jsfiddle.net/353dojrv/ (код там-же приведен).
Для тех у кого расширение CustomButtons уже установлено — просто кликнуть по ссылке.
(скрипт не автоматический — чтобы юзать — находясь на нужной странице /feed/all/ просто нажать эту кнопку — мне, лично, так удобней).
P.S. там вначале идет иконка для уведомлений (32x32) кому не надо — могут выпилить.
Можно пару замечаний?
1) У вас не электровелосипед, а ну не знаю… электромопед, ибо педалей в конечном то образце вроде нет?
2) Я, к сожалению, подзабыл курс металловедения, но вроде как титан хрупкий на излом. Или у Вас сплав какой-то?
3) Какой смысл делать короб для батарей как элемент рамы? Громоздко жутко. Не проще ли было сделать обычную раму а на нее защелкнуть пластиковый кейс? Дешевле, легче, проще гидроизоляция. Можно снять / надеть для заряда (скажем нести домой не весь велик а только кейс с аккумами). И выглядеть будет не как Броненосец Потемкин.
Но это все ИМХО, одно то, что Вы сумели довести это дело до конца (а варка титана это вообще отдельное дело) — это круто!
Успехов Вам и развития!
Ну дак прочтите статью, вроде из нее понятно, какими сущностями оперирует программа и сравните с теми, что применяются при учете в обычных бухгалтерских программах.
Вроде как человек тут не пытается свои теории некому навязывать. Он сделал программу и предлагает ее абсолютно бесплатно. Попробовал — удобно — пользуйся. Нет — ну и нет.
Или Вам очень важно работать в программе, основанной обязательно на проверенных научных разработках, заверенных РАН или кем-то еще?
Ну тогда SAP / 1C да и кучу всего еще Вам в помощь.
Тут же не спутники запускают, а домашнюю бухгалтерию ведут.
А по поводу «семи лет» — то, что для одного человека — ерунда, для другого может быть жизнью. Вам никто ничего не навязывает.
И не забудьте от блога mail.ru отписаться — это будет хороший показатель уровня доверия
P.S. никаких претензий к Вам, Dreadatour, я (да и думаю все остальные) не имеют — Вы свое дело сделали на отлично. Но здесь, в этой статье, за неимением других — Вы представляли компанию, и надо сказать, представляли Вы ее не очень, особенно последним комментарием — лучше уж было молчать. Не удивляйтесь тогда реакции. Без обид.
А можно вопрос, с чего это вдруг TC стал умирающий?
Он цветет и пахнет, и популярность его только увеличивается в связи с последними событиями.
Еще и недавно народ наковырял денег на бесплатную проверку его исходников.
Видимо не поняли друг-друга. Окей, замяли.
По-поводу content-encoding:
Header set Content-Encoding: gzip
В следующий раз, когда он обновит страничку, ему придет уже сжатый файл и все будет ок.
Алгоритм:
Делается директория, в которой лежат сжатые и не сжатые файлы, к сжатым в конце добавлено расширение .gz (ну или любое другое, главное чтобы оно было одинаково и Вы потом указали правильно content-encoding).
Далее с помощью modrewrite и .htaccess определяется лезут ли к файлам, которые могут быть сжаты и есть ли поддержка gzip у клиента.
Если есть — отдаем сжатый файл и выставляем соотвественно content-encoding, если нет — не сжатый.
При первоначальном запуске при попытке отдать сжатый файл проверяем его наличие — если нет — дергаем скрипт (например на php), который сожмет его и добавив определенное расширение (gz) положит рядом с несжатым и отдаст его клиенту — это если автоматом, а если нет, то при выкате на продакшен преджимаем нужные файлы и кладем их рядом с несжатыми, опять добавив то самое расширение.
Это для Apache, если Nginx, то немного по другому.
Часть из этого делается элементарно — та-же стандартная минимизация CSS и JS и их склеивание + GZIP — и делать этот минимум нужно ВСЕГДА.
Быстрый сайт — это сайт, которым приятно пользоваться, это залог того, что клиенты будут Вашими (по статистике, люди уходят с сайта, грузящегося более 3.5-4 секунд — имеется ввиду время от набора адреса и до появления хотя-бы части контента).
Причем сделать это можно практически не напрягаясь и на лету.
Хотя да, если Вам плевать на своих клиентов и на проект и чтобы он «лишь бы был» — то таки да, не заморачивайтесь!
Если люди хотят выжать максимум не взирая ни на что, ради забавы или рекордов — быть может.
Если же люди заморачиваются с этим ради продакшена (я хайлоад начал мучать около 4 лет назад — и неплохо о чем народ там думает) — они используют технологии, думая не только о байтах, а комплексно и уж точно не будут променивать 1.5 килобайта ради кучи геморроя — поверьте.
Про виртуальный хостинг Вы сами передергиваете — я сказал, что если Ваш сайт упирается в производительность и Ваш хостинг мешает это как-то улучшить — надо менять хостинг, оставаясь на старом Вы лишаете себя клиентов.
>Подгружать скриптом заранее сжатый zip-ом статический файл я бы точно не стал.
О, а отсюда по-подробней, почему-это? Так делают почти все. Причем у кого-то это динамически жмется (в момент первого обращения — как я Вам и говорил), а у кого-то сборщиками при выкладывании на продашен (тем-же Grunt-ом например).
И реализовать это можно даже если у Вас на виртуалке отключен ZIP.
Окей, даже если не менять, сделать скрипт, который будет на ходу сжимать гзипом и складывать в статику и потом отдавать из нее элементарно на любом языке (некий динамик кэш).
Я уж молчу про то, что обычную статику можно прегзиповать, а если учесть это, у вас остается только html, где экономия очень и очень небольшая получится.
И как написали выше — ога 1.5 кб сэкономили и засобачили изображение или библиотечку метра на 1.5.
Экономия то на спичках получается.
Возможно с БЭМ будет чуть лучше.
зато добавит:
Пример — в своих проектах у нас максимальная длина имен CSS в районе 5-8 символов.
Можно посчитать примерно, что это сократит на 4 символа имя, если принять, что с каждого имени экономим 4 байта и в css оно встречается 2 раза и то, что имя встречается обычно в дом 1 раз, и в среднем 100 классов на странице — это даст 4 * 3 = 1200 байт без учета гзипа, стоит ли оно того?
А можно попросить еще объяснить алгоритм (ну или хотя-бы ссылки в инете на что посмотреть) для вот такой простой задачки 2D (не 3D):
имеем выпуклый 4-х угольник и квадратную текстуру, надо натянуть текстуру на данный 4-х угольник причем с корректными искажениями:
Для тех у кого расширение CustomButtons уже установлено — просто кликнуть по ссылке.
(скрипт не автоматический — чтобы юзать — находясь на нужной странице /feed/all/ просто нажать эту кнопку — мне, лично, так удобней).
P.S. там вначале идет иконка для уведомлений (32x32) кому не надо — могут выпилить.
1) У вас не электровелосипед, а ну не знаю… электромопед, ибо педалей в конечном то образце вроде нет?
2) Я, к сожалению, подзабыл курс металловедения, но вроде как титан хрупкий на излом. Или у Вас сплав какой-то?
3) Какой смысл делать короб для батарей как элемент рамы? Громоздко жутко. Не проще ли было сделать обычную раму а на нее защелкнуть пластиковый кейс? Дешевле, легче, проще гидроизоляция. Можно снять / надеть для заряда (скажем нести домой не весь велик а только кейс с аккумами). И выглядеть будет не как Броненосец Потемкин.
Но это все ИМХО, одно то, что Вы сумели довести это дело до конца (а варка титана это вообще отдельное дело) — это круто!
Успехов Вам и развития!
Испоганили последнюю нормальную серию буков для технарей… эх…
Или не читатель? :)
Вроде как человек тут не пытается свои теории некому навязывать. Он сделал программу и предлагает ее абсолютно бесплатно. Попробовал — удобно — пользуйся. Нет — ну и нет.
Или Вам очень важно работать в программе, основанной обязательно на проверенных научных разработках, заверенных РАН или кем-то еще?
Ну тогда SAP / 1C да и кучу всего еще Вам в помощь.
Тут же не спутники запускают, а домашнюю бухгалтерию ведут.
А по поводу «семи лет» — то, что для одного человека — ерунда, для другого может быть жизнью. Вам никто ничего не навязывает.
Будьте добрее.
Так, господа, нас опять нае#ли, расходимся :)
И не забудьте от блога mail.ru отписаться — это будет хороший показатель уровня доверия
P.S. никаких претензий к Вам, Dreadatour, я (да и думаю все остальные) не имеют — Вы свое дело сделали на отлично. Но здесь, в этой статье, за неимением других — Вы представляли компанию, и надо сказать, представляли Вы ее не очень, особенно последним комментарием — лучше уж было молчать. Не удивляйтесь тогда реакции. Без обид.
Вы реально никогда про накрутку в интернете не слышали? Это же азы любого онлайн конкурса/голосования.
А так, как всегда — идея отличная, а реализация… Причем тут главное и проверять то толком ничего не надо было — отсеять по двум параметрам всего.
А так, поздравляю, на гиковском конкурсе победили боты :) (за небольшим исключением).
Вобщем, печал…
Он цветет и пахнет, и популярность его только увеличивается в связи с последними событиями.
Еще и недавно народ наковырял денег на бесплатную проверку его исходников.