Дмитрий:
> повторюсь, работать надо с тем, что есть у клиента, или с тем, что действительно он может сделать.
Не соглашусь. Клиенту необходимо предоставить аудит и варианты. Самый быстрый, дешевый и простой - пойти этим путем. Но мы, как специалисты, должны этот вариант снабдить хотя бы минимальными за/против и предложить альтернативные пути.
Приведу аналогию. У человека болит голова. А врач ему говорит - бахните анальгинчик, и все норм. Копеечная таблетка. Но боль со временем возвращается. Иногда даже становится сильнее и в конце концов может привести в некоторых случаях в летальному исходу. Адекватный врач отправит сдавать анализы (проводить аудит) и по результатам анализов будет настаивать на лечении проблемы, вызывающей эту боль, а не предлагать копеечное, выгодное и удобное на первый взгляд решение, которое по сути является временным устранением симптома.
> Вот что, из вышеперечисленного он осилит самостоятельно сделать качественно?
Он и не должен делать это самостоятельно, а должен понимать масштаб проблемы и обратиться к специалисту.
> может у него там вообще на 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 секунд (таймаут теста), что не является правдой. Все эти тесты и числа - только как ориентир для разработчика, а не для клиента. Для оценки. И надо понимать их не буквально, а в контексте конкретных решений.
Дмитрий:
> я своим клиентам услугу поднять результаты в тесте гугла до 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 тысяч. Но при этом все некешируемые запросы - в админку, для авторизованных пользователей (личные кабинеты), корзина-оплата и подобный функционал будут все равно летать очень быстро.
Дмитрий: почитайте коммент Вася Петров выше. Вы не совсем правильно себе представляете работу плагинов кеширования. И кеширования вообще. А еще возможности хостинга реализовать разные методы кеширования, доступные в плагине. В общем, все не так просто. Кеширование само по себе - крайняя мера, а не лекарство на все случаи жизни, и должно быть грамотно реализовано на многих уровнях. Кеширование страниц целиком - вообще крайняя мера, которая подходит лишь для статических данных. Да и в этом случае, сильно разумнее (и быстрее) реализовывать это не плагином кеширования, а средствами сервера. Из моей практики (и практики коллег занимающихся high-load проектами), самое производительное и быстрое решение - nginx fastcgi_cache в памяти. Вкратце можете посмотреть тут: https://www.scalescale.com/tips/nginx/configure-ng... Впрочем, это не отменяет необходимость оптимизировать приложение само по себе, чтобы оно работало быстро и без кеша. Потому что кеш нужно инвалидировать и праймить. Динамика никуда не девается даже при использовании полного кеширования. Кроме того, в случае топикстартера, проблема 100% еще более ощутима в админке, а там кешировать особо нечего.
sim3x:
> два разных на одной бумаге = 1
> Юристы, устно, для упрощения, могут ето назвать НДА
Ну это крайняя безграмотность юриста, указываешь ему на это все. Это два разных договора. NDA по своей сути не может включать отказ от конкуренции. Мухи отдельно, котлеты отдельно. Просто говоришь, что мой юрист категорически не согласен с такой формулировкой и даешь ссылку на википедию, пусть почитает что такое NCA.
> За отказ от конкуренции клиент должен сверху прилично отслюнявить
> Я об етом и пишу
С этим я и не спорю, а всячески поддерживаю.
sim3x: И еще. NDA - это вполне обычная и нормальная практика, по сути он ограничивает вас только в том, чтобы вы не растрепали "секреты фирмы". NCA - это достаточно жесткое ограничение для вас как специалиста (или компании, как бизнеса), которое ведет к неизбежной потенциальной потере прибыли, поэтому NCA как правило включает компенсацию. Грубо говоря, если клиент просто требует NCA - он посылается в пешее путешествие. За отказ от конкуренции клиент должен сверху прилично отслюнявить, чтобы мы в эту нишу больше не лезли. И еще - отказ от конкуренции практически не бывает вечным. Он "покупается" на некоторое время, например 1-2 года. Это время дает возможность клиенту выжать из нового рынка максимум и откусить долю, а потому уже и конкуренты подтянутся.
sim3x: Это совершенно разные документы сами по себе, и они никак не пересекаются. Да, вам могут подсунуть один общий документ, в котором будет и NDA, и NCA, и еще что угодно, но хоть это будет один документ по форме, это будут все те же отдельные документы по сути / содержанию. Это как договор на разработку сайта и договор на установку и настройку серверного оборудования. По сути - два совершенно разных, независимых друг от друга договора. Но если подрядчик один, и оба договора в рамках одного проекта, юристы могут извратиться и оформить это в один цельный документ. Но это все равно два разных договора по сути, с разными условиями и предметом договора.
Максим Корольский: "Деньги не приходили" - это не ответ. Это и без их "ответа" понятно, потому что на счету у тебя их нет. С данными свифт-перевода они могут видеть ВСЮ цепочку событий внутри систем. Поступление платежа от Скрилл в систему СВИФТ, потом путь до банка-корреспондента, потом до твоего банка. И на каждом шагу есть свои статусы и тд - по ним можно четко видеть где деньги и почему не пришли.
Максим Корольский: Странно. Во-первых - есть ли слип/данные сфит-перевода? Если да - звоните в свой банк и просите проверить платеж, они это могут. Во-вторых - месяц это бредово долго. По регламенту кажется максимум 7 банковских дней, если произошла какая-то ошибка или счет не найден / не смог принять - в течение 3 дней деньги возвращаются отправителю - так работает банковская система по всему миру, и Скрилл тут ничем отличиться не может.
sim3x: не путайте NDA - Non-Disclosure Agreement (неразглашение) с NCA - Non-Compete Agreement (отказом от конкуренции, иногда это NCC, CNC). Это два совершенно разных документа. Бегло можете изучить тут: https://www.legalnature.com/article-center/human-r...
Все правильно, только template_redirect не стоит трогать, он не для этих целей. Используйте init, он как раз идет сразу после установки текущего пользователя.
Златослав Десятников:
1. Это Yoda Conditions
2. Они являются частью Coding Standards в экосистеме WordPress и Symfony.
3. Использовать или нет - решать вам, если пишете код под упомянутые экосистемы, и код который будут использовать / модифицировать другие люди из этих экосистем, тогда используйте. А со временем привыкаете.
nweb: да при чем тут верстать в CMS, верстается все в нормальных редакторах/IDE. Но для верстки под WP (и многие другие CMS/CMF) есть своя специфика, и вот тут ваши эти jade ну никак не катят. Если верстальщик делает мне статический html из которого я потом сам шаблоны для WP буду собирать - мне нужен чистый и аккуратный html, собранный вместе, а не кусками. Если же верстальщик сам работает с уже динамичным контентом и шаблонами под WP, то там свой шаблонизатор используется, на PHP.
AlikDex: Дело не в 1 странице, а в подходе и методе принятия стратегически важных решений. Проект обречен, вопрос исключительно во времени - рано или позже.
AlikDex: ну, речь в данном топике о достаточно крупном, и вероятно, немножко high-load проекте. Если в крупном проекте разрабы задают такие вопросы и/или отсутствует человек, который принимает обдуманно такие решения (учитывая UX, оптимизацию и тд) и спускает их безголовым разрабам - проект обречен. Вот и все.
> повторюсь, работать надо с тем, что есть у клиента, или с тем, что действительно он может сделать.
Не соглашусь. Клиенту необходимо предоставить аудит и варианты. Самый быстрый, дешевый и простой - пойти этим путем. Но мы, как специалисты, должны этот вариант снабдить хотя бы минимальными за/против и предложить альтернативные пути.
Приведу аналогию. У человека болит голова. А врач ему говорит - бахните анальгинчик, и все норм. Копеечная таблетка. Но боль со временем возвращается. Иногда даже становится сильнее и в конце концов может привести в некоторых случаях в летальному исходу. Адекватный врач отправит сдавать анализы (проводить аудит) и по результатам анализов будет настаивать на лечении проблемы, вызывающей эту боль, а не предлагать копеечное, выгодное и удобное на первый взгляд решение, которое по сути является временным устранением симптома.
> Вот что, из вышеперечисленного он осилит самостоятельно сделать качественно?
Он и не должен делать это самостоятельно, а должен понимать масштаб проблемы и обратиться к специалисту.
> может у него там вообще на 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 секунд (таймаут теста), что не является правдой. Все эти тесты и числа - только как ориентир для разработчика, а не для клиента. Для оценки. И надо понимать их не буквально, а в контексте конкретных решений.