Оптимизация под Page Speed

Alines · 18-03-2020, 17:04:14

Цитата: alexakap от 18-03-2020, 16:37:24
Откройте код сайта и перейдите по ссылке, по которой у вас подключаются шрифты
<link href="https://fonts.googleapis.com/css?family=Noto+Sans:400,700&display=swap" rel="stylesheet">
У вас подлючаются все возможные языки в формате .woff2
Вам нужен только латинский с font-weight 400 и 700, поэтому вам надо только 2 файла
Я не против, можете подключить все. Но зачем, если они не используются

Возможно, что падение скорости у меня было из за того, что я все файлы подключал на два типа шрифта? Потому что speed insight у меня как раз на эти файлы и ругался и их размер.

pihovkin · 18-03-2020, 17:09:43

Буквально сейчас сами этим занимаемся и перепробовали различные методы.
Естественно картинки нужно делать те, как рекомендует PageSpeed Insights.
Также не маловажным будет применить Laizy Load к страницам, от которых требуется высокая скорость загрузки. Также необходимо подключать более легкие библиотеки. Это нам дало примерно 5% к приросту скорости. Ну и как вариант - делить js на чанки.

lalmazl · 20-03-2020, 01:36:24

главное не используйте data-src для img, ужасно раздражает такой подход по замену стандартного тега, лучше просто для хрома loading="lazy".

Alines · 20-03-2020, 12:10:56

Цитата: lalmazl от 20-03-2020, 01:36:24
главное не используйте data-src для img, ужасно раздражает такой подход по замену стандартного тега, лучше просто для хрома loading="lazy".

Насчет loading="lazy". Пробовал эту фишку. Нифига не работает. Может что-то делаю не так? Прописываю тэгу img вот так: <img src="/images/image.jpg" loading="lazy"/>

Val_Ery · 20-03-2020, 12:54:16

Цитата: Alines от 20-03-2020, 12:10:56
Насчет loading="lazy". Пробовал эту фишку. Нифига не работает. Может что-то делаю не так? Прописываю тэгу img вот так: <img src="/images/image.jpg" loading="lazy"/>

Там несколько моментов...
1. Не надо закрывать img. У вас все-таки html5
2. Работает эта фенечка тока в хромообразных, исключая сафари. В огнелисе работать не будет
3. С самим атрибутом, вроде как, рекомендуют использовать указанные в теге img ширину и высоту
4. Говорят, что есть проблемы с зазорами. Ну, то есть, картинка должна появляться при скролле. Если картинок много и все разной размерности, хром не может правильно рассчитать момент появления для каждой из них
5. Если желаете использовать картинки для разных брейкпоинтов, то атрибут надо применять только к основному изображению:
picture - > source + img
Источники, как и положено, по брейкпоинтам, а в имг - атрибут...

Alines · 20-03-2020, 13:24:02

Цитата: Val_Ery от 20-03-2020, 12:54:16
Там несколько моментов...
1. Не надо закрывать img. У вас все-таки html5
2. Работает эта фенечка тока в хромообразных, исключая сафари. В огнелисе работать не будет
3. С самим атрибутом, вроде как, рекомендуют использовать указанные в теге img ширину и высоту
4. Говорят, что есть проблемы с зазорами. Ну, то есть, картинка должна появляться при скролле. Если картинок много и все разной размерности, хром не может правильно рассчитать момент появления для каждой из них
5. Если желаете использовать картинки для разных брейкпоинтов, то атрибут надо применять только к основному изображению:
picture - > source + img
Источники, как и положено, по брейкпоинтам, а в имг - атрибут...

Спасибо за разъяснения. Но что-то слишком много нюансов. Пока буду и дальше на jquery использовать.

Val_Ery · 20-03-2020, 14:17:37

Цитата: Alines от 20-03-2020, 13:24:02
Но что-то слишком много нюансов. Пока буду и дальше на jquery использовать.

Там один Самый Главный нюанс: оно работает только в хромообразных. И я совсем не уверен, что будет работать в мобильном хроме.

P. S. Сам такого никогда не использовал. Потому что пользуюсь Огнелисом, а там это - не работает.
P. P. S. Если жикверю приходится ставить только ради ленивой загрузки, посмотрите, как это реализовано на Javascript (там совсем не сложно, описаний множество и... не надо подгружать jQuery).

4X_Pro · 23-03-2020, 02:01:48

Цитата: Alines от 18-03-2020, 13:09:45
Но по поводу шрифтов ситуация обратная. По крайне мере, если речь идет о гугл шрифтах. Буквально пару дней назад делал тесты на нескольких своих сайтах. Шрифты были встроены через гугл. Скачал их, внедрил на сайты локально. Как результат скорость загрузки страницы упала на 10%. Вернул обратно как было и скорость возросла обратно.

Вопрос: а как именно вы их мерили? Локально со своего компьютера или через сервисы типа PageSpeed и GTmetrix?
Дело в том, что тут еще географическое положение серверов влияет. Сервера GTMetrix и PageSpeed расположены в Америке. И, если ваш хостинг находится в России, качать шрифты с него им будет дольше, чем с CDN Google, который тоже находится в Америке. А вот для пользователей окажется все наоборот: скачать шрифты с географически более близкого сервера быстрее (если у хостинга канал нормальный), чем с CDN из Америки или Европы.

ЦитироватьОтносительно js и css файлов согласен. Это значительно ускоряет загрузку страницы. Особенно если они объединяются с помощью плагина, минимизируются и поддаются gzip сжатию. Переносить их нужно, даже основной файл библиотеки js. Это хорошо прибавит в скорости.

Недавно пришел к выводу, что склеивать файлы в один имеет смысл только в том случае, если не используется HTTP/2. В случае, если на сервере есть поддержка HTTP/2, достаточно просто обеспечить асинхронную загрузку для всех CSS, кроме основного (который обычно style.css называется) и отложенную (с атрибутом defer) загрузку JavaScript. В этом случае не будет задержки отображения до момента, когда прогрузится и обработается весь огромный склеенный CSS-файл, а только до момента загрузки основного.

Добавлено: 23-03-2020, 02:15:34

По поводу WebP: если на сервере стоит Apache, то его поддержка добавляется очень просто. В .htaccess можно добавить проверку на то, поддерживает ли броузер формат WebP (это передается в заголовке Accept) и если да, выдавать его вместо JPEG:

Код Выделить


AddType image/webp .webp
<IfModule mod_rewrite.c>
 RewriteEngine On
 # Check if browser support WebP images
 RewriteCond %{HTTP_ACCEPT} image/webp

 # Check if WebP replacement image exists
 RewriteCond %{DOCUMENT_ROOT}/$1.webp -f
 # Serve WebP image instead
 RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=accept:1]
</IfModule>

<IfModule mod_headers.c> 
  Header append Vary Accept env=REDIRECT_accept 
</IfModule>

Соответственно, файлы WebP должны быть с теми же именами и по тем же путям, что и JPEG, но с расширением .webp.
Если на сервере установлен ImageMagick и есть SSH-доступ, то можно конвертацию можно сделать автоматически:

Код Выделить

mogrify -format webp *.jpg
Единственный минус — может вырасти нагрузка на ввод/вывод из-за необходимости при каждом обращении проверять существование файла.

Alines · 23-03-2020, 12:28:05

Цитата: 4X_Pro от 23-03-2020, 02:01:48
Недавно пришел к выводу, что склеивать файлы в один имеет смысл только в том случае, если не используется HTTP/2. В случае, если на сервере есть поддержка HTTP/2, достаточно просто обеспечить асинхронную загрузку для всех CSS, кроме основного (который обычно style.css называется) и отложенную (с атрибутом defer) загрузку JavaScript. В этом случае не будет задержки отображения до момента, когда прогрузится и обработается весь огромный склеенный CSS-файл, а только до момента загрузки основного.

Может я что-то не понимаю, но сколько не пытался использовать defer или async, перестает работать тот или иной скрипт вообще. У меня используется HTTP/2. Я объединил все CSS в один файл и все JS в один файл, минимизировал и сжал. Скорость выросла на 10-15%. Разница ощутима.