Comments 15
Видел как некоторые сайты на лету переживают JPEG в WEBP, при этом отдают его по той же ссылке но с другим контент-тайпом. По размеру получается почти в два раза меньше при одинаковом качестве. Судя по всему работает это только для Chrome, а значит веб-сервер смотрит на user-agent и в зависимости от этого отдает разные файлы. Может есть готовые решения для такого?
Для вордпрес плагины есть).
А вообще хранишь только оригинал, а отдаешь через imageproxy, одним jpg другим webp если для кастома.
docs.imgproxy.net/#/configuration?id=webp-support-detection
А вообще хранишь только оригинал, а отдаешь через imageproxy, одним jpg другим webp если для кастома.
docs.imgproxy.net/#/configuration?id=webp-support-detection
Модуль PageSpeed для Apache/Nginx умеет такое делать на лету.
Есть ещё js либа modernizr, которая при загрузке станицы проверяет браузер и если это хром, просто добавляет к body класс webp, а для других браузеров no-webp. Дальше просто прописать разные css c webp вариантом, который смотрит на webp файл, и с no-webp, который смотрит на jpg/png файл.
Для img есть тег обёртка picture.
А насколько WEBP сжимает фото?
А ещё можно не накручивать на сайт огромное количество скриптов и стилей которые возможно и не нужны.
но на первое место всегда ставят Cloudflare
А разве есть ещё бесплатные cdn кроме него?
А ещё у них же есть бесплатные Service Workers, на которых можно вручную поднять свой CDN с преферансом и куртизанками.
А можно про это поподробнее?
Ничего не было сказано о минификации HTML, JS, CSS и SVG, а это все-таки дополнительная экономия.
Статья для новчика. Новичек с ней заедет в засаду, если попытается применить на практике:
1) Ничего не написано про то, что для работы gzip_static и brotli_static в Nginx вообще-то надо не только включить эти директивы но и еще самостоятельно пережать контент. Директивы всего лишь предписывают серверу использовать заранее сжатый контент, если он есть. А если заранее сжатого контента нет, то директивы сами по себе бесполезны. Так что придется скачать тулзы brotli и zopfli а потом еще написать скрипт, который пройдется по вашему контенту и все посжимает. Если статика время от времени меняется то скрипт надо будет потом прогонять повторно что бы сжатые версии стали бы актуальными. Для этого надо будет либо сделать какой-то автоматический триггер, либо озаботиться организационными мерами.
2) Ничего не написано про промежуточные кэши и про заголовки Accept-encoding в запросе и Vary:accept-encoding в ответе. Без этого появляются неиллюзорные шансы выстрелить в себе в ногу при настройке кэширования. Ну то есть утверждение о том, что Brotli работает только по HTTPS, связано как раз с этми самыми промежуточными кэшами. Про Brotli сказано а про Vary нет.
3) В примере про настройку cache-control в Apache зачем-то написана странная штука:
В скриптах могут быть какие-то свои настройки кэширования. В этом конфиге заголовки, выданные скриптом, будут тупо сброшены и заменены на заголовок Expires из конфига. Если о скриптах ничего не известно то это так себе конфиг.
4) Ничего не сказано про необходимость использования версионирования. Например вы кэшируете /index.html на 1 день (потому что там, например, прайс и он меняется раз в день) а стиль /default.css кэшируете на 1 год. Допустим что страницу и стиль кардинально синхронно поменяли. Клиент зайдет через неделю, страница у него будет новая а стиль будет старый, что обычно приводит к ломке верстки. Для предотвращения этой проблемы надо именовать стили, включая в имя файла постоянно возрастающий номер версии. Ну и после этого еще и не забывать пережимать стили после изменения (см. п. 1).
5) Опять же — минификация картинок, стилей, скриптов и самих страниц. Для текстов — откат с utf-8 на 8-битную кодировку, если это возможно, мы жде тут каждый байт экономим.
1) Ничего не написано про то, что для работы gzip_static и brotli_static в Nginx вообще-то надо не только включить эти директивы но и еще самостоятельно пережать контент. Директивы всего лишь предписывают серверу использовать заранее сжатый контент, если он есть. А если заранее сжатого контента нет, то директивы сами по себе бесполезны. Так что придется скачать тулзы brotli и zopfli а потом еще написать скрипт, который пройдется по вашему контенту и все посжимает. Если статика время от времени меняется то скрипт надо будет потом прогонять повторно что бы сжатые версии стали бы актуальными. Для этого надо будет либо сделать какой-то автоматический триггер, либо озаботиться организационными мерами.
2) Ничего не написано про промежуточные кэши и про заголовки Accept-encoding в запросе и Vary:accept-encoding в ответе. Без этого появляются неиллюзорные шансы выстрелить в себе в ногу при настройке кэширования. Ну то есть утверждение о том, что Brotli работает только по HTTPS, связано как раз с этми самыми промежуточными кэшами. Про Brotli сказано а про Vary нет.
3) В примере про настройку cache-control в Apache зачем-то написана странная штука:
<FilesMatch "\.(pl|php|cgi|spl|scgi|fcgi)$">
Header unset Cache-Control
</FilesMatch>
<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 5 seconds"
куча всего
</ifModule>
В скриптах могут быть какие-то свои настройки кэширования. В этом конфиге заголовки, выданные скриптом, будут тупо сброшены и заменены на заголовок Expires из конфига. Если о скриптах ничего не известно то это так себе конфиг.
4) Ничего не сказано про необходимость использования версионирования. Например вы кэшируете /index.html на 1 день (потому что там, например, прайс и он меняется раз в день) а стиль /default.css кэшируете на 1 год. Допустим что страницу и стиль кардинально синхронно поменяли. Клиент зайдет через неделю, страница у него будет новая а стиль будет старый, что обычно приводит к ломке верстки. Для предотвращения этой проблемы надо именовать стили, включая в имя файла постоянно возрастающий номер версии. Ну и после этого еще и не забывать пережимать стили после изменения (см. п. 1).
5) Опять же — минификация картинок, стилей, скриптов и самих страниц. Для текстов — откат с utf-8 на 8-битную кодировку, если это возможно, мы жде тут каждый байт экономим.
Sign up to leave a comment.
Как экономить трафик на веб-сервере