Максим Морев

Насоветуют... Менять бэкграунды - забудьте. HTML area - тоже похоронить.

Берёте вашу картинку. Поверх зданий создаёте векторный путь (обводите здания).
Размечаете нарисованные пути как вам удобно, достаточно будет повесить класс для дальнейшей стилизации по ховеру + в дата-атрибуты значимую информацию для тултипа/клика/что там ещё.

<svg ...>
  <path class="area" data-id="1" d="..." />
  <path class="area" data-id="2" d="..." />
</svg>

Инлайните получившуюся конструкцию на страницу. Фон можно в отдельном элементе и карту поверх, можно прямо в SVG зашить - не суть важно.

По ховеру на путь - через CSS делаете ему полупрозрачную заливку, у вас судя по картинке сплошным цветом просто заполняется при наведении - самый простой вариант.

По клику на путь - достаёте его `data-id` и выводите какую-либо информацию.

Вот пример статьи, где описано более подробно.
https://css-tricks.com/svg-map-rollovers/
В конце интерактивный пример есть.
Принципиальная разница с вашей задачей - вам изначально нужны пути без заливки и изображение под ними.

wp_nav_menu(['echo' => false]), м? :)
Оно по умолчанию его выводит, а не возвращает, вот и выводится сначала меню, потом всё остальное.

А лучше бы сразу плагин, который с единственным методом "сделать хорошо" :)
Плагинов таких нет, а если и найдётся, то не советую. Picture - это же не изображение, не shadow-dom магия, это обёртка над изображением, физическая обёртка, реальная. По сути вы хотите обернуть изображение в .
И его, и картинку внутри неё стилизовать надо по-разному. А в случае автоматического оборачивания откуда вы узнаете, что и как стилизовать? А как будете помечать изображения, чтобы не оборачивалось, если не надо? А вы уверены, что всегда надо?

Есть плагины, которые сделают вам дубли ваших картинок в webp и положат рядом или в отдельную папочку.
А picture - пишите сами.
Если лень набирать - используйте сниппеты, если используйте компонентный подход - заведите какой-нибудь компонент `base-picture`, в который передавайте URL основного изображения, и проп по типу `webp`, заданный в `true` по умолчанию, что в контексте логики компонента будет означать, что webp-версию нужно дописать автоматически путём замены расширения в переданном основном изображении (ну или через любую логику, которая вам нужна). Только так.

В закладках лежит glfx.js - выглядит как то, что вам нужно, есть нужный фильтр.
Сам не трогал, нет проектов в работе, где это было бы надо - так что опытом использования не поделюсь.
Но на первый взгляд выглядит весьма удобно. :)

Похоже на то, что у меня было недавно.
Со шрифтами после апдейта иногда происходило вот такое, тоже мелькало периодически:


Вот тут обсуждение моей проблемы, но там кроме советов "включите аппаратное ускорение" ничего полезного нет (а оно уже было включено).

Мне помогло переустановить/обновить драйвера.
Не знаю, какие конкретно - просто пачкой запустил через DPS, наверняка что-то про видеокарту, я тут вообще не специалист :)

Форкнуть, поправить, в зависимостях указать свой форк вместо оригинального пакета.

Здесь нет волшебной таблетки. Это комплекс факторов...
Из главного: ленивая/отложенная загрузка всего и вся (всевозможные метрики и второстепенные скрипты / графика / компоненты, если используете фреймворки), использование современных форматов графики (webp в частности), вёрстка mobile-first (существенно снижает время на расчёт лейаута и рендер на приоритетных устройствах), инжект CriticalCSS (это про time to first paint), уменьшение размера DOM-дерева.
Это из фронта, на бэке - сжатие gzip/brotli, максимальное время жизни кэша, оптимизация времени до ответа.

Они же все рекомендации прямо при проверке пишут, там очень подробно всё расписано.
Волшебной кнопки не существует.

За 100/100 гоняться на чём-то больше стандартного лендоса - как правило бред сумасшедшего (оно обычно можно, но того совершенно не стоит, так как из-за отложенной загрузки/рендера будет страдать UX, что важнее красивой пузомерки).
90+ для почти любого проекта - вполне несложно, если умеючи.
А умеючи - это с опытом, анализом рекомендаций, а не поиском новых сборок/инструментов.

Изначально в сборке этот кейс предусмотреть. Не так уж и много - пути компиляции в WP версии заменить.
Нет так уж сложно :)

Здравствуйте. Вот тут настраивается.

Здравствуйте. Ну не видят люди в этом проблемы, вот и пишут. Не всем быть прогрессивными. :)
Порой мне кажется, что лучше уж так, чем, как иногда встречаются советы, "просто используйте let вместо var и всё будет хорошо" (картинка лица с рукой).

1. Фоновые изображения нужно иметь в максимальном размере;
2. Часто выглядит визуально несколько более законченно, мне всегда макеты, которые шириной контейнера обрубаются, кажутся несколько зажатыми. Особенно на мониторе с 2560 ширины :)
А больше - незачем. Но почему бы и не да - какие ваши аргументы против? Экономите место?

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