sim3x: не люблю его и не использую, у меня все fine-tuned. Да и не в этом дело. Зачем мне грузить слайдер, лайтбокс, скроллимейт и еще десяток скриптов + парочку их css на каждой странице, если нужны они только, допустим, на главной? Или валидация форм нужна только на странице контактов. Примеров масса. То же с большими спрайтами. Во-первых, мы сильно увеличивает общий весь страницы и самый первый приход пользователя - отдаем ему тупо все, а там видно будет - пригодится или нет. И если мы грузим это все на каждой странице - получаем как раз замедление рендера - браузер то на каждой странице будет парсить все скрипты и стили, даже этот десяток не используется. В общем, с точки зрения оптимизации это все надо разделять. И вот тут HTTP/2 в помощь. Это один из примеров. Можно углубляться, но смысла нет. Ответ очень прост - если это корпоративный сайтик небольшой или портфолио - все это не важно. Если это high-load и крупный проект - тогда это мегаважно. Собственно из опыта хайлоада все это и выросло у меня в кастомные решения.
sim3x: конкатенация и спрайты. Генерация этого добра хоть и автоматизирована, но тоже время на поддержку этого всего. В моем случае с WP иногда бывает неудобно, особенности платформы. То же касается загрузки скриптов и стилей только там где надо вместо одного бандла. Картинки тоже, вместо одного большого спрайта - ровно то, что нужно на этой странице. И всем этим добром, предоставленным со стороны фронтенда в разобранном виде, а не одной большой соплей, мне на бекенде управлять гораздо комфортнее и быстрее. Фронтендеру проще - он забилдил автоматом сборку и в ус не дует. А мне потом это надо оптимизировать под максимальную производительность. По мелочи, но в сумме какая-то копеечка на каждом проекте. Меньше обезьяньей работы.
sim3x: Да я в курсе. Там, в принципе, в 105 кажется слайде - единственная точная информация из этого спича. Все остальное - синтетические тесты и подгонка под свой маркетинг. Многое не учтено, много сказано с точки зрения CDN а не реальных приложений, и по packet loss там вопросов к их тестам много... В общем, нюансов вагон и тележка. Фастли еще те жуки. В целом, конечно H2 не является волшебной палочкой, да. Но все же, in real world он прекрасно работает и таки действительно заметно и ощутимо ускоряет. А также снимает часть работы с команды, а экономия ресурса - это профит. Особенно в long term.
Skrolea: Может быть такое, что старый сайт на джумле работал с кешированием, поэтому была нагрузка невысокая. А WP из коробки хоть и готов к кешированию, но сам по себе ничего никуда не кешит, если не попросить. Отсюда все запросы - динамика. И вот тут конечно надо смотреть архитектуру и код, ибо напартачить можно было много где. Агрессивное кеширование может решить симптом (испольование ресурсов), но не решит проблему - все что мимо кеша (например, та же админка), все равно будет жрать ресурсы, и хостер будет слезливо просить перестать насиловать их железо. Впрочем, они это делают при нагрузках 5% уже, им же оверселлить надо, там на одной ноде куча хомячков, а вы за десятерых вдруг кушаете.
Дмитрий S: Да, если руками писать ID постов, то такой вариант норм. Единственное, я бы само поле my_related_posts хранил в виде сериализованного массива (нам сырые данные не нужны), и в 'post__in' не нужно тогда делать implode. К тому же, в будущем, если захотите простенький UI доделать чтобы посты можно было искать и добавлять из админки (страницы редактирования текущего поста), а не ID ручками копипастить, то там массив будет к месту.
Не надо ничего менять на относительные, надо использовать функции WordPress, он сам все выведет с правильным протоколом. Не знаете WordPress - не сбивайте с толку.
Георгий: есть вариант попробовать какой-нибудь плагины типа Enable Media Replace или External Media Upload. На .org их хватает, ищите по remote media, remote library, externla media и подобное. Но я лично никогда не пробовал, было пару раз что надо было заменить - менял тупо в базе относительный на полный и все.
Ну ничего из вопроса не понятно. От слова совсем. Где код писать - в плагине или functions.php не имеет особого значение, между этими подходами есть различия, но выполняются они одинаково. А вот по селектам и фильтрам - ничего не понятно. Вместо тысячи извинений написали бы четко по сути, что есть, что надо, что непонятно :)
