ну... можно обойтись. но в перспективе переход на J4 не радует - smart search просто монстр и раздует таблицы нереально. визуально gsc выглядит не очень. но Денис говорит, что поиск гугла положительно влияет на показатели.

Володь, на j4, получается, кроме smart search нет альтернатив. что думаешь по поводу этого компонента поиска и размеров тиблиц, которые он генерирует?

Володь, на j4, получается, кроме smart search нет альтернатив. что думаешь по поводу этого компонента поиска и размеров тиблиц, которые он генерирует?

Ну мы свой вариант будем юзать

это тот поиск интеллектуальный с сайта дачи?

В jed нету ли поисков для joomla 4?

Если он тебе про фронт будет говорить - то слушай. А вот про сео - я бы воздержался

если и есть, то нет поддержки билдера. нужно будет писать интеграцию. вообще жаль, что обычный com_search забросили

Никогда не использовал, ни это ни смарт поиск Простой вариант добавить CSE. Можно ещё стилями его обвешать

вообще-то гугл должен за такое дело наказывать. нельзя свои стили для google adsense использовать на уровне css, насколько я помню. с поиском, полагаю, тот же эффект

Для гугл адсекс ты стили не применишь. А вот в поиске там можно развлекаться и красить как угодно, прям с сайта CSE

я посмотрел, размер шрифта поменять нельзя. во фришной версии

Может ли js вычислить, что страница загружена поисковым ботом?

У меня на joomlа сайте в мобильном хроме при отрисовке 3000 dom элементов загружаемых через ajax, страница начинает тормозить и я их искуственно кооментю через js до определенного момента. Хочу чтобы js для бота не комментил эти элементы и учитывал в поисковой выдаче.

Таблица из 1000 слов на английском с переводами, транскрипцией и кнопкой озвучки

Нужно индексировать слова?

Да

У меня на joomlа сайте в мобильном хроме при отрисовке 3000 dom элементов загружаемых через ajax, страница начинает тормозить и я их искуственно кооментю через js до определенного момента. Хочу чтобы js для бота не комментил эти элементы и учитывал в поисковой выдаче.

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

Я нашел возможное решение, как убрать тормоза при отрисовке большого числа DOM - это css content-visibility. Завтра буду тестить. Если сработает можно будет боту и юзерам отдавать одно и тоже.

Нужно индексировать слова?

Доброе утро. Сайт сделан как приложение, рассчитанное на сотни тысяч прсетителей, в т.ч. и оффлайн, в этом случае на ux/ui выходит на первое место и минимизация нагрузки на сервер. Плюс в индекс поиска должны попасть все слова. Основной смысл подгружаемого списка это показать юзеру слова по типу их освоения, пройденные без ошибок, с ошибками, не пройденные. Поиск для удобства, он же не должен происходить на серваке. Сервак должен отдавать заранее кэшированные страницы, которые service worker должен ложить в кэш браузера, тем самым перенося всю вычислительную нагрузку на устройства юзеров.

Доброе утро. Сайт сделан как приложение, рассчитанное на сотни тысяч прсетителей, в т.ч. и оффлайн, в этом случае на ux/ui выходит на первое место и минимизация нагрузки на сервер. Плюс в индекс поиска должны попасть все слова. Основной смысл подгружаемого списка это показать юзеру слова по типу их освоения, пройденные без ошибок, с ошибками, не пройденные. Поиск для удобства, он же не должен происходить на серваке. Сервак должен отдавать заранее кэшированные страницы, которые service worker должен ложить в кэш браузера, тем самым перенося всю вычислительную нагрузку на устройства юзеров.

Сайт это PWA с интегрированными landinding page по адресам /ru, ru/en ктоторые после после перехода по ним юзеру больше не показываются. Страница /ru/en/courses/vocabulary это главная страница для курса vocabulary, будет еще курс grammar. Внутренние страницы занятий например ru/en/courses/vocabulary/elemenrary работают как обособленные приложения, при кликанье по кнопкам на них открывают различные разделы без внутренних переходов. Сайт сам мо себе мульиязычный, и позволяет выбрать различные языки сайта и обучения (пока все эти языки отключены) для каждого языка языка создается отдельный service worker и манифест, что позволяет делать отдельные pwa для каждого языка (поэтому рассчитан на юзеров по всему миру и предполагаемая нагрузка сотни тысяч в сутки). В мобильной версии сайта в футере есть кнопка установить приложение, если нажмете ее, то сайт установится установится на телефон как нативное прилоение (для андроид точно работает для appla не проверял). В идекс слова нужно загонять, чтобы индивидуализировать страницы обучения (у всех таких страниц оболочки одинаковые кроме хедера), также вижу что страницы с загруженными таблицами слов в топе поиска по соответствующим запросам.

Здравствуйте :) видно, что идея продумана, но мне кажется продумана в корне не верно. Самая первая проблема - это перекладывать что-то глобальное на клиента. В целом конечно так делать можно, но изначально тогда необходимо делать некое хранилище на клиенте, по типу бд, далее туда прогружать необходимые данные для работы и уже потом нативно с этим работать. В случае ежели это клиент, который централизированно должен работать с данными с сервера и эти данные должны быть доступны для разных вариаций клиента, тогда он должен быть тонким клиентом и ничего сам не делать, кроме рендера готовых данных. Далее индексация всегда дело сложное и не совсем интуитивно понятное. Поэтому если вы хотите индексировать различные вариации данных (в данном случае как я понял текстовые), то как мне кажется тогда это делать нужно на сервере и изначально проектировать архитектуру сервиса исходя из этих потребностей. Иными словами надо бы взять какой-нить эластик, туда напихать данные и уже от туда на клиент подгружать готовые данные. Иначе как я понял, получается вы что-то структурировано рендерите, потом это как-то наобум хотите проиндексировать, а потом из этого что-то осознанное получать. Так проще сразу структурированные данные осознанно проиндексировать и дальше с ними работать, пропуская непонятный шаг. Короче сайтом тут не отделаться. Надо спустится на уровень архитектуры серверной. Далее, разговоры про сотни тысяч пользователей в нагрузке всегда преждевременный, если это не авито с 10 годами работы или что-то подобное :) тут моя мысль следующая, не надо про оптимизацию думать раньше времени. И ещё, если на js на клиенте что-то делать, например запускать воркеры или что-то обсчитывать, то как минимум мобилы сразу сядут, а компы у людей будут нагреваться и жрать ресурсы. Таким макаром продукт далеко не уедет

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

Например нажатие на кнопку «начать» почему то приводит к тому что вываливается непонятная надпись Дальше что делать?

Выбрать язык обучения, их будет несколько

так а нафига отрисовывать много дом элементов? я просто вот не могу понять зачем в целом этим заниматься, отрисовавыть нужно по идее только то, что клиенту нужно в данный момент, а не все подряд

Я вообще не понимаю зачем использовать pagebuilder да еще и такой неудачный в таком мелком приложении которому он не нужен

Джумла из коробки прекрасный инструмент Вы выбрали почему то странное решение И вы утверждаете что у вас localstorage работает с service worker?

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

Еще бы найти эту кнопку 🙂

Не буду мешать