Comments 28
Похвастаюсь результатом. Ссылку не даю, ибо реклама будет. Будет спрос — может статью напишу, как добиться. Но это не битрикс.
Как этого добиться написано в комментариях к оценке вашего сайта. Получение 100% результатов без манипуляций с CSS невозможно. А самое главное — в этом нет необходимости, результат не оправдывает средства. Более того, яндекс метрика и иные сторонние скрипты сами руководят своим кэшем. Но, конечно, можно страдать и выдавать гениальные идеи:)
UFO just landed and posted this here
Статика, к сожалению, не решает следующие вопросы:
- расстояние между элементами
- последовательность вызова скриптов и стилей
- css в теле документа, отвечающий за верхнюю часть страницы
- минификация/сжатие/объединение статики
- адаптивная вёрстка
- сжатие изображений
- сторонние счётчики, их кэш и работа
Эм…
- первый пункт вообще не понял
- в статике никто, кроме вебмастера, не решает в какой последовательности подключать скрипты и стили
- что этому мешает?
- что мешает статической странице быть адаптивной, использовать оптимизированные изображения и минифицированные скрипты?
Никто не мешает ничего вебмастеру. Просто превратить сайт из «динамичного» в «статичный» баллов гуглу не даст — я об этом. Это не панацея и даже не метод получения этих данных — я об этом.
По поводу первого пункта — одной из метрик гугла является расстояние между элементами в мобильной версии — чтобы пальцем однозначно попадать по ссылкам и не промахиваться. Это тоже приходится учитывать, чтобы получить 100/100, и перевод сайта с динамического на статический не приведёт к тому, что элементы встанут дальше друг от друга. Другими словами, добиться такого результата переводом на статику нельзя (это не необходимое и не достаточное условие).
По поводу первого пункта — одной из метрик гугла является расстояние между элементами в мобильной версии — чтобы пальцем однозначно попадать по ссылкам и не промахиваться. Это тоже приходится учитывать, чтобы получить 100/100, и перевод сайта с динамического на статический не приведёт к тому, что элементы встанут дальше друг от друга. Другими словами, добиться такого результата переводом на статику нельзя (это не необходимое и не достаточное условие).
Думается, DanDare написал о том, что статикой легче манипулировать и подгонять ее под желания гугла, нежели генерируемые цмсками страницы. Опять же, написал, что данное решение подходит не всегда, просто как вариант.
По поводу первого пункта, да, я в курсе, что расстояние между активными (ссылки и тп) элементами влияет на удобство и учитывается в счетчике. К слову, как и размер шрифта. Я просто не понял и до сих пор не понимаю почему же "статика, к сожалению, не решает следующие вопросы". Тут по всем пунктам (кроме счетчиков) вообще без разницы о статике идет речь или нет :)
По поводу первого пункта, да, я в курсе, что расстояние между активными (ссылки и тп) элементами влияет на удобство и учитывается в счетчике. К слову, как и размер шрифта. Я просто не понял и до сих пор не понимаю почему же "статика, к сожалению, не решает следующие вопросы". Тут по всем пунктам (кроме счетчиков) вообще без разницы о статике идет речь или нет :)
UFO just landed and posted this here
Ну, тем не менее, при статике и скорости и баллов добиться легче :) Я, извиняюсь за выражение, докопался из-за
Ведь из чего статику сделаешь/сгенерируешь, тем она и будет. Статика из адаптивной страницы будет адаптивной и т.д. Чего тут статика не решает и причем тут она — не понятно.
Статика, к сожалению, не решает следующие вопросы:
расстояние между элементами
последовательность вызова скриптов и стилей
css в теле документа, отвечающий за верхнюю часть страницы
минификация/сжатие/объединение статики
адаптивная вёрстка
сжатие изображений
Ведь из чего статику сделаешь/сгенерируешь, тем она и будет. Статика из адаптивной страницы будет адаптивной и т.д. Чего тут статика не решает и причем тут она — не понятно.
Класть CSS в тело html-документа — не самая хорошая практика, хоть Гугл и дает за нее недостающие баллы.
Класть CSS в тело документа — за такое гугл даст 94-98 баллов. Чтобы было 100, необходимо, чтобы в теле документа был только css, отвечающий за верхние 700-800 пикселей страницы, а это гораздо меньше полного CSS.
Так а остальную часть css вы куда включили? В head нельзя — снимет баллы, в body нельзя, потому что не положено спецификацией.
загрузка стилей JS-ом. Я ещё дополнительно делаю так: после первой загрузки страницы вешаю куку с номером версии стилей. Затем при последующих загрузках проверяю наличие куки. Если версия стилей не изменилась, включаю их в head. Тут и гугл не заподозрит обмана и реальная скорость загрузки первой и последующих будут оптимальными
Есть интересное решение от Addy Osmani.
github.com/addyosmani/critical
Еще хорош uncss addyosmani.com/blog/removing-unused-css
github.com/addyosmani/critical
Еще хорош uncss addyosmani.com/blog/removing-unused-css
Все должно быть проще:
1. Вынесите стили и скрипты из папки /bitrix;
2. Минифицируйте все у себя, а не средствами битрикса;
3. Для скриптов, которые должны быть в доме страницы можно использовать:
4. Обязательно включите gzip на сервере.
1. Вынесите стили и скрипты из папки /bitrix;
2. Минифицируйте все у себя, а не средствами битрикса;
3. Для скриптов, которые должны быть в доме страницы можно использовать:
inlineScripts.push(function() {
//ваши методы
}
)
4. Обязательно включите gzip на сервере.
Меня раздражает практика совать скрипты вниз (ну разве что за исключением счетчиков и рекламы).
Достаточно сказать им defer.
Достаточно сказать им defer.
Я за долгие годы так и не услышал ответ на один простой вопрос: зачем, если мы используем схему «nginx + apache», нам включать gzip на апаче, да не просто включать, а включать в виде модуля Битрикса (!), если именно nginx будет сжимать контент для юзера. Это как раз «рекомендованные настройки» и виртуальная машина, уж не знаю как сейчас, еще недавно шла именно с ними.
Другими словами, чтобы сделать сайт на битриксе быстрее и меньше нагрузить сервер, надо, против рекомендаций Битрикса, отключить модуль «Компрессия», отключить сжатие на стороне Apache его модулем, и включить сжатие на nginx — на выходе Apache и PHP не будут бессмысленно тратить CPU для того только, чтобы сжатое распаковал, а затем запаковал для отдачи дальше nginx.
Работа механизма минификации css и js тоже иногда удивляет. Также удивляет и привычка Битрикса приписывать версии статики в конец имен файлов — и ведь ее отключить не так чтобы совсем просто!
По-честному, оставьте всем заниматься своими делами. Битрикс уже давно стал продуктом, под который настраивают сервер, так что можно просто задать ТТХ машины, без которых Битрикс откажется работать. Если так, что все функции веб-серверов внезапно окажутся не помехой, а именно помощниками сайта: как пример, тот же gzip_static заметно поможет еще меньше тратить процессор на постоянное сжатие статических, неизменных файлов.
И таки да, есть еще и mod_page_speed от Гугла, который довольно легко и почти «из коробки» помогает малой кровью улучшить загрузку сайта у юзера. Если бы не версии файлов в URL-ах, он прекрасно бы работал на сайтах с Битриксом, а вот с указанными «версиями»…
Другими словами, чтобы сделать сайт на битриксе быстрее и меньше нагрузить сервер, надо, против рекомендаций Битрикса, отключить модуль «Компрессия», отключить сжатие на стороне Apache его модулем, и включить сжатие на nginx — на выходе Apache и PHP не будут бессмысленно тратить CPU для того только, чтобы сжатое распаковал, а затем запаковал для отдачи дальше nginx.
Работа механизма минификации css и js тоже иногда удивляет. Также удивляет и привычка Битрикса приписывать версии статики в конец имен файлов — и ведь ее отключить не так чтобы совсем просто!
По-честному, оставьте всем заниматься своими делами. Битрикс уже давно стал продуктом, под который настраивают сервер, так что можно просто задать ТТХ машины, без которых Битрикс откажется работать. Если так, что все функции веб-серверов внезапно окажутся не помехой, а именно помощниками сайта: как пример, тот же gzip_static заметно поможет еще меньше тратить процессор на постоянное сжатие статических, неизменных файлов.
И таки да, есть еще и mod_page_speed от Гугла, который довольно легко и почти «из коробки» помогает малой кровью улучшить загрузку сайта у юзера. Если бы не версии файлов в URL-ах, он прекрасно бы работал на сайтах с Битриксом, а вот с указанными «версиями»…
Без обид, не работал с битриксом, я вообще не вижу смысла в связке Nginx + Apache. Меня целиком устраивает связка Nginx + FCGI
Какие обиды. До недавнего времени рекомендованная Битрикс-машина шла именно с такой связкой. Естественно, многие сайты переезжают на nginx+..., но я говорю про дефолтные настройки машины, на которую ТП Битрикса ссылалась как на то, что «точно работает» — оно и правда работает, но может работать еще лучше путем очень нехитрых настроек.
Повторюсь, это особенно любопытно на фоне того, что Битрикс не назвать «легкой CMS», и под него сервера настраивают специально, так что написать в ТТХ, что «требуется nginx с включенными и настроенным модулями ngx_http_gzip_module и ngx_http_gzip_static_module» и убрать из поставки Битрикса модуль «Компрессия» было бы только разумно.
Тем более что в Nginx бинарные модули сжатия, уверен, более рассчитаны на нагрузку, чем (вроде бы) никогда не обновляемый модуль «Компрессия», написанный на php.
Повторюсь, это особенно любопытно на фоне того, что Битрикс не назвать «легкой CMS», и под него сервера настраивают специально, так что написать в ТТХ, что «требуется nginx с включенными и настроенным модулями ngx_http_gzip_module и ngx_http_gzip_static_module» и убрать из поставки Битрикса модуль «Компрессия» было бы только разумно.
Тем более что в Nginx бинарные модули сжатия, уверен, более рассчитаны на нагрузку, чем (вроде бы) никогда не обновляемый модуль «Компрессия», написанный на php.
Как браузер посетителя поймёт, что статика изменилась, если убрать версионность? Браузер же не отправляет запросов на проверку изменений, так как включен вечный или долгий кэш.
Вы не поняли. Битрикс «версионность» вводит как httр://domain.com/static/file.ext?ver=123 что никак не нравится ни mpd_page_speed, ни части прокси, ни даже браузерам иным. Версии предполагается в этом варианте указывать в параметре ver, который, по идее, надо еще как-то и вычислять при указании в коде страницы.
В то время как вариант httр://domain.com/static/123/file.ext (видите, куда частичка с номером версии скакнула — «каталогом» перед именем файла?) прекрасно работает, а на стороне сервера обрабатывается реврайтом. Кроме того, такой вариант можно сделать и в виде создания реального каталога, куда положить и простые, и gzip-нутые версии объединенных файлов статики, чтобы gzip_static делал свое дело — при этом обновление такого версионного каталога отлично возлагается на обработчик 404 ошибки, например, что убирает задачу обновления кеша из кода рендера самой страницы (при этом подкаталоги в /static/ можно будет удалять в любой момент, т.к. обработчик 404 всегда их восстановит).
Оно, конечно, не панацея, но как-то поэффективнее, на мой вкус и опыт, чем вариант, так насильственно пропихиваемый Битриксом.
В то время как вариант httр://domain.com/static/123/file.ext (видите, куда частичка с номером версии скакнула — «каталогом» перед именем файла?) прекрасно работает, а на стороне сервера обрабатывается реврайтом. Кроме того, такой вариант можно сделать и в виде создания реального каталога, куда положить и простые, и gzip-нутые версии объединенных файлов статики, чтобы gzip_static делал свое дело — при этом обновление такого версионного каталога отлично возлагается на обработчик 404 ошибки, например, что убирает задачу обновления кеша из кода рендера самой страницы (при этом подкаталоги в /static/ можно будет удалять в любой момент, т.к. обработчик 404 всегда их восстановит).
Оно, конечно, не панацея, но как-то поэффективнее, на мой вкус и опыт, чем вариант, так насильственно пропихиваемый Битриксом.
Да, согласен, у себя тоже делаю через static.123.js, не ожидал такого от Bitrix.
Категорически поддерживаю! В своё время писал об этой проблеме в ТП и получил вполне ожидаемый от Битриксов ответ:
Я передал пожелание в отдел разработки, но шансов что это будет реализовано крайне мало, так как это сломает сущесвующий функционал, в частности работу CDN.Тогда же создал идею, если можете проголосовать — проголосуйте в поддержку.
1. Стандартная виртуальная машина идет с включенным сжатием на стороне nginx. В том числе включен модуль gzip_static, для отдачиуже сжатых копий объединенных файлов (Включается в настройках ядра)
2. Модуль БУС «Компрессия» необходим только в случае использования не оптимального хостинга. Где не доступны другие варианты сжатия контента. В случае нормального хостинга, его необходимо отключать.
3. При установки на виртуальную машину проекта, стандартный установщик отключает модуль компрессия через определение константы.
4. В чем конкретно вы видите преимущество вашего метода установки версионности статических файлов?
2. Модуль БУС «Компрессия» необходим только в случае использования не оптимального хостинга. Где не доступны другие варианты сжатия контента. В случае нормального хостинга, его необходимо отключать.
3. При установки на виртуальную машину проекта, стандартный установщик отключает модуль компрессия через определение константы.
4. В чем конкретно вы видите преимущество вашего метода установки версионности статических файлов?
> 1. Стандартная виртуальная машина идет с включенным сжатием на стороне nginx. В том числе включен модуль gzip_static, для отдачиуже сжатых копий объединенных файлов (Включается в настройках ядра)
Молодцы! На апаче сжатие отключено? (под рукой свежей нет, в старой было включено, что явно избыточно).
> 2. Модуль БУС «Компрессия» необходим только в случае использования не оптимального хостинга. Где не доступны другие варианты сжатия контента. В случае нормального хостинга, его необходимо отключать.
Скажите, а ЗАЧЕМ он вообще идет? Как много хостингов в мире, где крутятся сайты на Битриксе, но где нет сжатия? :) Ну давали бы его скачивать отдельно, но в составе поставки-то?
> 3. При установки на виртуальную машину проекта, стандартный установщик отключает модуль компрессия через определение константы.
Сейчас — наверное. Но в прошлой версии машины, внезапно — ГОДАМИ!!! — этого не было. Сейчас машины под рукой нет, не проверю, увы.
> 4. В чем конкретно вы видите преимущество вашего метода установки версионности статических файлов?
Так написано же выше — есть софт, который крайне любит видеть расширения в конце адреса статического файла. Вы же так много сил прилагаете к совместимости с разнымии-всякими программами, это как раз тот случай.
Еще раз оговорюсь: Битрикс развивается, но иные модули (когда Компрессия переписывалась в последний раз? а джаббер из Корпортала? :) ) как сделаны, так и заброшены. Чем тянуть трупы, куда как было бы разумнее использовать то, что может дать стороннее (но почти везде существующее) ПО — веб-сервер, скажем.
И, знаете, так и хочется говорить — «наконец хоть это сделали». Говорил и писал об этом в вашу ТП уже лет пять :) что давало впечателния калибра болта, забитого на оптимизацию :)
Молодцы! На апаче сжатие отключено? (под рукой свежей нет, в старой было включено, что явно избыточно).
> 2. Модуль БУС «Компрессия» необходим только в случае использования не оптимального хостинга. Где не доступны другие варианты сжатия контента. В случае нормального хостинга, его необходимо отключать.
Скажите, а ЗАЧЕМ он вообще идет? Как много хостингов в мире, где крутятся сайты на Битриксе, но где нет сжатия? :) Ну давали бы его скачивать отдельно, но в составе поставки-то?
> 3. При установки на виртуальную машину проекта, стандартный установщик отключает модуль компрессия через определение константы.
Сейчас — наверное. Но в прошлой версии машины, внезапно — ГОДАМИ!!! — этого не было. Сейчас машины под рукой нет, не проверю, увы.
> 4. В чем конкретно вы видите преимущество вашего метода установки версионности статических файлов?
Так написано же выше — есть софт, который крайне любит видеть расширения в конце адреса статического файла. Вы же так много сил прилагаете к совместимости с разнымии-всякими программами, это как раз тот случай.
Еще раз оговорюсь: Битрикс развивается, но иные модули (когда Компрессия переписывалась в последний раз? а джаббер из Корпортала? :) ) как сделаны, так и заброшены. Чем тянуть трупы, куда как было бы разумнее использовать то, что может дать стороннее (но почти везде существующее) ПО — веб-сервер, скажем.
И, знаете, так и хочется говорить — «наконец хоть это сделали». Говорил и писал об этом в вашу ТП уже лет пять :) что давало впечателния калибра болта, забитого на оптимизацию :)
На данный момент нет информации о каком либо заметном объеме проблем у стороннего ПО с генерируемыми нами ссылками. Если есть другая информация, поделитесь.
Что касается хостинга, использование не оптимального еще не редкость. Возможно в ближайшем будущем, модуль «Компресии» не будет устанавливаться по умолчанию.
Что касается хостинга, использование не оптимального еще не редкость. Возможно в ближайшем будущем, модуль «Компресии» не будет устанавливаться по умолчанию.
А также адаптированная для Google PageSpeed верстка на примере и ее тест на GooglePageSpeed.
Sign up to leave a comment.
Адаптивные сайты, или Как добиться благосклонности Google