Как очистить кэш pagespeed

Обновлено: 06.07.2024

У нас есть сервер (OVH-Франция), с Apache и mod_pagespeed . На этом сервере у меня есть установка WordPress.

Я внес изменения в файл Javascript в своей теме, но pagespeed не понимает, что есть новый файл, и продолжает загружать исходный файл javascript. js/ui.js.pagespeed********

Я сделал это изменение две недели назад, перезагрузил сервер сегодня утром, и он все еще загружает исходный файл Javascript.

Как я могу удалить кэш pagespeed?

Могу ли я просто удалить этот файл?

Можно ли использовать mod_pagespeed с сервером приложений tomcat? прямо или косвенно? Правильно ли я говорю, что вы можете использовать mod_pagespeed с tomcat, если используете apache webserver в качестве прокси для tomcat webserver? (работает ли это с mod_jk?)

Rails 2.3.*, mod_passenger 2.2. * и Apache 2.2.*. Стоит ли устанавливать mod_pagespeed или Rails создает все заголовки кэша и т. д. Правильно, так что mod_pagespeed не нужен?

PageSpeed документов Google о Устаревшей Очистке Всего Кэша предполагает это:

При использовании mod_pagespeed в игре есть два разных времени кэширования:

Источник TTL, который mod_pagespeed использует для обновления своего внутреннего кэша на стороне сервера.

TTL, с помощью которого mod_pagespeed обслуживает перезаписанные ресурсы браузеров. Когда mod_pagespeed впервые читает ваш файл reousrce, он использует origin TTL, чтобы выяснить, как часто следует повторно проверять файл origin CSS. Предположим, что ваш origin TTL равен 1 дню. Как только mod_pagespeed будет иметь это файл в кэше, он не вернется & повторно проверьте этот файл в течение дня. Изменение TTL после того, как mod_pagespeed поместил ресурс в свой кэш, не поможет, потому что mod_pagespeed не будет перезагружать ресурс до тех пор, пока не истечет срок действия ресурса в его кэше или вы не очистите его кэш .

Мы рекомендуем использовать origin TTL продолжительностью 10 минут, что обеспечивает разумную оперативность при обновлении файла. Если вы попытаетесь сделать это намного меньше, тогда вашему серверу нужно будет чаще обновлять его. Это увеличивает нагрузку на сервер и снижает оптимизацию.

Чтобы быстрее видеть изменения в ваших файлах во время разработки, очистите кэш на вашем сервере(серверах).

Если ваша среда позволяет включить ModPagespeedLoadFromFile , вы можете получить лучшее из обоих миров, потому что mod_pagespeed может устранить свой внутренний кэш на стороне сервера.

Для получения дополнительной информации, пожалуйста, обратитесь к документации , описывающей этот процесс для получения более подробной информации.

Кто-нибудь использовал mod_pagespeed в магазине magento? Ломает ли он что-нибудь (например, пользовательские оптимизации и т. д.)?) Очень заинтересован в его использовании, но страдает от нехватки ресурсов.

Для для веб-серверов Nginx и Apache существует модуль оптимизации контента, который в свою очередь в уже оптимизированном виде кэшируется в директорию по-умолчанию "/var/cache/pagespeed/", а устаревшие файлы кэша могут доставлять неудобства при регулярном обновлении скриптов.

Способ №1 - очистка файлового кэша pagespeed ака Legacy mode

По запросу "pagespeed clean cache" массово предлагается создавать в базовой директории кэша (по-умолчанию "/var/cache/pagespeed/") некий файл " cache.flush " с дальнейшей перезагрузкой веб-страницы без перезагрузки самого сервера, - однако нигде не говорится, что данный способ "Legacy mode" является утсаревшим и для его успешного применения необходимо дабы аргумент EnableCachePurge был «off», который в новых версиях по умолчанию планируется «on».

По умолчанию система настроена на поддержку только сбросов всего кэша - мы назовем этот устаревший режим. Начиная с версии 1.9.32.1, он также может быть настроен для очистки отдельных URL-адресов. Два режима работают по-разному, и вы можете выбирать между ними для каждого виртуального хоста. Стандартный режим включен по умолчанию, чтобы обеспечить совместимость с существующими сценариями и другой инфраструктурой, которая могла бы быть построена вокруг него. В будущем выпуске отдельная очистка URL станет значением по умолчанию. После этого устаревший режим очистки всего кэша будет исключен. Вы можете выбрать один из двух режимов с помощью аргумента EnableCachePurge. Если установлено значение «вкл.», Вы получите новое поведение с отдельной очисткой URL, а «выкл.» Даст вам устаревшее поведение. По умолчанию установлено значение «off».

Если мы хотим временно отключить использование кэша, то EnableCachePurge must by «on», делаем " touch /var/cache/pagespeed/cache.flush " и спустя сек 5 (так в документации) просто перезагружаем страницу, а дабы снова использовать кэш просто удаляем созданный ранее файл " cache.flush ".

Способ №2 - ручное удаление файлового кэша pagespeed

" Наши умные науки, в наши мускульные руки, штуки разные вложили. Мы им будем удалять. "

Думаю здесь предельно всё ясно. Ненайдя ничего лучшего можно тупо удалять директорию с кэшем, после перезагрузки сервера директория кэша будет создана автоматически.

Способ №3 - автоочистка файлового кэша pagespeed по-феншую

Первыми двумя вариантами забиты все Интернеты, но ведь должен же быть такой "феншуёвый" вариант конфигурации, при котором кэш pagespeed-модуля очищался автоматически через нужный нам интервал времени?! Для настройки регулярной автоматической очиски файлов кэша pagespeed-модуля пришлось ковырять документацию ибо готового и "пережеванного" варианта в Интернетах необнаружилось.

Значит принципы автоматической очиски кэша такие:

Механизм LRU - Least recently used (LRU, Вытеснение давно неиспользуемых): в первую очередь, вытесняется неиспользованный дольше всех. Алгоритмы кэширования — Википедия
По умолчанию предполагается, что FileCacheSizeKb = 102400 (100 МБ), FileCacheInodeLimit = 500000, а FileCacheCleanIntervalMs = 3600000 (1 час)
Кэш не ограничен лимитами FileCacheSizeKb и FileCacheInodeLimit и может превысить их вплоть до заполнения всего диска, а очищаться начнёт, когда пройдёт время FileCacheCleanIntervalMs и будет достигнут лимит FileCacheSizeKb или FileCacheInodeLimit , а очистка прекратится после понижения размера занимаемого кэша до уровня " 0,75 * FileCacheSizeKb " (102400 * 0,75 = 76800 kb) и " 0,75 * FileCacheInodeLimit " (500000 * 0,75 = 375000 inode).

Короче горворя удаляется только 25% от лимитов FileCacheSizeKb/FileCacheInodeLimit через интервал FileCacheCleanIntervalMs по принцыпу LRU (Least recently used).

Но нам бы автоматически удалять весь кэш, ну или хотя бы почти весь, а для этого мы можем сделать FileCacheSizeKb = 2 , FileCacheInodeLimit = 2 и соответственно установить необходимый интервал FileCacheCleanIntervalMs .

Метка времени последней очистки кэша сохраняется в файле " /var/cache/pagespeed/!clean!time! " и обновляется при каждой следующей очистке кэша.

Следует также отметить, что проверка метки времени и соответственно очистка кэша по прошествии FileCacheCleanIntervalMs выполняется только при каждом обращении к хосту (т.е. при посещении сайта), а если обращений к хосту нет, то соответственно "/var/cache/pagespeed/!clean!time!" не проверяется, кэш не очищается, - это поведение pagespeed-модуля выявлено опытным путём, когда FileCacheSizeKb/FileCacheInodeLimit = 2, FileCacheCleanIntervalMs = 600000 (60 сек), но временная метка "/var/cache/pagespeed/!clean!time!" обновлялась с различными интервалами (2, 3, 5 мин) и только при активном посещении сайта очистка кэша и обновление метки происходило с интервалом 60 сек.

Правильно используем кэш браузера и устраняем проблему «не указан срок действия»

Смотрите (снимок ниже) в рамке обозначенной цифрой 1, подгружаются файлы js сторонних сервисов, но вы же не можете им сказать эй давайте включайте кэширование браузерами для своих ресурсов. Увы, в этом случае ничего не поделаешь, и эти нарекания не удалишь.

Сейчас рассмотрим три шага, которые состоят в следующем:

И вот вам первый совет. По возможности, никогда не используйте внешние ресурсы на своих сайтах, это очень тормозит. Так как у большинства не собственные сервера, то эта проблема актуальна. У меня стояла форма обратной связи от одного портала, но я ее убрал, js код тормозил страницу, решать вам.

Переходим к рамке 2, тут указаны замечания для следующих ресурсов, в основном это css, js и изображения. Разберемся, что это за срок действия. Дело в том, когда посетитель заходит на сайт, то его браузер скачивает себе файлы (это мы уже и так знаем из определения выше). Чтобы знать сколько хранить эти файлы у себя в памяти и нужно указывать это время.

Шаг 1. Скачиваем .htaccess

Первым шагом надо скачать .htaccess, все делаетя быстро, через менеджер FTP. В начале нужно будет узнать, на чем работает ваш сервер, точнее его обеспечение. Оно должно быть Apache (95% работают именно на нем, но проверить стоит).

У следующих ресурсов nginx параметры включения данной функции разные, чем у apache, так что я не зря сказал проверить на чем работает сайт.

Дальше, заходим в корневой каталог сайта (через FTP, я использую FileZilla) в папку pablic_html, там находится весь движок вордпресс. Здесь в идеале располагается файл .htaccess, он стандартный от Apache. Он регулирует загрузку и доступы, если его нет то создаем его. Будем его рассматривать в более тематических статьях, пока что нам надо сделать кэширование.

Шаг 2. Вносим mod-header в файл

Если же сделан по новой, то вставляем вот это и закидываем его в корневой каталог.

Разбор строчек кода, за что они отвечают

Теперь надо разобраться за что отвечают все эти строки кода. Все тривиально, вы можете видеть в строчках разные расширения png, jpg и им подобные, и напротив этих расширений указаны числа, это и есть временной отрывок в котором будут храниться эти файлы. Например число 43200, указывает на то что фалы этих расширений будут держаться в кэше один день.

Если все было сделано правильно, то эта строка исчезнет, но мы можем сделать еще лучше, как, читайте дальше.

Плагин для кэширования граватаров NIX Gravatar Cache

Плагин nix gravatar cache- это находка для меня. Я маленько приврал, когда сказал, что не возможно избавиться от загружаемых скриптов с других сервисов. В списке внешних ресурсов вы сможете найти сайт граватара, это условие срабатывает если у вас к статье есть комментарии и к ним прикреплен gravatar. Как не странно, но тут можно включить кэш браузера wordpress для данных картинок.

Я человек дотошный, и все таки нашел решение, оттуда идет только картинка, и соответственно ее можно кэшировать и приделать к ней срок действия.

Решение нашел в плагине NIX Gravatar Cache, я знаю что это есть зло, но от него вообще нет почти нагрузки. Признаюсь, перепробовал три плагина, но только этот делает изображения в jpg, а те в непонятно какие форматы. Все настройки сводятся к двум пунктам, они указаны на скриншоте.

Первая галочка включен или выключен, и второй сколько хранить кэш.

В чем вся прелесть? В том что посетитель оставляет свой комментарий, а плагин автоматом скачивает его граватар на хостинг, и потом уже идет загрузка не из сайта граватара, вот и все. Ставьте обязательно, потому как, лучше один плагин чем сотня запросов (при условии что у вас сотня комментариев).

Кэшируем весь сайт

Чтобы кешировать весь сайт,так же нужен плагин. В этой роли я выбрал Hyper Cache, он легок и занимает не много процессов. Но сейчас его рассматривать не буду, потому как тема очень обширная и мне просто не хватит статьи. Имейте в виду, что надо установить, а как настроить ждите следующей статьи.

На этом я закончу, мы по максимуму прокачали ваш кэш комплексно. В данный момент ему ничего не грозит и ваш сайт будет загружаться намного быстрее.Читая данную статью вы узнали, как устранить пункт: используйте кэш браузера от нашего друга гула по PageSpeed Insights.

Подведем итог, что мы узнали и какой порядок действий

Узнали на чем работает сайт (apache, nginx и тому подобное).
Научились закачивать .htaccess на компьютер.
Отредактировали файл доступов.
Смогли закинуть обратно на сервер.
Поставили плагин nix gravatar cache.

P.S. Если что-то не получилось то смело пишите комментарии, отвечу и помогу.

Поставил, плагин NIX Gravatar Cache, результат улучшился, спасибо!

Пользуйтесь на здоровье.

У меня стоят гугл аналитика и яндекс аналитика. Кешировать их, я так понимаю, нельзя. Как быть в этом случае?

Никак, это невозможно закешировать файлы с другого сервера. Конечно можно, но тогда статистика собираться не будет.

Кешировать можно любые внешние файлы, просто люди не опытные и не умеют это делать, пишут то, что с копировали у других и переписали, сами не знают о чём вообще говорят.

Поделитесь информацией как это сделать? Без вреда к функционалу подключаемых сервисов.

Здравствуйте. Все сделал как вы писали строчка про кеш не исчезла

Здравствуйте, вы через что вставляли код? Через файлзиллу? И еще момент если стоит плагин оптимизации от йоаста, то лучше там прописать. И еще момент очистить кеш.

Просто через редактор хостинга

Очистите кеш, если стоит плагин кеширования. И второе у вас стоит плагин AIOSP (seo плагин), там есть пункт редактирования файлов htaccess, попробуйте через него. Если не поможет, то возможно у вас хостинг не поддерживает данную функцию кеша браузера.

Спасибо понял свои ошибки.

Получилось? Смотрите могу я посмотреть, бесплатно.

Завтра буду пробовать делать, о результате сообщу, сегодня инет лагать начал, медленно все работает

Хорошо, обязательно отпишитесь о работе.

Виктор приветствую. Я так понял что вы сделали на главной страницу, и при выходе новой статьи дописываете в нее информацию?

Доброго вечера. Сделал отдельную страничку, пометил ее как главную. Когда в блоге появляются статьи они отображаются на этой страничке. Точнее анонсы статей. Мне нужно прописать ключевые слова на эту страницу и сделать так, чтобы было описание главной, а не каждый раз разное описание взятое из статей. Возможно ли это как то сделать?

Лучше сделать как делает сам вордпресс, отметить пункт показывать последние статьи на главной, а то так только больше головной боли будет. Почему вы так не делаете?

Вот скрин главной skrinshoter/s/120816/xYXqGE.jpg
На этой странице выводятся 10 последних записей (анонсы)

А вот скрин на анализ сайта skrinshoter/s/120816/CpYcRC.jpg
Как видно на скрине описание взято из последнего поста. То есть описание, каждый раз, с выходом новой статьи меняется, поисковикам это может не понравиться я думаю. Я бы хотел закрепить определенное описание для главной.

Делал, проблемы это не решает. Все равно описание каждый раз разное. А если просто ставить главную страницу, получается некрасиво и не функционально, мне хочется сделать так, чтобы и посты выводились и описание было нормальным. Описание задано в сео плагине All in One SEO Pack но почему то, при анализе его не находит

Подсказал мне один человечек, покопаться в настройках плагина, сейчас буду пробовать

Надо изнутри смотреть, это скорее всего не правильная обработка функции wp-head, потому что плагин привязывает вывод именно к ней. Попробуйте ради эксперимента просто сменить тему и посмотреть будут ли изменения. Если изменений не будет то это плагин.

как быть с этими сайтами? какой плагин кэширует эти изображения?
Спасибо

Александр, с этим ничего не поделаешь, да и не надо, внешние сайты нельзя кешировать. Можно их пропустить через скрипт чтобы он как бы делал маску, но это очень сложно, и не всегда будет србатывать. Главное чтобы:
1. Был включен кеш у браузера.
2. Общее кеширование.
3. Оптимизация скриптов и css.
4. Сжимать собственные картинки.
Все остальное с внешних ресурсов нельзя изменить, не обращайте на это внимание, тем более на ютуб и вконтакте.

Да, все именно так )))

В чем может быть проблема?

Темы на сайтах одинаковые стоят?

Добрый день, странно, сегодня решил разобраться в ситуации и о чудо =) все хорошо работает на обоих сайтах =)

У Вас полезный ресурс, буду еще на днях решать проблему с JavaScript и CSS, используя Вашу статью.

Привет. Со шрифтами от гугла, менять их на файлы и закачивать на сервер и грузить со своего хостинга. Со всем остальным ничего не поделаешь, сторонние файлы увы не закешируешь, а если и закешируешь через скрипт, то они будут собирать статистику 10 секунд в день, и подписчиков так же.

И у меня, после включения плагина, исчезли аватары

А старые аватары были настроены через сам вордпресс, или через какой-либо плагин?

Валентин,а если сайт работает на nginx,также надо прописывать в .htaccess?

На nginx обратитесь в службу поддержки хостинга, там есть специальные модули для этого .htaccess тут не поможет.

Если nginx то никуда, этот код под апаче, если связка nginx и апаче, то код пойдет, вставлять либо после begin wordpress, либо перед end wordpress.

Добрый день! Валентин. Через редактор хостинга вставил код в файл htaccess, но после анализа в PageSpeed ни чего не изменилось. Помогите разобраться очень тормозит сайт.

Ниже отрывок из файла.

Header unset Cache-Control

Приветствую, так а где мой код из статьи?

Копирую и вставляю весь отрывок, а при отправлении выходит то что в предыдущих письмах.

Посмотрел скриншот, вроде все по уму, спросите у своего хостинга, поддерживает ли он функцию mod_header для кеширования в браузерах.

Спасибо. Сейчас испробуем! ;-)

Пожалуйста, будут вопросы задавайте.

Почему у меня ничего не выходит? я все верно копирую ваш код вставляю , он отображается в админке но результат тот же

Вставьте напрямую в файл .htaccess а лучше обратиться к хостеру, они лучше сделают.

Никак если есть внешние скрипты типа метрики.

Здравствуйте, Валентин. Благодарю за статью. Плагин NIX Gravatar Cache наверно больше не поддерживается? Что-то не могу его найти.

Приветствую. Да видно, но если интересует могу его скинуть, а там уже по ftp закините на блог.

Да, было бы здорово. Спасибо)

Напишите мне на электронную почту в разделе контакты, я вам пришлю.

Если нужен хитрозадый вариант то можно путем небольшого хака
просто отшиваем юзерагента PageSpeed Insights в области кода, где у нас аналитика

Эта статья основана на личном опыте. В ней мы разберем основные ошибки и возможности их исправления, чтобы удовлетворить Google PageSpeed, получить высокую оценку, а самое важное, ускорить работу вашего сайта и тем самым произвести позитивное впечатление на посетителей. Пациентом у нас будет сайт магазина по продаже керамической плитки.

Исходный результат у нас следующий:

Подробный отчет о диагностике:

Ускорение работы сайта. Основные этапы

1. Время загрузки первого контента

В отчете прекрасно видно, что первые 6 кадров при загрузке страницы пустые, то есть, браузеру что-то мешает отображать сайт. Эта ошибка возникает в том случае, когда у вас в разделе <head> присутствует большое кол-во скриптов или стилей, или же они расположены в начале страницы. Другими словами, браузер пытается сначала их загрузить, а лишь потом начать отображать. Действие не совсем корректное, поскольку браузер должен делать все синхронно. То есть одновременно начать отображать контент и параллельно подгружать статические элементы (картинки, стили, скрипты).

Наша задача в данном случае, это проанализировать все то, что находится в начале страницы и по максимуму унести вниз до закрывающего тега </body>. Стили также необходимо перенести в конец страницы, вверху оставить только те стили, которые формируют первый экран сайта.

В моем случае, вверху страницы находится: подключение библиотеки jQuery, скрипт по удалению Яндекс.Советника, основная библиотека функционала сайта main.js, подключение Google Tag Manager и десяток css-файлов. Из всего перечисленного в начале страницы действительно нужно только скрипт для удаления Яндекс.Советника и подключение GTM, со стилей нужен только маленький файл для первого экрана. Остальное, а это большая библиотека jQuery и main.js, да и еще десять css-файлов только замедляют работу сайта, их мы переносим вниз.

2. Уменьшение размера CSS-кода и JavaScript-кода

Что под собой подразумевает уменьшение размера кода. В первую очередь, это уменьшение кол-ва файлов, то есть, если у вас 5-10 css-файлов, лучше их объедините. Браузеру проще загрузить один большой файл, нежели несколько мелких. После объединения необходимо почистить сами файлы, под чисткой подразумевается удаления всех комментариев, лишних пробелов и отступов, переносов строк. Этот процесс называется минификация. Чтобы сделать это автоматически можно установить либо дополнительный плагин, если таков существует, либо воспользоваться онлайн-сервисами минификации.

И так, наша задача, объединить, по возможности, все подключаемые css-файлы и все js-файлы в соответствующие большие файлы. Над полученными файлами произвести минификацию.

3. Уменьшение размера HTML-кода

Задача в чем-то похожа на предыдущий пункт, но речь уже не о статическом контенте, а генерации самой страницы сайта. С самого начала вам необходимо почистить файлы шаблонов, чтобы в них отсутствовал закомментированный код, так как он никакой информации не несет, но использует лишний трафик. Далее, после того, как ваш движок сгенерировал исходный код html-страницы и готов его отдать пользователю, вам необходимо минифицировать полученный код, то есть удалить из него лишние пробелы, табуляции, переносы строк.

Пример кода для очистики html:

Казалось бы, зачем удалять эти пробелы и переносы, роли никакой не играют, но на практике размеры страницы сокращаются на 25-50%. Что значительно ускоряет её загрузку.

4. Кеширования статических объектов

Задача достаточно простая, нам необходимо настроить web-сервер, который обрабатывает статику, чтобы он отправлял специальные заголовки браузеру с требованием кешировать картинки, иконки, скрипты, стили, шрифты и прочие подобные объекты.

Как правило, за отдачу статики отвечает nginx, поэтому в конфиг сайта необходимо добавить следующее:

В список вы можете также добавить и другие статически файлы, которые использует ваш сайт.

В случае, когда ваш сайт работает только на apache, в файл .htaccess добавляем следующее:

Также, для эффективной работы с кешем стоит добавлять дату последней модификации файла, пример:

5. Настройка показа всего текста во время загрузки web-шрифтов

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

Делается это добавлением в раздел @font-face<>:

6. Отложенная загрузка изображений

Пример кода:

Скрипт можно усовершенствовать, сделав загрузку только тех изображений, которые находятся в видимости пользователя. А также загружать изображения разных размеров для разных расширений экрана. Но для начала хватит и этого.

Также, по аналогии с изображениями желательно настроить отложенную загрузку фреймов. Поскольку обычно не требуется их первостепенное отображение.

7. Оптимизация изображений

Этот пункт необходимо разделить на 3 части:

7.1. использование правильных размеров

Наша же задача при оптимизации, проверить залитые изображения и в случае необходимости отредактировать их.

7.2. сжатие изображений

Вторым действием будет сжатие изображения. В процессе сжатия картинка, особенно в формате jpeg, может потерять в качестве, но потери не значительны и на практике буквально не заметны. Сжатые изображения весят, в среднем, в два раза меньше, тем самым экономят трафик и повышают скорость работы.

Наша задача, проверить изображения на сервере и по возможности произвести сжатие.

7.3. Использование современных форматов изображений

В последние годы набирает популярности представленный Google формат *.webp. Но заменять сразу все изображения на webp не стоит, так как браузер Safari не поддерживает данный формат, как и старые тоже. А значит львиная доля пользователей будет испытывать проблемы при посещении вашего сайта.

Использование формата webp дает не плохой прирост в скорости и если вы все-же хотите его использовать следует знать, что браузеры, которые поддерживают формат webp отображают это в системных заголовках. То есть при генерации страницы вы можете сделать проверку:

И если браузер поддерживает webp, то отдавать картинки в этом формате, в противном случае использовать стандартный jpeg или png. Но данный способ требует больше дискового пространства и заморочки при добавлении записей.

Таким образом, наша задача заключается в том, чтобы проанализировать все блоки сайта и удалить всю ненужную информацию, сократив размеры страницы, а все удаленное подгружать с помощью ajax.

Результат

Вышерассмотренные пункты можно использовать как чек-лист для любого проекта. Вот эти задачи были применены для нашего сегодняшнего пациента, а именно было настроено кеширование, отложенная загрузка картинок, фреймов, были сокращены размеры css, js и html. Произведено сжатие изображений, исправлены ошибки в верстке, удалены невидимые блоки. В результате имеем следующее:

Для данного сайта это является, практически, максимальным результатом. Возникает логический вопрос, как же другие сайты умудряются получить 100 баллов. Чтобы ответить на него проведем следующий анализ. У нас остается две рекомендации:

Здесь мы можем увидеть, что загрузка скриптов занимает большую часть времени. Проанализировав список самих скриптов, видим, что это скрипты используемые в целях аналитики и электронной коммерции. Все они подключены через Google Tag Manager. Пробуем скрыть код подключения и видим такие результаты:

Поскольку код GTM мы удалить не можем, делаем вывод, что предыдущие результаты являются максимальными для данного сайта.

На этом все, если у вас остались какие-либо вопросы или дополнения пишите в комментариях.

Читайте также: