Как вы оптимизируете скорость загрузки сайтов на WordPress?

Это все не сильно поможет топикстартеру, потому что у него TTFB 2 секунды. А это - говнокод и куча тяжелых говноплагинов.

У меня тоже было 2 сек до установки и настройки кэша. Однако согласен - плагины нужно тщательно подбирать, и это еще один путь оптимизации.

Игорь Воротнёв: плагин кэширования как раз очень сильно и поможет

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

Вася Петров: я пытался доказать, что сайт нужно переносить на VPS. Но... Вот и приходится городить костыли за костылями.

Max Medar ВПС совсем не обязательно. А если нет админа, то и не желательно. Лучше нормальный шаред. От не заевшегося хостера, а никак не от регистраторов. Никакие не регру, никру и тп не годятся.

Дмитрий: почитайте коммент Вася Петров выше. Вы не совсем правильно себе представляете работу плагинов кеширования. И кеширования вообще. А еще возможности хостинга реализовать разные методы кеширования, доступные в плагине. В общем, все не так просто. Кеширование само по себе - крайняя мера, а не лекарство на все случаи жизни, и должно быть грамотно реализовано на многих уровнях. Кеширование страниц целиком - вообще крайняя мера, которая подходит лишь для статических данных. Да и в этом случае, сильно разумнее (и быстрее) реализовывать это не плагином кеширования, а средствами сервера. Из моей практики (и практики коллег занимающихся high-load проектами), самое производительное и быстрое решение - nginx fastcgi_cache в памяти. Вкратце можете посмотреть тут: https://www.scalescale.com/tips/nginx/configure-ng... Впрочем, это не отменяет необходимость оптимизировать приложение само по себе, чтобы оно работало быстро и без кеша. Потому что кеш нужно инвалидировать и праймить. Динамика никуда не девается даже при использовании полного кеширования. Кроме того, в случае топикстартера, проблема 100% еще более ощутима в админке, а там кешировать особо нечего.

Игорь Воротнёв:
>Вы не совсем правильно себе представляете работу плагинов кеширования
забавно)
Вообще, я своим клиентам услугу поднять результаты в тесте гугла до 100/100 продвигаю. И вполне успешно.
Интересно б было узнать, в каком именно месте я неправильно представляю работу плагинов?)

У него TTFB 2 секунды. Значит ему нужно либо переписывать тему/плагины, либо покупать дорогой сервер (причем, не факт, что это поможет), либо кэшировать все в статику и отдавать статику.

Перегнать все в статику плагином - самое простое. Работает на любом хостинге.
Да, кэшировать средствами сервера, всякие там varnish, nginx и тп, - круче и эффективнее. Но основная масса клиентов такое себе позволить не может.
Работать надо не с сферическим high-load, а с тем, что есть у заказчика).

Ну и, к вопросу топик стартера.
Сделать асинхронную загрузку css можно. Самое простое, использовать плагин. В гугле по 'wordpress css async' они есть.
например
https://ru.wordpress.org/plugins/wp-async-css/
Я такими не пользуюсь, своим кодом инлайню кусок critical css в шапку, а все остальные css гружу только после загрузки страницы. Но делать так советовать не буду, тк это сложнее

Дмитрий:
> я своим клиентам услугу поднять результаты в тесте гугла до 100/100 продвигаю
Я тоже когда-то это делал. И да, это реально делать средствами плагинов. Но это синтетические числа, далекие от реальности. И это скорее выполнение заведомо известного и понятного списка требований гугла (при чем в основном по фронтенду, то есть клиентской части), а не реальное ускорение. Да, ускорение происходит, но далеко не в тех масштабах, какие возможны. Впрочем, есть требования, которые плохо дружат с требованиями отдела маркетинга, например - аналитика, трекинг и прочие плюшки, необходимые бизнесу, и так нелюбимые тем же гуглом - именно они зачастую и не позволяют получить эти 100 из 100. Хотя даже этими плюшками и результатами 86/100 сайт может быть фантастически быстрым. Потому что учитывать в первую очередь надо perceived speed, а не числа. Собственно, асинхронность - это и об этом в том числе. Речь здесь в первую очередь о бекенде, который совершенно никак не тестируется и не отражается в данном тесте от гугла.

> У него TTFB 2 секунды. Значит ему нужно либо переписывать тему/плагины,
Об этом я и говорю.

> либо покупать дорогой сервер (причем, не факт, что это поможет)
Верно, не факт что поможет.

> либо кэшировать все в статику и отдавать статику.
Вот именно поэтому я и говорю, что вы слишком просто, "в лоб" воспринимаете кеширование. Кеширование в статику часто бывает либо невозможно, либо непрактично. И оно лишь маскирует проблему, а не решает ее. Кроме того, кеширование в статику, как я уже говорил, неприменимо в админке, а если фронт с TTFB 2 секунды, то в админке там скорее всего в разы больше.

> Перегнать все в статику плагином - самое простое. Работает на любом хостинге.
Самое простое не всегда самое оптимальное и самое разумное. Опять же, есть вариации - хранить на диске? На хостинге возможно упретесь в лимит IOPS или файловых дескрипторов. Запросы будут вставать в очередь на уровне файловой подсистемы, и вместо выигрыша получите то же самое или даже медленнее (пример из реальной практики). Хранить в памяти? Шаред не предоставляет такой возможности. Хранить на диске и отдавать чисто веб-сервером без PHP? Или все-таки поднимать PHP и на максимально раннем этапе возвращать статику вместо поднятия всего WP? И то и другое - вариант, реализовано во многих плагинах. Результаты разные. Сильно разные.

> Сделать асинхронную загрузку css можно
Конечно можно. Но можно получить неприятные FOUC. И TTFB в 2 секунды асинхронная загрузка стилей не решит. От слова совсем.

Глобально я к тому веду, что использование плагинов кеширования в надежде вылечить тормоза - это очень грубые полумеры и попытки замаскировать симптомы, а не вылечить болезнь. Базовая логика такая:

- оптимизация кода
- оптимизация запросов к БД
- кеш запросов
- объектный кеш
- фрагментный кеш
- статику

То есть, в первую очередь оптимизируется динамика на всех уровнях. А кеш в статику (да, в идеале в память и на уровне сервера) - это вишенка на торте. Которая позволяет не столько ускорить уже ускоренное, сколько увеличить RPS и эффективность использования ресурсов сервера. Грубо говоря, без статики оптимизированный сайт на этом конкретном сервере будет обрабатывать (быстро!) 500 запросов в секунду, а с включеным full page cache в памяти на уровне Nginx этот показатель вырастет до 10 тысяч. Но при этом все некешируемые запросы - в админку, для авторизованных пользователей (личные кабинеты), корзина-оплата и подобный функционал будут все равно летать очень быстро.

Коллеги, мы уклонились от темы. Речь ведь идет о применимости тех или иных методов в конкретных условиях конкретного человека. ИМХО ему нужно выиграть время, т.е. "заткнуть" сейчас. Если у него появится ресурс, то он получит возможность оптимизации кода и т.д. Или сделать сайт заново с учетом всего вышесказанного.

Игорь Воротнёв: повторюсь, работать надо с тем, что есть у клиента, или с тем, что действительно он может сделать.

Вот что, из вышеперечисленного он осилит самостоятельно сделать качественно?
На мой взгляд, если он задает такие вопросы, то только поменять хостинг или поставить плагин.
Из опыта, некоторые заказчики пробуют самостоятельно ставить плагины кэширования. Выбирают тот же W3TC, но настроить его не могут. В таком случае, советую им ставить WP Super Cache, он значительно проще в настройке.

Я не знаю, что у него за сайт. в каждом конкретном случае стратегия оптимизации может быть разной. может у него там вообще на init висит какой-нить wp_remote_get и погоду каждый раз проверяет? Но в 95% случаев плагин кэширования поможет поднять TTFB без изменения логики работы сайта.

>Я тоже когда-то это делал. И да, это реально делать средствами плагинов
не соглашусь. живой сайт средствами плагинов до 100/100 догнать проблематично. обычно приходится код руками под конкретный сайт писать.
>отому что учитывать в первую очередь надо perceived speed, а не числа.
тоже не согласен, но к теме вопроса это уже не относится.

Игорь Воротнёв, "В общем, все не так просто. Кеширование само по себе - крайняя мера,"
+100500! Кеширование само по себе - палка о двух концах. А реализованное на пхп - ужасный костыль.

Коллеги, а особенно привыкшие затыкать дыры кеш-плагинами (и плагинам безопасности - ещё одно зло) наверняка ж вы слышали про серверное кеширование? Но наверно не достаточно уделили этому вопросу внимание, уж коль плагинами лечите системные болезни. Стоит изучить о типах кеширования и методах оного. Что для чего и когда применяется.

А знаете ли вы, что у ВП на уровне ядра есть несколько видов кеша? Прочитайте и про это. Кто-то из Ковшениних писал достаточно доходчивый материал. И на wp.tv в нескольких докладах об этом упоминалось.

И вообще кеширование средствами php (плагины, да) - это лошадь, запряженная в феррари. Вместо того, чтобы заправить и жать педали автомобиля - запрягаем в неё лошадь и дышим выхлопами из-под её хвоста.

Дмитрий:
> повторюсь, работать надо с тем, что есть у клиента, или с тем, что действительно он может сделать.

Не соглашусь. Клиенту необходимо предоставить аудит и варианты. Самый быстрый, дешевый и простой - пойти этим путем. Но мы, как специалисты, должны этот вариант снабдить хотя бы минимальными за/против и предложить альтернативные пути.

Приведу аналогию. У человека болит голова. А врач ему говорит - бахните анальгинчик, и все норм. Копеечная таблетка. Но боль со временем возвращается. Иногда даже становится сильнее и в конце концов может привести в некоторых случаях в летальному исходу. Адекватный врач отправит сдавать анализы (проводить аудит) и по результатам анализов будет настаивать на лечении проблемы, вызывающей эту боль, а не предлагать копеечное, выгодное и удобное на первый взгляд решение, которое по сути является временным устранением симптома.

> Вот что, из вышеперечисленного он осилит самостоятельно сделать качественно?

Он и не должен делать это самостоятельно, а должен понимать масштаб проблемы и обратиться к специалисту.

> может у него там вообще на init висит какой-нить wp_remote_get и погоду каждый раз проверяет?

Совершенно разумная мысль. Поэтому я и настаиваю на аудите, профилировании. Есть вероятность что можно решить проблему без какого-либо кеширования вообще, удалив условную "раковую опухоль" (вылечив болезнь, а не симптом). У меня когда-то был случай с TTFB по 5-6 секунд, который иногда поднимался до 30 секунд и складывал все по таймауту. Оказалось, что из-за бага в каком-то плагине, у клиента висели около 30 тысяч (!!!) cron-задач с разными интервалами, и когда система пыталась все это поднять-выполнить - все падало. Устранение этого бага и сокращение задач до реальных ~20 решило проблему раз и навсегда. Если бы клиент просто поставил плагин кеширования - он бы получил видимость результата, но падения продолжились бы - реже при прайме кеша, и все так же регулярно при работе в админке.

> Но в 95% случаев плагин кэширования поможет поднять TTFB без изменения логики работы сайта.

Нет, в 90% случаев плагин кеширования создаст видимость решения проблемы.

> не соглашусь. живой сайт средствами плагинов до 100/100 догнать проблематично. обычно приходится код руками под конкретный сайт писать.

Я имел в виду и кастомные плагины тоже. На GitHub можно нарыть огромное количество готовых решений в виде плагинов, о которых мало кто знает. Свои наработки, которые можно портировать от проекта к проекту - тоже в виде плагинов.

> Потому что учитывать в первую очередь надо perceived speed, а не числа.
> тоже не согласен, но к теме вопроса это уже не относится.

Числа - это синтетические данные. К примеру, я обслуживаю один крупный проект, у которого perceived загрузка в пределах 200-300мс, хотя реальная fully loaded не наступает по тестам вообще, ибо там кроме асинхронных вещей еще есть сокеты и ежесекундно обновляемые данные. Цифры из теста скажут вам, что страница грузится более 60 секунд (таймаут теста), что не является правдой. Все эти тесты и числа - только как ориентир для разработчика, а не для клиента. Для оценки. И надо понимать их не буквально, а в контексте конкретных решений.

Вася Петров: неистово плюсую :)

Игорь Воротнёв: Вася Петров: господа плюсующие, вы не забывайте, что мы в реальном мире живем. И решать нужно реальные проблемы.

Да, все так, все именно как вы пишите, делать и нужно. Но на сколько это сделает разработку и поддержку дороже и дольше? И, да, клиент сам не должен в коде копаться, все должны делать специально обученные люди. Но в жизни так не бывает. Этот вопрос - яркий пример. Пользователь не умеет, но проблему решить ему нужно и делать это он будет сам.

>Коллеги, а особенно привыкшие затыкать дыры кеш-плагинами (и плагинам безопасности - ещё одно зло) наверняка ж вы слышали про серверное кеширование?
Почитайте внимательнее мои комментарии выше?

>Клиенту необходимо предоставить аудит и варианты.
Ну и 90% клиентов выберет установку плагина, так как это дешевле на порядок.
Вон, мой текущий клиент - у него свой сервер, на нем WordPress Multisite. Полный доступ к всем настройкам, можно сервер как угодно крутить. Объяснил, оценил, что сколько займет, что и почему лучше/хуже. В итоге - плагин, небольшие правки кода, чистка базы. Потому как это дешевле.

>Приведу аналогию. У человека болит голова
О, я тоже аналогии люблю приводить. Тут уместнее будет такая:
Ребенок получил двойку, привели к психологу, спрашивают, что делать. Он советует этого выкинуть, сделать нового и его воспитать по его программе. Тогда будут только пятерки.
Хотя достаточно б было дать ремня или лишить компьютера на неделю - дешевле, быстрее, и будет работать в основной массе случаев не хуже.

>Нет, в 90% случаев плагин кеширования создаст видимость решения проблемы.
Это как?) Сайт работает, но удовольствие не приносит?)
Да, код внутри останется такой же фиговый (но у заказчика нет денег/времени на профилирование). Да, будут проблемы при перестройке кэша (хотя некоторые плагины умеют перестраивать кэш в фоне) и будет у администратора страница напрямую грузится.
Но за счет кэширования и раздачи статики основной массе пользователей мы снижаем нагрузку на хостинг. И вполне может быть ситуация, что освободившихся ресурсов хватит для обслуживания одного единственного администратора.

>Все эти тесты и числа - только как ориентир для разработчика
Тот же тест гугла вполне нагляден и понятен для не-разработчика. Доводить до 100/100 действительно может в некоторых случаях быть не оправданно.
Но как еще простому пользователю понять, что у него сайт действительно стал грузится быстрее? На глаз?) perceived может быть очень perceived и варьироваться в широких пределах в зависимости от настроения пользователя, скорости его интернета, наличия на компьютера торрентов и прочего.

>К примеру, я обслуживаю один крупный проект
Вот я про что и говорю. Надо быть ближе к народу. То, что оправданно для больших проектов, мелким может быть вообще не по карману.
А то, посмотрел другие советы. Пишут то все в теории правильное, но на практике такую хрень)

"Отказ от вижуал компзеров они - зло" - ну да, зло. Но человек только только выложил деньги, чтоб ему на таком композере сайт собрали, а теперь надо платить, чтоб ему его по другому, без композера, пересобрали?
Сколько будет стоить разработка сайта с точно таким же функционалом, но без такого плагина? Чтоб можно было легко все в админке самому править и блоки перетягивать?

"HTTPS - зло" - с хрена ли?
Ну да, сайт по https будет помедленнее. Но это жеж один из факторов ранжирования в поисковиках. Или это, типо, чтоб он был ниже в выдаче, по нему меньше пользователей ходило, поэтому меньше нагрузка на сервер и он быстрее работает?)

"полный рефакторинг кода" - спасибо, капитан) кто это оплатит?
и прочие, безусловно, полезные советы.

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

Дмитрий:
> господа плюсующие, вы не забывайте, что мы в реальном мире живем. И решать нужно реальные проблемы.

Именно. Решать проблемы, а не затыкать дырки, вызванные этими проблемами.

> Но на сколько это сделает разработку и поддержку дороже и дольше?

Short term или long term? Это ключевой момент.

> Но в жизни так не бывает.

Еще как бывает. Сплошь и рядом, к счастью.

> Этот вопрос - яркий пример. Пользователь не умеет, но проблему решить ему нужно и делать это он будет сам.

И такое бывает. К сожалению, тоже сплошь и рядом. Но это совершенно не означает что это нужно принимать как норму и всячески это поддерживать. Мы, как разработчики / более опытные разработчики должны обучать клиента и менее опытных разработчиков-новичков. Говнокод - не выход. Никогда.

> Ну и 90% клиентов выберет установку плагина, так как это дешевле на порядок.

Смотря как вы это аргументируете. Это раз. Два - не надо пугаться рефакторинга. Очень часто минимальные изменения за разумные деньги решают критические узкие места. Время/стоимость такая как за настройку плагина, а результат совершенно другой. И всегда считайте клиенту не только сиюминутную стоимость конкретного фикса, дайте ему увидеть long-term последствия.

> В итоге - плагин, небольшие правки кода, чистка базы. Потому как это дешевле.

Но все же есть небольшие правки - это уже рефакторинг. Значит проводился минимальный аудит. Это как раз то, о чем я говорю. А то, что конкретно в этом случае поставить плагин оказалось выгоднее - либо от недостатка понимания клиентом долгосрочных нюансов, либо ему их попросту не озвучили. Ну или банальная сверхэкономность или просто отсутсвия денег - тоже бывает, ок. Значит в этом случае берем плагин. Но клиенту все же озвучиваем все варианты.

> О, я тоже аналогии люблю приводить. Тут уместнее будет такая:

Совершенно неуместная и неприменима. Вы перекручиваете понятия.

> Это как?) Сайт работает, но удовольствие не приносит?)

Нет, это так, что проблема как была, так и осталась. Вы лишь припрятали ее немножко, но не полностью. Она не так сильно лезет в глаза как раньше, но все равно лезет. А если сайт растет и меняется, со временем проблема накапливается, разрастается и приводит к тому, что никакой рефакторинг уже не поможет, необходимо действительно "этого выбросить и сделать нового" - у меня как раз сейчас такой проект. Сделали клиенту аудит и прозрели все, включая его самого. Год угробил на сайт, 3 команды сменил и пару фрилансеров которые "фиксили симптомы". Кучу денег угробил. И дошел до момента, когда все эти "фиксеры" разводят руками и говорят что прикрутить новую фичу Х не представляется возможным - потому что все нахрен развалится. Теперь клиент платит на порядок больше и делает все с нуля. Потому что long term (см. выше).

> освободившихся ресурсов хватит для обслуживания одного единственного администратора

Администраторов, редакторов и авторов может быть много. И даже если он один - он может в админке проводить достаточно много времени, ежедневно. И загрузка страниц по пару секунд - это ад.

> Но как еще простому пользователю понять, что у него сайт действительно стал грузится быстрее? На глаз?)

Вы удивитесь, но да - можно и на глаз. Если ни у кого не возникает мысли что сайт медленно работает, или еще лучше - все реально замечают что сайт работает быстро (читай - быстрее чем остальные сайты которыми они пользуются ежедневно) - значит все ок. Для любителей циферок в google analytics можно отслеживать время загрузки. И там можно как раз детально отслеживать и TTFB, при желании. И потом графики красивые клиенту строить. А если сайт "на глаз", по ощущениям подтормаживает и бесит пользователей - какая разница что там за циферки? Я знаю сайты 90+/100, которые тормозят. Именно субъективно тормозят. Как пользователю, ими пользоваться некомфортно.

> Вот я про что и говорю. Надо быть ближе к народу. То, что оправданно для больших проектов, мелким может быть вообще не по карману.

Не стоит сразу со старта пугаться рефакторинга, профилирования и отладки. Часто можно с помощью WP-CLI за пару минут отловить медленные куски, посмотреть код и найти узкие места. Устранение / переписывание может занять от получаса до пары часов, не обязательно должно быть перелопачивание всего сайта с нуля в течение пары месяцев за кучу килобаксов. У меня были случаи (неоднократные) рефакторинга мелких кусков на небольших проектах, которые давали колоссальный результат. Один из примеров с задачами на кроне я приводил выше. Времени ушло меньше, чем уйдет на настройку W3TC.

Вижуал композер таки зло, да. Но если он есть - с ним тоже можно грамотно работать. А можно говнокодить и вместе с ним. Дело не в инструменте, а в том, как он используется.

HTTPS - отнюдь не зло. В паре с HTTP/2 - совсем не медленнее, наоборот.

Полный рефакторинг кода никто не делает. Если рефакторить надо больше половины - дешевле писать с нуля.

> Единственная проблема, про которую известно точно - долго отдает первый байт.

То есть, проблема точно на уровне кода.

> единственное, что может решить проблему с такими вводными - установить плагин кэширования.

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

Игорь Воротнёв:
>Short term или long term? Это ключевой момент.
Да что ж вы такой упертый)
Отвлекитесь от нормальных проектов, от крупных сайтов и прочего подобного.
Основная масса сайтов - это "сайты за 5 тысяч" (ну или за $300, если для иностранцев). Где скачали шаблон, через композер накидали блоков, понатыкали плагинов и пустили туда пользователей. Все.
К чему на такой проект настраивать кэширование на стороне сервера через, к примеру, varnish?

>Время/стоимость такая как за настройку плагина
Поставить и включить WP Super Cache - дело 5-10 минут. И дальше оно тупо работает.
Найти узкое место, исправить, протестировать, и все за 10 минут - это насколько реально?

>Во-первых, как я уже устал пытаться донести, проблему это не решит, а только замаскирует частично
Есть лишние деньги перелопатить код, купить сервер, нанять человека его админить - вперед, никто не запрещает.
Вы попробуйте свой бизнес вести? Замечательно отбивает излишнюю тягу к перфекционизму.

И, ак я уже устал пытаться донести (с), попробуйте быть ближе к народу?)
Возьмем любой сайт-визитку на WordPress, скажем цветы продают. С говняной темой, лажевым хостингом и зоопарком плагинов.
И перед праздником собираются устроить рекламу, планируется наплыв посетителей на сайт и тд и тп, а он грузится почему-то долго. Ну или заказал продвижение у сеошников, а те ему порекомендовали хоть как-то повысить скорость загрузки сайта.
И че клиент будет делать по вашим советам?

Мелкому бизнесу, нафик не нужен красивый код (ну, вернее, он им нужен, но они не готовы за него адекватно платить), поэтому вполне устроит чтоб хоть как-то, но работало. Поэтому и WordPress так распространен, при всех его недостатках.
Выгоднее заплатить сейчас копейки за настройку плагина, оставшиеся деньги вбухать в рекламу, а потом целый год на сайт вообще не заходить. Какой ему longterm?

Дмитрий всё верно, затыкайте дыры по-быстрячку. Пока вы такие зашибаете копейку я никогда не останусь без рубля :)

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

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

Кстати, Вася Петров, почему https - зло? Не получилось сертификат подключить?)

см выше. Как вы оптимизируете скорость загрузки сайтов на WordPress?

Вася Петров: вопрос про https снимаю.
Почитал ваши комментарии тут к совету чуть выше. Сразу не заметил.

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

Дмитрий:
Святая Вера в Непогрешимость и Истиность W3 Total Cache, WP Super Cache и прочих Рокет кэшев, а так же в 100/100 гугло цифирь при помойке под капотом, и делает WP объектом насмешек. А Вера это благодаря ее Адептам, к которым, как я посмотрю относитесь и вы охватывает 99% пользователей.
Спасибо Бложекам, И Великим Мастерам из категории Сайт за Жувачку.

По моему, рядом с "Заводом по Сжиганию Фотографов" надо построить парочку для Сжигания WordPress Экспертов, на торжественном открытии можно утилизовать Евгения Попова(R)

WP Panda: объектом насмешек WP делают упоротые адепты, полностью согласен.
Вас так сильно задело, что я раскритиковал ваше высказывание про зло вижуал компзеров, что вы обращаете внимание только на то, что вам интересно, остальные куски комментариев упускаете?

Где я писал, что установка плагина - идеальное решение? И с чего вы взяли, что 100/100 в гугле - это обязательно?

Дмитрий:

Вас так сильно задело, что я раскритиковал ваше высказывание про зло вижуал компзеров, что вы обращаете внимание только на то, что вам интересно

Не надо думать за меня, мне глубоко плевать, что и кто думает о вижуал композерах. Меня интересует только мое мнение, оно же по счастливому совпадению единственное правильное, и аксиома.

Где я писал, что установка плагина - идеальное решение?

Везде, перечитайте свою писанину

И с чего вы взяли, что 100/100 в гугле - это обязательно?

Опять же не надо приписывать мне такое, я такого не писал.

А вот вы да

Вообще, я своим клиентам услугу поднять результаты в тесте гугла до 100/100 продвигаю.

WP Panda:
>только мое мнение, оно же по счастливому совпадению единственное правильное
ну, про упоротость, не я первый начал, да?)

>Везде, перечитайте свою писанину
Прикрепите, пожалуйста, цитату? Оптимально, да, писал. По соотношению цена/качество/время.

>Опять же не надо приписывать мне такое, я такого не писал.
ну ок, вы писали "Непогрешимость и Истиность ... 100/100 гугло цифирь".
На мой взгляд, советы теста гугла вполне адекватны и корректное следование этим советам сайт ускорит. Если у сайта результаты были в красной зоне, после оптимизации поднялись до зеленой, результат работы часто виден будет даже на глаз (хоть такой способ тестирования сайтов я бы не рекомендовал)).
Ну и, не стоит забывать, что даже если б эти тесты показывали полную фигню, то это один из факторов ранжирования. На мой взгляд, оправданно потерять 200-300ms в скорости и получить более высокую позицию в выдаче.

>А вот вы да
Ну да, писал такое. И да, предлагаю поднять до 100.
Но я же и вот такое писал "доводить до 100/100 действительно может в некоторых случаях быть не оправданно".

Дмитрий: Нет у меня ни желания, ни времени ни спорить с вами, ни чего-то доказывать. Живите как умеете, плодите и размножайте свои сайты за 5 тысяч, доказывайте, что 2х2 = 8, в общем успехов и процветания.

WP Panda: то есть, время и желание прийти, рассказать про "Святую Веру в Непогрешимость и Истиность", про "Сайт за Жувачку" и тп, найти получилось, а как что-то техническое обосновать нужно, так сразу нет?

Но таки да, думаю, стоит дискуссию как-то закруглить или продолжить позже, после завершения весеннего обострения. А то у одних https - зло, у других "Завод по Сжиганию") Вообще не по теме топика.

Спасибо, видео доклада выглядит отлично!