Александр Голубев: Apache + Nginx это бред, хотя и очень популярный. Фокус в том, что статику (картинки, стили и тд) будет отдавать Nginx - быстро. И это хорошо. Но, как только нужна динамика - тот же WordPress с его PHP, Nginx отправит запрос на Apache, поднимется его процесс, который вместе с собой поднимет PHP... Здравствуйте, тормоза.
Alex Fisher: тогда зависимости и либы - либо в пакетных папках, либо в vendor, а в init - только свои файлы. То есть, собственный код отдельно, его гит должен отслеживать. Все, что качается или билдится из исходников - в .gitignore
Гриша Никольский: ну как вам сказать. На небольшом, никому особо не нужном сайте (я имею в виду, глобально хакерам вы не интересны) - можно. Если же вы параноите или хотите совсем железобетон - наймите специалиста. Будете пилить сами - слишком высок риск, что улучшив в одном месте, вы добавите проблем в другом. К тому же, безопасность - штука комплексная, это не только валидация полей форм и фильтрация вредоносных данных.
Александр Голубев: на shared основная, самая главная проблема - отсутствие Memcached / Redis, которые радикально меняют ситуацию. Все остальное - вторично. А таже там Apache, который сам по себе тормоз, но самая большая его беда - в работе с PHP. Но перейти на Nginx на shared вы тоже не сможете. Поэтому, для скорости даже самый простой VPS за 5$ в месяц, но настроенный нормально, будет лучше чем самый шустрый и дорогой shared
Иван Украинцев: это маловероятно, разве что для вычисления значения этих переменных берутся из БД (мимо кеша) или по http-протоколу с других серверов (например, по АПИ получается курс валют и тд). Если речь просто о 10-15 переменных, значения которых корректно определены, то такой код в 100-150 строк и на 10-15 переменных выполнится в мгновенье ока.
Ребята, вы делаете 2 ключевые ошибки:
- сравниваете теплое с горячим (статику и динамику)
- не понимая как работает PHP (да и любой серверный язык) делаете выводы на основании только того, что вы видите перед глазами
Александр Голубев: Александр, я не буду писать подробности, достаточно отправить вас читать основы PHP. Вы говорите про каких-то 10 файлов, про какие-то переменные, но это все - микропоспические нюансы. Во время выполнения 1 запроса PHP загрузит несколько сотен (!) файлов WordPress, тем, плагинов, ваши 3-4, или 20-30 шаблончиков, из которых собирается страничка вообще НИКАКОЙ погоды не делают. Что реально влияет на скорость генерации страницы на сервере - так это количество запросов в БД, количество обращений по внешним http-запросам, количество обращей к файловой системе. Но тут такое количество нюансов, что все это не так просто - правильно настроенная серверная ОС кеширует дескрипторы файлов и целые файлы если надо, правильно настроенная БД существенно снижает нагрузку и тормоза, а при наличии объектного кеширования, большинство запросов до БД вообще не доходят и тд. То, что вы уперлись в количество настроек темы и количество шаблонов вообще никак не влияет на скорость. Ну, влияет, но микроскопически, не парьтесь об этом. То, что могут быть криво написанные "настройки темы", которые будут дергать постоянно базу данных и не кешировать запросы - вот это другая история. То есть, проблема не в самих настроках (по-вашему "переменных") и их количестве, не в количестве шаблонов, а в общем качестве кода.
Да как угодно :) Как удобнее. Тут нет каких-то жестких правил.
По вашему примеру - я бы сделал так:
- git репа ествественно в корне
- к вашим файлам в корне добавится, соответственно, папка .git и файл .gitignore
- в .gitignore добавляем build, node_modules - обе папки заполняются выполнением одной команды на папку, одна команда собирает файлы из исходников, другая качает модули из внешних репо, это не нужно держать под контролем версий
- по папочка init не совсем понял что у вас там?
> Где нужно хранить папку с файлами которые загружаются через пакетный менеджер: в корне проекта или в папке init?
Я пока не совсем еще понимаю, что у вас в init, что касается всех файлов через пакетные менеджеры - выделите на них свои папки или собирайте все в одну и и подпапки - как удобнее. Есть некоторые "общие практики" типа папок vendor и тд. Погуглите. К тому же, в каждой сфере, почти в каждом языке программирования, иногда даже в рамках какого-то одного фреймворка есть свои "best practices", которые, в это же время, не являются догмами - вы вольны делать так, как вам удобнее. Репозиторий ведь ваш :)
Alex Fisher: репозиторий в корне проекта. Все ненужное - в gitignore, все нужное - где оно и должно быть - что в корне (какие-то индексные файлы например, конфиги, конфиги билдов и тд), что по своим папочкам. Я не совсем понимаю что вы хотите добиться, почему у вас вообще возник вопрос с корнем репозитория. Возможно, пример вашего репо и целей, которых хотите добиться помог бы прояснить ситуацию?
Гриша Никольский: +1 к WP Panda. В целом - код более-менее, нет явных ошибок, есть валидация данных и тд, в отличие от большинства уроков "для новичков". Но если уж совсем по-чесноку, то да, решение неполное, не самое оптимальное.
WP Rocket и WP FFPC шустрее WP Super Cache. Но свой максимум все они выдают на VPS / Dedicated. На shared хостингах все сложнее, геморнее, и в результате - все равно медленнее.
Иван Украинцев:
> Почему у меня статика грузится за .2-.3 сек
см. выше. Потому что для статики не надо интерпретатор поднимать, парсить файлы и все это дело исполнять, брать данные из БД и файловой системы etc. Для статики просто - взяли файл и выплюнули его в ответ.
> чтобы вп делал слепок всей динамики в статику, чтобы пользователь "первого посещения" качал 1 .html файл и всё
Вам нужен Full Page Cache. Страница генерится один раз и сохраняется в виде статики. Можно хранить как в файловой системе, там и непосредственно в памяти (Memcached, Redis, родной fastcgi_cache у Nginx) - это быстрее. Это делают многие плагины - FFPC (Fast Full Page Cache), WP Super Cache, Batcache и тд. Ищите тот плагин, который позволяет делать pre-caching - генерить заранее, чтобы при первом визите люди сразу получали страницу из кеша. Мой любимый плагин - https://wordpress.org/plugins/wp-ffpc/
> переменных php бывает много да, но они мне нужны для того чтобы клиент мог редактировать сайт
Люди, перестаньте нести чушь про переменные, почитайте хоть основы PHP. Количество переменных (как и их наличие вообще) ничего не решает, это вообще не влияет на скорость обработки кода на сервере. Для того, чтобы переменными на что-то повлиять, это надо сильно постораться наговнокодить так, чтобы были утечки памяти, чтобы рекурсии без выхода шли и тд. В остальных, стандартных случаях, количество ваших переменных в шаблонах WP вообще не имеет значения. Даже для крупных платформ это входит в сферу "микро-оптимизации", а для небольших сайтов - просто выбросите это из головы.
Повторяю еще раз, основные потери идут на запуск интерпретатора, считывание всех необходимых файлов (скриптов), их анализ и компилирование кода, выполнение запросов к файловой системе и базе данных, внешних http-запросов и тп. Это все ресурсоемкие задачи. А работа с вашими переменными - это только маленькая часть одного из этих этапов.
Александр Голубев:
> Так вроде весь jQuery подключается через файл functions.php
jQuery поставляется вместе с WP, он уже подключен с помощью wp_register_script именно в head, где ему и место. Для подключения jQuery достаточно в enqueue вашего скрипта указать его в аргументе "dependency". А вот чтобы перенести в подвал - придется выпилить это все и зарегистрировать заново, по своему. Что чревато последствиями, так как много других библиотек и скриптов действительно зависят от jQuery, а потому рассчитывают на его наличие в head.
> скорость загрузки страницы в WP сильно зависит от php кода
От PHP зависит скорость генерации страницы на сервере. Скорость загрузки страницы от этого зависит лишь частично, так как это лишь один из этапов загрузки страницы.
> темы перебирают очень много аргументов, увеличивая время загрузки иногда на 0.2-0.8 сек, чем если бы это была индивидуальная верстка
Простите, но вы вообще не понимаете о чем говорите. "Перебор аргументов" происходит быстрее, чем браузер парсит ваш CSS. Задержка, которую вы получаете из-за генерации динамической страницы, возникает из-за необходимости провести кучу вычислений и сборок - запустить интерпретатор языка, считать из файловой системы кучу файлов-скриптов, проанализировать их и скомпилировать в машинный код, выполнить его, а уж потом - распарсить урл, запросить данные из БД, выполнить массу рассчетов, собрать страничку из шаблонов и тд. Это свойственно не только WordPress, а и любой динамической платформе, на любом языке. Это неизбежность. Сравнивать с чистым HTML некорректно, так как в этом случае никакой обработки данных нет, сервер просто отдает готовый файл. Чтобы получить этот же результат от динамических платформ, используется Full Page Caching - кеширование страниц целиком.
> Это я не имею доступа к серверным настройкам и кешированию изображений, так как у меня виртуальный хостинг.
У вас там много уже есть. Это и гзип, и корректные заголовки для кеширования статики и тд. Все, к чему доступа вы не имеете - требует специальных знаний, которых у вас нет.
1. jQuery вниз - только если совсем осторожно, он же есть dependency. К тому же, спустить его вниз корректно - это уже advanced technique.
2. Все перечисленное вами - исключительно фронтенда касается. А есть еще долгая задержка между запросом и получением всего этого фронтенда с сервера.
3. Раз уж зашла речь о плотной оптимизации фронтенда, то давайте еще рефаткорить JS. Убирать все ненужное из document.ready, выбрасывать ненужные и медленные либы, менять jQuery на ванильный javascript etc
4. "И отключаете несколько функций ядра WP, которые не нужны, как минимум на фронтэнде" - это вы что такое интересное имеете в виду?
Oioraen:
1. да, 1.9.5 с http/2 уже можно установить без сборки вручную, что лишний раз подтверждает всеобщее желание получить http/2.
2. Ну не знаю, китайские сертификаты мне не внушают доверия. Сайт у них грузится через раз и медленно. Мне лично наличие Великого Китайского Файрвола между моими посетителями и certificate authority нафиг не нужны. Хочется совсем бесплатно - есть StartSSL. А вообще у нормальных сервисов часто сертификаты идут "почти бесплатно" в виде бонуса. К примеру, покупая домены у Namecheap и используя ежемесячную скидку, вы по стандартной цене домена получаете и домен, и нормальный SSL-сертификат, и WHOIS Guard.
3. Установка через какую-то хостинг-панель - просто и понятно. Ручками через командную строку - как ни объясняй, а если человек не дружит с терминалом и не понимает как оно все на сервере устроено - быть беде.
Александр Таратин: Вы на каком-то другом рынке работаете? У вас клиенты какие-то не такие как у остальных? Если ваше конкурентное преимущество - это поддержка старых ИЕ, то у вас большая проблема, и рано или поздно (скорее рано), клиентов вы потеряете все равно. Без обид.
Александр Таратин: так а вы сайт для него одного делаете (нафталинового дебила ценителя антиквариата), или все же для пользователей, которые будут на его сайт ходить? Покажите ему ссылки которые я вам скинул. Убеждать клиентов и предлагать им разумные решения - тоже часть нашей работы. Я понимаю, если у вас проект уже в разгаре, но в целом, советую делать так - изначально при переговорах уточняете, нужен ли ИЕ8 (ну и так по всем спорным браузерам / версиям), если да - почему. Пытаетесь выяснить истинную причину, и объясняете (с графиками и статистикой, как по ссылкам), что это: 1) никому не нужно, 2) адаптация под старые версии это дополнительная работа, что = дополнительное время (сроки) и деньги. В 9 случаях из 10 клиента можно легко переубедить, если оперировать реальной статистикой и вкратце объяснить, что добавить поддержку старых браузеров будет стоить ему копеечку, которую лучше потратить на что-то более полезное. Сроки и бюджет - это элементы модели "неизбежных продаж", на этих аргументах клиента убедить достаточно легко.
Александр Таратин: IE8? Ну это разве что у вас в клиентах какой-то совсем бедный/жадный корпоративный сектор. Покрытие в мире - 2.36% за последний календарный год. В РФ (и среднем по всему рунету) - и того меньше, всего 1.87%. Андроид 2.3 - нафталин 5-летней давности. Все версии андроида - 6.84% мир и 3.73% рунет. Разбивки по версиям у меня нет, но уверен, что подавляющее большинство - минимум 4.0, в основном сендвич, джелли, киткат и лоллипоп. Если есть пруф обратного - буду рад увидеть (сам подробную статистику найти не смог).
evnuh: именно поэтому я дописал "ззы" :) Все же, установка и настройка HTTP/2 пока что штука для более-менее продвинутых - это и кастомная сборка Nginx, и покупка сертификата, и его установка на сервере.
Александр Таратин: свежие версии умеют, поэтому, можно смело считать, что на данный момент покрывается все кроме IE на винде ниже 10, оперы мини и андроида. Опера скоро обновится, задержка была именно в стабильной реализации протокола на стороне серверов (Apache, Nginx etc). Остальные - не паримся особо, так как HTTP/2 с обратной совместимостью, то есть при отсутствии его поддержки работа идет по стандартному HTTP/1.1. Минифицировать и гзиппить будем все равно, остается только минификация. Вангую в очень разумные сроки появление тулзы для оптимизации / автоматизации этого процесса. Возможно, на уровне сервера будет проверяться поддержка и на лету делаться конкатенация и складываться в кеш. По крайней мере для Nginx сделать такое не проблема, а для Apache можно по условной логике подключать модуль PageSpeed, который в том числе и клеит файлы. Или сам PageSpeed обновится с таким функционалом - если HTTP/2 клиентом подддерживается, то будет отдаваться в обычном режиме, если нет - склеенные файлы.
С другой стороны, вреда от склеенных файлов для HTTP/2 вообще никакого, так что можно и смело оставлять склейку.
Ну и про 5 лет - это вы слишком загнули. HTTP/2 - это тот апгрейд, который реально полезен всем, ибо экономит и время, и ресурсы, и деньги. Вполне возможно, что даже вечно отстающие от обновлений шаред-хостинги достаточно быстро введут поддержку, так как это не только снизит их расходы (смогут больше оверселить), но и добавит новый апсел ко всем услугам - SSL-сертификаты. А с запуском https://letsencrypt.org/ и бесплатными сертификатами для всех распространение HTTP/2 заметно ускорится в 2016. Учитывая нарастающую паранойу по поводу шифрования данных - это только плюс.
