15 лет сидел на опере. Но после последнего изменения дизайна, я понял, что всё... надоело это, и тормоза, и баги.
Перешёл на Edge, это небо и земля! Работает быстро. Конечно надо под себя настроить, это открытие для меня. Оперу удалил со всех устройств.
И теперь внимание вопрос - насколько (по мнению Гугла) должен быть упразднён JS интерактив для мобильной версии, чтобы укладываться в 0,2 секунды?
Что при этом делать с картами и прочими интерактивными элементами?
Никто не знает т.к. INP не возможно измерить в момент (пока), это накопительные данные только.
C рекомендованным до 0,5 секундным показателем?
Думаю, большинство вебмастеров будут игнорировать этот показатель, ибо они и сами на своих сервисах его не вывезут.
Уведомление уже сыпется, если выше 0,2 секунды. Выше 0,5 это всё ппц по мнению гугла.
По простому то да, именно проверка сколько приколюшек задействовано при клики и других действиях.
Но, как всё это тестировать в реальном времени, нет инструмента. Всё отдано на то, что кодер JS знает как оптимизировать свой код.
Вот тут у меня и возник первый затык. Если время на сайте в среднем 3 минуты, а показатель INP гуглу не нравится - значит страница грузится в среднем более 2 минуты 32 секунд?! Но это нонсенс. По метрикам всем (в т.ч. гугловским) даже из америки сайт с моего хоста в рф грузится не более 5 секунд. По рф (а он для рф) вообще менее секунды. Поэтому пока полностью непонятки.
Вы наверное говорите про TTFB. А INP это когда ВСЕ ваши JS и CSS загрузили полностью до конца и страница готовая к использованию. И всё это на мобилках с медленным 3G-4G тестируется.
Сейчас опять начнётся хайп про зелёные зоны и люди не понимаю, что есть разница в скорости открытия HTML и скорости когда JS наконец-то закончат свою работу. Сразу напишу пример:
Ваш сайт = коробка с вещами.
CDN, TTFB и "мой сайт быстрой открывается" и т.д. это всё про доставку коробки от сервера до вашего браузера.
Далее эту коробки браузеру надо распаковать и разложить по местам, попутно вытирая от пыли. А это уже: FCP , LCP , TBT, CLS и теперь ещё INP
Ещё раз, это показатели НЕ касаются ни кэширования, ни gzip, ни CDN, ни первичной загрузки вашей страницы.
Да это ЖОПА для JS кодеров. Этот параметр исключительно собирательный т.е. измерить его в момент нет инструмента от Гугла. Поэтому вопросов очень много по этому параметру.
Все рекомендации от Гугла, это оптимизация JS скриптов, НО проверить достаточность оптимизации я не понял как в реальном времени.
B-Tree и при этом хранить в памяти?
Тогда уж redis.
Если площадка позволяет, я не против. Применять технологии именно так как требуется.
дело в том что там будет много записей. около 1-2млн. наверно тоже по памяти будет напряг
чем вас sqlite с индексом не устроил не понятно, уже бы запустили и всё работало. Если надо просто поместите бд файл в память и всё будет работать еще быстрее.
На MOdX?!
Извращение в кубе. Наймите программа, чтобы он вам на WP это перекинул и забудете о проблемах.
Насколько я помню по нескольким случаем работы с этой системой (лет 5 назад), это довольно своеобразная CMS.
