Добрый день! Очень долгая загрузка страницы сайта (и других, с подобным содержанием) http://pc-do.ru/remont-kompyuterov-i-noutbukov-v-yuao/m-avtozavodskaya По тестам (google и другие сервисы) - 60 из 100. Визуально полная загрузка страницы около 10 секунд. Включил Gzip-сжатие страниц стандартными средствами. Установил JCH Optimize бесплатной версии, включил авто настройку. Стало немного быстрее, но все равно долго. Можете что то подсказать? Купить платную версию JCH Optimize (будет ли значительная разница)? Другой плагин? Сделать какие то настройки вручную? Может какой то один скрипт так нагружает, как вычислить? Нужна ваша помощь!
1. Стоит обновить движок. 2. Gzip а так же кеширование лучше делать серверными средствами. 3. JCH Optimize Замедляет сайт, если фронтенд он и чутка оптимизирует, то бэкенд ака скорость ответа сервера он замедляет причем прилично, да и нагрузка растет. 4. Если говорить о серверной оптимизации так же стоит убрать все лишнее особенно плагины. Различный сбор статистики Joomla уведомления об обновлении ядра и т.д 5. С фронтом может так же помочь PageSpeed nginx module. Закешит картинки, объединит css и js выделит критикал и т.д и кушает не много 6. Убрать сделать ajax некоторые модули. 7. Ну и кончено же, по возможности, оптимизировать шаблон. Кроме того как я люблю говорить, баллы и тесты предназначены для разработчиков и носят в себе рекомендательный характер, не стоит за ними гнаться если это повредит сайту. Довольно таки давно, но писал небольшую статейку на этот счет https://septdir.ru/blog/web/joomla-pagespeed-insights.html
Я удивлён, что никто из отписавшихся не посоветовал автору открыть инспектор браузера, перейти на вкладку Network / Сеть или т.п. и нажать Ctrl+F5. На появившейся диаграме будет видно наиболее тяжёлые для загрузки ресурсы (время загрузки картинок, скриптов, стилей и т.п. в мс). Возможно, получится ограничиться сжатием картинок и минимификации файлов стилей и скриптов.
Да я согласен на все 100. Я говорю странно, что о таких вещах не написали, а ведь с этого начинается оптимизация любого проекта, ИМХО
Возможно, многие просто не знают что это такое, можно написать небольшой материальчик --- добавлено: May 6, 2018, первое сообщение размещено: May 6, 2018 --- Не все знают, что на сайтах с тысячами материалов (страниц) более 90% времени запроса к базе занимает ACL (Access Control List) Если включить «Показывать ссылки неавторизованным», то скорость может вырасти на порядок, но это только для больших сайтов, если страниц мало, никакого эффекта не будет
Оптимизация любого проекта начинается с бэкенд и только после этого делается фронт. Без фронт оптимизации скорость загрузки страницы будет зависит от "стороны клиента" то бишь скорости интернета, рамы и т.д. А вот без бэк оптимизации будь у тебя хоть гигабитный интернет и 3 css файла на весь сайт. Он все равно будет грузиться по 10 секунд. "Запрос к базе ACL" делается единожды для каждого userid после чего результат кешируется, знай и люби ядро. Результат pagespeed следующее 1 секунда для бэк части это много. даже для крупного сайта. С остальными двумя пунктами можно воевать вечно. Ну для начала можно все js и сss склеить в один. Перенести все вниз сайта без вреда вряд ли получиться ибо без jq начнутся глюки, хотя судя по именам файлов не используются .min, но использование minified версий стилей и скриптов в наше время даст лишь не значительный прирост На метрику и аналитику будут ругаться вечно, есть способы обмануть но и они не вечны. Вообще все эти проблемы решает нормально настроенная VPS с nginx модулей pagespeed(и стили скеит и кеш сделает и критикал выделит) [B][/B]
Читаем статью внимательно Читаем мой первый пост Кроме того я полностью согласен с zikkuratvk com_content в легкую справляется с 10-20к материалов. И в модулях в том числе ни каких проблем нет. Хотя свои модули лучше Кстати ниже ответ автора Еще раз люби и знай свое ядро =) --- добавлено: May 8, 2018, первое сообщение размещено: May 8, 2018 --- Вообще если говорить об ACL то проблема с ним действительно есть и о ней знают. Но проблема не имеет отношения к com_content. Сама система прав доступа очень тяжелая и компонентах зачастую для безопасности делают слишком много проверок. Однако данная проблема не стоит в приоритете. Хотя бы до того момента когда кто нибудь не рискнет своими нервами и здоровьем, и не создаст PR.
Ты со своей колокольни глядишь, я со своей (как фронт). Особенно после блокировки IP-адресов гугла озаботились этим) Вообще, огромное спасибо Роскомнадзору, за такие вещи. Я думаю, огромное кол-во фронтендов и админов серьёзно повысили свою квалификацию с сфере оптимизации фронта Ты открой практически любой сайт крупного магазина, банка - это же жесть: прямо в head подключается по 50 скриптов и стилей, неоптимизированные картинки, повторение кода скриптов. А многие из этих скриптов вообще работают на 1 странице из 100. Приняв во внимание то, что кэширование и сжатие на некоторых сайтах не настроено вообще - это пипец... После того, как начал отваливаться GTM, и, что самое ужасное - Google maps (на базе которого была напилена куча расширений) это стало фатальным. После того, как происходит "google is not defined", о котором, наверное, вся страна узнала за последние 2 недели, функционал многих страниц просто рушится (т.к. все ж скрипты врубают по классике - чисто через document.ready ). Вот такие дела. А бэк - ну да, конечно полезная штука. И нормализация таблиц в базе тоже полезно. Но всё же я начинаю с фронта. P.S.: @Septdir, почитал посты твои - это очень здорово, что на форуме появился такой мужик
Если брать скрипты. Подключать их только на нужных страницах тоже бек. А склеивать в один отлично умеет pagespeed nginx. А вот насчёт гугла. Я лично шрифтами пользуюсь. Но и то в последнее время их локально держу. Так кеширование лучше получается.
Пробовал пару раз. Получается жутко не контролируемая и тяжеленная вещь. Да и в контейнеры пихают все что не поподя
