31 мая 2021 в 1:25
Доброй ночи.
Что можно максимум предпринять для ускорения? Для Google speed test например? И аналогов. Буст прошу не предлагать сейчас соответственно.
advagg, lazy -- что еще? Как всегда ругается на все:
1) картинки (webp понятно, но без изысков пока хочу понять);
2) ШРИФТЫ -- вопрос;
3) JS: сам на себя ругается ведь (или я чего-то не понимаю) -- как победить?
Хотя бы на это есть ответы?
Проблема не в конкретном сайте, она каждый раз возникает: картинки льются ЛЮБЫЕ, JS вообще темный лес (даже если нет "кракозябров" от меня или еще кого), шрифты -- как победить этот кейс вообще?
Я вижу одно: всегда ругань на все стандартное, но клиенты (и я) не хотим видеть такую ерунду в результатах теста))) ОСОБЕННО для мобилки (тут отдельный момент!!!). И, как понимаю, графика -- основная проблема.
Сорян за дилетантизм (хотя, че тут), но я, честно сказать, хочу найти некий вектор (роад-мэп, если что), чтобы закрыть этот вопрос для "стандартных" сайтов.
Можно пинать, только за, уворачиваюсь.
Благодарю за ответы.
Комментарии
Стандартные сайты:
1) статичные страницы;
2) типы материалов;
3) веб-формы (большая куча бывает накидана);
4) вьюсы (и сборки);
5) куча блоков (бывает, блин, у готовых проектов);
6) гео всякое (детект, карты);
7) параграфы;
8 ) галереи и слайды;
9) кривые паралаксы и все похожее.
Если это поможет.
В D9 отличный кэш и 100 баллов можно выбить вообще ничего не делая. НО! Если на сайте куча скриптов типа jivosite и подобных, тор нужно это всё дело оптимизировать
Ну и всё зависит от конкретного сайта. Нужно смотреть узкие места и исправлять их
А как оптимизировать стороннюю штуку? Прям правда так и спрашиваю.
Я, например, если больше ничего не помогает, делаю для всяких живосайтов задержку в 3-5 секунд. Страницы грузятся намного быстрее
Это как?
var script = document.createElement('script');
script.src = "//code.jivosite.com/widget/GwcgiTR56m";
document.getElementsByTagName('head')[0].appendChild(script);
}, 3000);
А если несколько скриптов?
Яндекс метрику т.обр. насколько корректно подключать? Это не повлияет на данные метрики?
А какая разница? Всё что некритичное, можно загружать чуть позже
Метрика критична?
Если метрику или аналитику загружать с таймаутом, то могут быть искажены результаты. Зато показатель отказов будет очень низкий)))) что касается конкретно метрики, то многие забывают о включенном вебвизоре, а он неслабо снижает производительность.
Вопрос со шрифтами решается, если цсс-ку гуглы выкачать и скинуть к себе, а также добавить преконнект (или предоад) на fonts.google.com
По картинкам надо смотреть в первую очередь всё, что во всяких бэкграундах в теме загружено - нужно прогонять в фотошопе картинки через "сохранить для web".
Advagg на 8-9 друпале имеет очень мало смысла. Сжатие и объединение из коробки и так работает отлично.
Что касается всяких там вьюх, они по большому счёту влияют только на TTFB и его производные. Если ответ сервера достаточно быстрый, можно не забивать этим голову. А вот всякие карты надо уже смотреть, сжирают они баллы пэйджспида или нет. Ещё надо не забыть поставить ленивую загрузку на айфреймы.
jivosite, яндекс метрику убираем на время увеличения пейджспида.
advagg - ну поиграйте с настройками. Например bundler количество css файлов может сократить. А jquery на CDN сейчас лучше не размещать.
Картинки тут обсудили https://drupal.ru/node/143446 imagic - хорошо себя показывает для формирования webp.
"сохранить для веб" - в Фотошопе недостаточно хорошо сжимает. Лучше ifran view для jpeg и tinypng.com для png. Хотя со сжатых картинок webp может коряво формироваться.
Шрифты подключать из папки, задаем font-display: swap.
https://google-webfonts-helper.herokuapp.com - поможет.
Карты и формы с рекапчей - на отдельные страницы (модальные окна)
Слайдшоу. В D8 - slick. Он имеет несколько собственных вариантов lazy load. + требует blazy, который подгружает картинки и в контенте, а не только в Слике.
1. Advagg дает, но немного.
2. Метрики всякие, как понимаю, не вариант.
3. Со шрифтами все локально, как правило, и есть. Про swap знаю.
4. slick и требуемый blazy знаю, согласен.
5. Картинки, выходит, неизбежно нужно готовить, кидать все подряд и надеяться на оптимизацию не получится. Просто в этом моменте люди часто (почти всегда) думают, что "все можно сделать, Гугл же показывает, что плохо". webp, да, все-таки отдельная тема.
6. С бэкграундами не совсем понял. Они же наоборот, кажется, быстрее должны работать, нет?
Пэйджспиду всё равно, где картинка - в бэкграунде или просто картинкой. Просто всё, что загружено в тему, нужно оптимизировать изначально самому.
Кроме того, есть очень интересная статья у Никиты https://niklan.net/blog/139
Картинки. Необязательно готовить у себя. views + формирование урла картинки с альтом и шириной+ тег picture c webp и пониженным разрешением для мелких экранов дадут хороший результат
Не понял. А если тупо речь про материал с графикой? С picture и понижениями понятно, но как это вкрутить в ноду? Сорян, вообще не понимаю как.
Если изображение через поле - вьюху сделать можно - и там полный разгул для творчества.
Если вставлено, непосредственно в текст - не знаю. Разве что контенщика выдрессировать. Но blazy частично спасает ситуацию.
Блайзи на инлайн, допустим. Но я честно не понимаю: зачем на на поле вьюсы вешать? А про разгул понятно конечно. Можете дать трешовый (или стандартный) пример для этого? Ведь то, что лучше не трогать -- лучше не трогать. Нет?)))
Поле выводить вьюсом чтобы меньше програмировать вывод поля картинки.
В views в гораздо больших пределах можно вывод кастомизировать.
Еще подробнее.
Вывожу поле во вьюс, а потом пихаю вьюс в материал? Ниче не понял, честно.
да. совершенно верно.
только во вьюсе вы можете указать вывод изображения в нужных вариациях под нужные разрешения для тега picture без всякого мусора в коде. а если это будет поле - придется заниматься программированием ради банальных задач.
президент моего фан клуба adano очень любит подобные методы.
Так это дичь, на мой взгляд. Я может и не сталкивался с такими сложными задачами, где это нужно, но правда не могу понять такого подхода. Это, типа, "вышел, зашел, снова вышел, а потом вспомнил про ключи на столе".
Не настаиваю и хочу понять смысл. Дайте пример реальный. На словах просто.
Пример чего? Я думаю вы поняли, как вывести поле вьюхой. И как в этой вьюхе все кастомизировать.
Про изображения.
Выводим несколько раз поле картинки. На каждый раз применяем разные прессеты изображений в т.ч. сгенерированные с webp. Каждый раз форматируем в виде урла и тут же задаем width, height, alt. А потом все это оборачиваем тегом picture.
Тут пробоем нет.
Вот теперь понятно.
Все-таки не проще кодить (сам не уверен сейчас) поле, чем такой изыск делать? Еще раз: я серьезно. Я согласен про простоту, так сказать, но не думал (не было таких задач). Однако, мы делаем много всего, чтобы просто отдать поле с пикчером.
Я знаю, у вас был кейс про webp, например. Я не планирую переубеждать, даже интересный вариант, просто поясните: просто тупо накинуть webp на поле, а в шаблоне дать размеры и альт нельзя? Вероятно, туплю.
Можно, но так не интересно. 🤓
Как минимум обходимся без responsive image (хоть он в ядро встроен) и webp. Хотя придется ставить imagick и хостинг теребить.
Как бы если будете изображение через slick (и в views) выводить - у него много мусора в коде будет. Это слегка расстроит сеонистов агитирующих за чистоту кода.
На "сеонистов" мне пофиг. Делаю, что могу. Дальше - ждем или отказывайтесь. Я как гуру себя не предлагаю. Вот вам "спаисбо".
Для картинок есть еще Image Optimize, Image Optimize Binaries.
Если на сайте изображения в виде фотографий, а владелец упорно загружает туда png, то можно их по-умолчанию конвертировать в jpg в настройках стилей.
Плюс Responsive image под разные размеры экрана. Правда он не добавляет width и height, что не есть хорошо, т.к. браузер не знает соотношение сторон. Но для этого есть патч на drupal.org
Обычно после этого Гугл перестает настаивать на оптимизации изображений или применении "современных форматов" даже если webp не используется.
Благодарю.
Это да.
Это да, но вот именно размеры. За намек на патч спасибо.
Всем спасибо.
Собак не ел и никому не желаю. Но тема открыта конечно. Жду "все", любой изыкс.
А вот вопрос конкретный уже.
При кэше (эдваг есть) пропадают текстовые картинки (не фонтависом, но не имеет значения). Без кэша - все есть. Не ожидал, что наткнусь, но писал тему общую, а заметил в конкретной сборке проблему. ЧЕСТНО. Ничего не менялось, просто реально кэш влияет, проверил несколько раз.
Путь к файлу шрифта прописан относительный?
Да.
Относительный от корня сайта или от расположения файла стилей? Если второе, то всё логично - CSS-ка сжалась и легла в sites/default/files, а шрифты лежат в теме. Надо прописывать путь от корня сайта.
Благодарю. Не подумал.