Игорь Воротнёв

Верстка под WP по сути укладывается всего в несколько отличий от верстки под что либо еще:

1. В некоторых местах (body, меню, обертки страниц/записей и тд) WP генерит свой список классов. Его можно и нужно использовать, если тема предназначена на продажу или в репозиторий на .org, предполагается что ее будут крутить/развивать под свои задачи. Если для себя / для клиента, то можно не использовать, но как минимум с меню придется на бекенде несколько правок сделать.
2. Контент, который редактируется в редакторе (старый TinyMCE или новый Gutengerg) либо лишен классов по умолчанию (тогда стучимся по классу контейнера), либо как разработчики намудрят (Gutenberg, всякие конструкторы страниц). В принципе, можно полностью под себя сделать с Gutenberg, но это дополнительные временные расходы.
3. Статика (скрипты, стили) подключается из PHP, картинки и другие файлы - как правило тоже, через медиа-библиотеку.

Иногда что-то по мелочи попадается, но в целом - это все.

BB 8,

wp-мэйт просит чтобы у динамического контента не было КЛАССОВ ВООБЩЕ

Вот это ключевой момент. И в комментах вам уже написали, что проще ваш CSS поменять, нежели редактор WP. Технически, редактор WP научить можно. Но он сохраняет весь динамический контент в БД вместе с HTML (и классами). Это означает, что если вам понадобится класс переименовать, или добавить новый модификатор к "всем таким же блокам или элементам" - то вам придется лазить по всем старым записям и менять это там тоже. Что, разумеется, не очень ок.

Какие есть варианты? Всякие Visual Composer'ы, но они тоже сохраняют HTML в базу, поэтому риски те же. ACF и подобные решения для произвольных полей, которые позволят разбить контент на "блоки", и каждому блоку на выводе можете давать свой темплейт. Но если контента много, по нему надо искать и тд - опять же, вагон лишней работы бекендеру. Ради чего? Какой профит?

Есть надежда лишь на новый редактор, Gutenberg, который в этом году должен заменить TinyMCE. Там все на реакте, контент редактируется именно блоками, и каждый блок может иметь свой темплейт. По идее, это должно решить эту проблему раз и навсегда.

Это называется FOUC – Flash Of Unstyled Content. Происходит он потому что у вас невалидный и кривой HTML, менюшка ваша выводится в HEAD (где ее быть не может по определению, только в BODY), и до CSS. Отсюда и проблема – сначала браузер выплевывает HTML-разметку, а потом спохватывается, что вот еще стили есть, берет их и перерисовывает страницу.

И да, счетчики эти всякие и прочие говноскрипты смело ставьте в футер, а еще лучше асинхронно и с задержкой. Раньше их выполнять не стоит.

zorca в комментах написал уже, public_html из путей уберите

через backgrond-image нельзя же, потому что не вписать <?php the_post_thumbnail(); ?> в свойствах css, и position: absolute нельзя использовать

Можно, просто вместо функции the_post_thumbnail(), которая выводит html-код изображения (то есть весть тег IMG), используйте функцию the_post_thumbnail_url(), которая выводит только URL картинки:

<div class="post-head" style="background: url( <?php the_post_thumbnail_url(); ?> );">
    <h1><?php the_title(); ?></h1>
</div>

Ну а через класс .post-head уже дополнительные стили вешаете.

зачем нужна сетка для верстки

Сетка нужна для удобства и консистентности верстки.

будь то бутстрап или грид

Бутстрап это большой фреймворк, сетка - лишь маленькая его часть. А грид - это и есть "сетка". С терминологией надо бы порядок навести.

если я все равно в контейнере отступаю в пкс от краев, задаю ширину в стилях и помещаю все в контейнер, а для телефонов оптимизирую через медиа запросы

Поздравляю, вы создаете и используете собственную сетку! :) Исходя из этого, решите для себя сами - достаточно ли вам вашей собственной сетки, удобно ли с ней работать. Если да - тогда сторонние готовые решения вам не нужны. Если нет - тогда используйте готовую сетку и не парьтесь.

не знаю какие требования у них к шаблонам (на их сайте нет).

Серьезно?

https://help.market.envato.com/hc/en-us/articles/2...
https://help.market.envato.com/hc/en-us/articles/2...
https://help.market.envato.com/hc/en-us/articles/2...

Бекенд у вас весьма шустрый:



Это весьма и весьма достойный результат. С сервером и на серверной стороне все в порядке. А теперь узкие места:

1. Загрузка шрифтов с серверов Google. С вашим шустрым сервером имеет смысл шрифты стянуть себе и отдавать локально. Срежете секунды полторы:



2. Далее, есть проблема с несколькими стилями:

vcare.uz/wp-content/plugins/js_composer/assets/lib...
vcare.uz/wp-content/plugins/js_composer/assets/lib...
vcare.uz/wp-content/plugins/js_composer/assets/lib...

Они долго грузятся, можете сами в Developer Tools посмотреть. Проблема не только в том, что они долго грузятся, но и в том, что они встают в очередь так как расположены в подвале и из-за использования HTTP/1.1. Можно решить 2мя путями:

- конкатенация в один файл
- использование HTTP/2

В идеале, можно искать баланс между HTTP/2 + выборочная конкатенация.

3. Файлы

- new.vcare.uz/wp-content/uploads/2017/08/header-1.j...
- new.vcare.uz/wp-content/uploads/2017/08/bg-white22...

С ними 2 проблемы:

- грузится с поддомена (+ DNS lookup и прочие потери на новый коннект)
- динамический параметр, который предотвращает кеширование файла на стороне клиента

Перенесите файл на основной домен и уберите параметр.

4. Contact Form 7



У вас 7 (!!!) аякс-запросов этот плагин генерит. Я так понимаю, это 7 разных форм на странице. Запросы запускаются достаточно рано в цикле жизни страницы, и блокируют других ресурсов, занимая соединения с сервером. По протоколу HTTP/1.1, насколько я помню, браузер открывает до 6 соединений с сервером. В вашем случае, часть из этих 6 к моменту вызова этих ajax-запросов уже занята, и они встают в очередь друг за другом, вместе с другими ресурсами. Это умножает время ожидания. Переход на HTTP/2 заметно снизит влияние, но желательно избавиться от них вообще. Я бы советовал заменить CF7 на более адекватный плагин. Попробуйте, к примеру, Torro Forms (толковый и бесплатный, еще и с нормальным интерфейсом).

5. Еще один запрос к admin-ajax.php



Собственно, он инициирован Visual Composer'ом - это Masonry сетка. Возможно, он у меня дозапустился потому что я начал скролить страницу и докрутил до того места, где он нужен. Возможно, он не запускается по умолчанию и проблемой не является.

6. Front-end performance (парсинг и рендеринг):



Парсинг скриптов занимает много времени, ибо их много. Но от этого можно избавиться только путем уменьшения их количества, что, возможно, не вариант. А вот второй очень тревожный сигнал - это как раз время ожидания (Idle). Это как раз говорит о невозможности браузера продолжать работу на каких-то этапах из-за того, что он ждет пока прилетят запрошенные ресурсы. Переход на HTTP/2 крайне желателен + замена CF7. Это как раз тот случай, когда HTTP/2 должен дать ощутимый эффект.

Ну это так, беглый анализ. Посмотрите результаты тестирования тут: https://tools.pingdom.com/#!/2GQ2d/http://vcare.uz/