Evgeniy, ваще 0 полезной информации(
коротко:
если высокий TTFB - тормозит бэк или криво настроено кэширование
во всех остальных случаях проблемы на фронте
как только будет понятно, где проблема, можно будет предлагать какие-то варианты
Brenli, ваще без разницы на чем делать. Все движки сейчас умеют многое, а в умелых руках умеют почти все
Делать нужно на том, в чем лучше всего разбираются имеющиеся в наличии программисты
ThunderCat, этот показатель гугл использует для ранжирования, так что вывести сайт хотя бы в желтую зону для сео смысл имеет
Конкретно по Largest Contentful Paint - у него там грузится большая картинка, которая и портит этот показатель. Улучшить, не убирая картинку, можно, но пускай учится задавать конкретные вопросы. А не вот это вот "не знаю как мне быть".
ForSureN1, смотри что пишет гугл. Пытайся исправить каждое замечание. Не знаешь как, пробуй разобраться. Не выходит - делай вопрос конкретно по этому замечанию и с инфой, что именно у тебя не получается.
"не считаю это критичным " - а гугл считает
А вот это вот?
Largest Contentful Paint - 10 секунд!
Удалите неиспользуемый код CSS
Для изображений не заданы явным образом атрибуты width и height.
Устраните большие смещения макета
Постарайтесь уменьшить количество запросов и размеры передаваемых данных
и тп
но я посмотрел 3 видео, и в каждом говорят одинаковые вещи,но я и разбираться то в этом не хочу
что я был бы рад любому совету
ну так советы будут все ровно те же, что были в тех 3х видео.
Вернее, совет будет ровно один - тестируем сайт в пейджспиде, смотрим, на что он ругается, правим эти места.
Там у каждого пункта есть подробное описание, есть ссылки на документацию. Есть, опять же, куча видео в интернете на эту тему
ForSureN1, погоди
то есть ты не хочешь разбираться, а хочешь, чтоб мы за тебя все сделали?
Так-то нормальный фронтендер должен уметь делать быстрые сайты. Это не работа сеошника. Сеошник может сказать, "надо сделать столько-то попугаев в гугл пейджспиде", а делать должен уже фронт
все, что советовали выше, фигня (ну как бы оно нужно, но вторично)
самое главное - научится самостоятельно искать информацию в интернете. Без этого навыка обучение затянется на порядок
transcend, не стоит верить всей фигне, что пишут в интернете
>Аналитику в конец.
спорное решение. Асинхронно загруженный скрипт не будет мешать загрузке страницы, но сможет сработать быстрее, чем он же, но добавленный в конец
>SVG как раз лучше в начало
не обязательно
зависит от места, где показан svg на странице
>ссылку на svg-спрайт, либо прямо инлайном запилить в html
не обязательно
добавление ассетов инлайн в страницу увеличивает размер страницы -> боль у мобильных пользователей с плохим каналом
>Если у вас 10 ссылок на декоративные элементы - это плохой подход. На старых http серверах
может стоит вначале выяснить, что у него за сервер? с большой долей вероятности он работает по http/2 или даже что-то новее
для такого типа правильнее делать полностью наоборот - каждый ассет отдельная ссылка
правильный алгоритм для 90% сайтов будет:
инлайним критикал css
все, что не нужно для рендеринга above the fold - откладываем загрузку
но приоритезируем загрузку картинок для above the fold контента (loading=eager)
картинки раздаем в правильном разрешении, в пожатом виде, в подходящем формате
конкретно по вашему сайту
имеет смысл раздавать гугло шрифты с своего сервера, или с CDN, который лежит на вашем домене
так будет выигрыш в ~200 мс для каждого первого запроса к новому домену
дальше смотреть, на что жалуется гугл и тупо выполнять рекомендации
с твоей стартовой темой работать умеешь только ты. И потенциально научится работать с ней может так же меньше разработчиков
с сейдж умеют работать больше
aksutov1996, да елки
можно сделать, чтоб любой скрипт не влиял на гуглопопугаи
чтоб "просмотрщик" был быстрым (как понимаю, под быстротой имеется в виду счёт в гугле, а не нагрузка на процессор, канал и прочее такое), достаточно это скрипт грузить как defer, а всем картинкам сделать отложенную загрузку
дальше уже стоит заморочиться с сравнением размеров бандла (у какого из скриптов при нужном функционале будет меньше грузится js и css файликов)
За цифры скорости не осуждайте, главное, что эти цифры можно сравнивать)
эти цифры вообще ни о чем. На грани погрешности. Гугл сам говорит, что последовательные измерения оной и той же страницы могут давать разный результат
совсем не нужно