pragmatik

Еще раз, как по-вашему PageSpeed Insights должен распознавать принадлежит вам сервер с которого Вы грузите скрипт или нет,

чтобы определять можете Вы сжать этот скрипт или нет?

И как по-вашему PageSpeed Insights должен распознавать принадлежит вам сервер с которого Вы грузите скрипт или нет, чтобы оценивать можете Вы его сжать или нет? По ip?))

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

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

А почему, если не секрет?

\installation\sql

По отношению к вашему бизнесу?))) Ай я яй, какой я плохой, не даю обманывать потенциальных клиентов.

Ведете себя деструктивно исключительно Вы, занимаясь веб-разработкой, не имея при этом соответствующих познаний. Я Вам указал на конкретные проблемы в вашем проекте. И Вы вдруг резко начали рассказывать какой Вы занятой:

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

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

Я Вам уже намекал, что не намерен помогать вам с ТС рыть себе (точнее вашему свободному времени) яму. Приспичило использовать для работы ненадежные инструменты - на здоровье. Хотя бы на своих ошибках чему-нибудь научитесь.

Во-первых, у вас там компонент еще и превью генерирует, т.е. по факту у вас две картинки, вторая открывается при клике по первой, а значит простым "прописать в стиле картинки" не обойдется.

Во-вторых, не факт, что у Вас код, который используется для оформления этих всплывающих картинок, прописывается на страницах, которые не содержат элементов Phoca Gallery. Можно его, конечно, скопировать в общий код шаблона, но тогда на страницах Phoca Gallery он будет дублироваться. Впрочем у Вас там столько дублирующегося кода и лишних библиотек, что хуже уже вряд-ли будет. Я такого низкого показателя PageSpeed Insights еще нигде не видел.

Резюмирую: я бы рекомендовал нанять разработчика, разбирающегося в условиях шаблонов Joomla, чтобы он переработал шаблон под требования PageSpeed Insights.

Еще раз, что Вы подразумеваете под

? Что они по вашему делают, когда "учитывают" к какой категории относится материал, если речь не о навигации? Может Вы хотите, чтобы адрес категории в url работал как лишний ключевик? Тогда, при описанном вами положении вещей, когда он вырезается, поисковые системы, разумеется, его учитывать не будут (сами подумайте, мало ли какие редиректы могут вести к материалу, смысл им их в выдаче учитывать).

Для Joomla существуют десятки различных галерей. Уточните хотя бы о какой конкретно идет речь.

Скорее всего у Вас структура меню не соотносится со структурой материалов, отсюда и такие коллизии. Хотя может и sh404 чудит. Но сама джумла здесь точно ни при чем, т.е. это или из-за кривых рук, или из-за сторонних расширений.Поисковым системам по большому счету без разницы к каким категориям относятся материалы. Вы хотите, чтобы в результатах поиска навигационные цепочки отображались? Тогда да, проблема. Вам придется искать, что влияет на формирование url. Но даже если Вы всё корректно сделаете, это не дает гарантию появления навигационных цепочек (подробнее об условиях их появления в Яндексе, у гугла с этим проще).

Я вижу еще минимум три источника проблем, каждый из которых упирается в бездну непонимания вами процессов веб-разработки:

1. Замусоренный код шаблона = проблемы с формированием кода страниц. На каждой странице грузится чертова уйма ненужного на конкретной странице кода. Выливается это в полнейшую печаль (нажмите на картинку для получения подробной статистики):

2. Отсутствие маскировки использования Joomla. Выливается в рост попыток взлома, которые создают дополнительную нагрузку на сайт, да и могут рано или поздно увенчаться успехом, со всеми отсюда вытекающими.

3. robots.txt. Мало того, что он не содержит линка на sitemap (что влечет всевозможные проблемы с индексированием), так еще и содержит кучу родного для Joomla мусора, которая также служит маркером использования Joomla (последствия - см. в пункте 2).

Пункты выше приведены мною не потому, что мне нравится учить всяких клоунов, а с целью сократить Вам возможности для последующих оправданий и обмана потенциальных клиентов. Учить Вас с нуля не разумно, гораздо разумнее сказать Вам: "Оставьте веб-разработку! Не ваше это! Или потратьте время на обучение и лишь потом оказывайте услуги населению!". А пока Вы предоставляете услуги не будучи в состоянии обеспечить их качество (а теперь то мы знаем, что Вы об этом точно предупреждены, а не находитесь в наивном заблуждении относительно своих способностей) это не что иное, как мошенничество. Ведь даже если Вы не берете при этом денег, ваши клиенты несут издержки, как следствие некорректной работы сайтов.