Ох уже эти вывод из воздуха.
Добро пожаловать на форум, где люди делятся информацией и её обсуждают. Привыкайте.
Насчёт "прилипалок", а что важнее мифические цифры или удобства пользователям?
Вот поэтому и Google ОЧЕНЬ и очень нежно всё это вводят т.к. боятся сломать всё к херам.
Ещё более наглядный пример: У всех кто использует не стандартные шрифты + swap ВСЕГДА будет смещение контента. И вот тут начинается интересное в реальной жизни.
Или вы загружаете шрифт без swap = будут проблемы со скоростью отображения + если шрифты не локальные, а в Google Font
Я это всё к тому, что нужно менять сам подход к созданию сайтов, НО в эпоху WP+Elementor (или другой редактор)= OneLove! Это практически нереально сделать.
Получит дешёвый сайт и получить быстрый сайт, практически не возможно. Заказчики хотят, чтоб "богато" было на сайте!
Поэтому переделка и оптимизация сайтов это ещё очень и очень долги процесс.
Похоже , теперь и при скролле сдвиг суммируется. Теперь надо отложенную загрузку латать.
Так это он через плагин смотрит самопальный.
Сочувствую. Я сам только недавно разобрался. Проблема в прилипалках, у тебя это хедер таблицы. Вот смотри как CLS растет на скролле:
А зачем CLS в динамике то мерить? Там же важно, чтобы при первой загрузке, элементы не прыгали.
Обновлён плагин AutoPageSpeed для Opencart и Joomla до версии 1.7
Что нового:
+ Убраны из оптимизации CSS для печати+ Добавлен preconnect для внешних скриптов+ Добавлена обработка CSS import
Плагин уже протестирован на 5-ти площадках и отлично справляется со своей работой.
Нам эти слова вообще ни о чём не говорят. И что там за специалист такой, которые не может объяснить, что он имеет ввиду.
Есть бизнесрулы, которые я не могу менять на лету. Меня интересует оптимальный запрос, только)
Попробовал вставить вариант арбнета в консоль - чекер мне покрутил у виска))) Ошибка на ошибке. Не знаю, может в мускле так можно, постгрес ругается. Невозможно апдейтать по 2-м таблицам
Один запрос создать многомерный массив из второй таблице и подставлять данные для него в уже готовый запрос для первой таблицы. Тогда нам только 1 раз надо обращаться к справочнику, так его назовём.
Нет. Суть - найти оптимальное и красивое решение. естественно что все работает и в пределах коммита и в транзакции. Но не хотелось бы идти в базу 50 раз когда можно 2
Все крутится на AWS с оплатой за ресурсы
А может быть поменять первичный индекс? Убрать этот id_ а вместо него использовать name т.к. он там же будет уникальный. Тогда у нас отпадёт надобность обращаться вообще во вторую таблицу, чтобы узнать его id
Вторая таблица останется чисто на вывод информации.
