Эта статья является частью серии, созданной в сотрудничестве с SiteGround . Спасибо за поддержку партнеров, которые делают возможным использование SitePoint.
Если вы разработали темы WordPress для массового распространения, вы, возможно, столкнулись с проблемой нахождения идеального баланса между созданием качественных тем и созданием многофункциональных, насыщенных мультимедиа продуктов для ваших клиентов.
Давайте подробнее рассмотрим, в чем может заключаться напряженность, и как вы можете найти способы найти компромисс между созданием быстро загружаемых тем и предоставлением пользователям гибкости и простых параметров настройки, которые они любят и ожидают.
Гибкость и производительность в разногласиях при кодировании тем WordPress?
Вначале я скажу, что мое обсуждение не будет касаться производительности по отношению ко всему веб-сайту WordPress, который может включать ряд различных факторов, таких как поиск хорошего хостинг-провайдера , реализация механизмов кэширования, использование как бэк-энда, так и front-end. конец техники и т. д.
Кроме того, тема не о производительности тем WordPress, которые вы кодируете с нуля, либо для собственного использования, либо для конкретного клиента. В этих конкретных случаях вы адаптируете свои темы к конкретным потребностям себя или своего отдельного клиента, что должно облегчить оптимизацию производительности.
Скорее, мое внимание будет сосредоточено на темах WordPress, которые вы кодируете для широкой публики, для распространения на WordPress.org или на онлайн-рынке. Сценарий такой, когда вы, как разработчик темы, не можете контролировать, как ваша тема будет использоваться и настраиваться.
Но почему кодирование для производительности конфликтует с темами кодирования для публики?
В целом, производительность требует от вас:
- придерживаться простых конструкций
- включить ограниченное количество функций в ваши темы (больше функций, вероятно, потребует большей вычислительной мощности и ресурсов, что влияет на производительность темы)
- добавить минимальное количество шаблонов страниц для темы для работы (меньшее количество шаблонов требует меньше ресурсов, что хорошо для производительности)
- выполнять как можно меньше запросов к базе данных (запрос к базе данных занимает много времени)
- ограничить количество и размер изображений и других носителей, которые, как известно, тяжелые файлы
- минимизировать количество HTTP-запросов (каждое обратное путешествие на сервер и обратно занимает некоторое время с очевидными негативными последствиями для производительности).
С другой стороны, значительное количество пользователей вашей темы, скорее всего, более предприимчивы, чем технологически настроены. Следовательно, то, что они могут искать, — это продукт, который они могут превратить во что угодно, без единой строчки кода, с множеством функциональных возможностей, потрясающих фото и видео ресурсов, супер восхитительного параллакса и других анимационных эффектов, и тому подобное.
Чтобы предоставить пользователям тем гибкость, которую они хотели бы получить, это может привести к некоторым затратам на производительность. Но давайте рассмотрим несколько конкретных моментов, которые иллюстрируют, как это может произойти, и как вы можете найти золотую середину для успешного результата.
Темы для внешнего вида, плагины для функциональности
Несмотря на то, что ряд авторитетных экспертов WordPress высказывают несколько аргументированных критических замечаний в отношении так называемых тем о кухонных раковинах, то есть тех многоцелевых тем, которые могут стать чем угодно, предлагая любую функциональность под солнцем, спрос на них по-прежнему сохраняется. идет сильный.
Темы, дающие пользователям возможность легко добавлять кнопки социальных сетей, функции SEO, контактные формы, таблицы цен и т. Д., Хотя и привлекают большое внимание покупателей, не обходятся без серьезных недостатков.
В частности, такая тема WordPress тесно связана с плагинами, специально созданными для нее или даже интегрированными непосредственно в тему. Эта практика широко осуждается по следующим причинам:
- Некоторые плагины, поставляемые в комплекте с темой, могут иметь уязвимости, которые подвергают пользователей темам риску. Если тема не содержит установленных плагинов, она менее подвержена таким рискам
- Супер важный недостаток тесной интеграции между темами и плагинами — это то, что Рен Вентура определяет как блокировку темы . Вот его объяснение этой проблемы:
Блокировка темы происходит, когда пользователь WordPress не может изменить свою тему, не потратив большую часть функциональности сайта. Как только тема деактивирована, она деактивирует такие вещи, как шорткоды и пользовательские типы сообщений, которые были зарегистрированы темой. Без этих функций, которые пользователь в значительной степени включил в сайт, все развалится.
Как следствие, когда вы меняете тему, многие вещи, которые вы считаете частью своего сайта, исчезают со старой темой. Например, если ваша тема предлагает возможность добавлять отзывы на ваш веб-сайт, после изменения темы все содержимое, относящееся к вашим рекомендациям, исчезнет. Не хорошо.
- И, конечно же, раздувать, а значит и производительность стоит. Допустим, вам не нужен раздел отзывов на вашем сайте. Тем не менее, весь код, который заставляет эту функциональность работать в теме, все еще там: он занимает место на вашем сервере, что в конечном итоге стоит денег.
Отличная идея, которую группа по обзору тем (т. Е. Добровольцы, которые проверяют темы, представленные в репозитории тем WordPress.org), справедливо соблюдает: отделите функциональность от внешнего вида. Плагины имеют дело с функциональностью, темы с внешним видом. Избавление от всех сложностей улучшит производительность темы и в то же время облегчит пользователям установку и настройку тем WordPress.
Вашим пользователям не нужны тонны опций тем (но они могут этого не знать)
До недавнего времени темы WordPress включали довольно сложные страницы с опциями тем, чтобы пользователи могли вносить любые изменения с помощью нажатия кнопки.
В наши дни благодаря важному решению, принятому Группой проверки тем на WordPress.org в 2015 году, большинство тем предлагают варианты тем с помощью настройщика WordPress , который позволяет просматривать в реальном времени изменения, вносимые пользователями.
К сожалению, менталитет кухонной раковины, который управлял старыми страницами опций темы, начал мигрировать в настройщик, который теперь можно видеть как также начинающий заполняться всевозможными настройками.
Хотя нетехнические клиенты любят варианты тем, чтобы вносить изменения в свои темы, иногда слишком много доступных вариантов приносит больше проблем, чем кажется, что они решают:
- Слишком много вариантов может парализовать пользователей, которые не слишком знакомы с основными принципами дизайна веб-сайтов.
- Установка и настройка темы может занять больше времени, чем ожидалось.
- Легко ошибиться, например, выбрать неправильные цвета, сделать текст нечитаемым и т. Д.
- Пользователи могут добавлять слишком много шрифтов в свои темы, тем самым портя дизайн и замедляя работу сайта.
- Больше опций означает добавление функциональности к теме, что влияет на ее производительность.
Хотя ваши клиенты могут сначала не принять это, вы являетесь дизайнером темы, поэтому вы должны быть тем, кто лучше всех сможет принять важные дизайнерские решения для вашей темы.
Тщательно откалиброванного количества параметров темы должно быть достаточно, чтобы позволить вашим клиентам внести некоторые целевые и тщательно предопределенные (вами) изменения, чтобы персонализировать тему и сделать ее своей.
Внедрить умные методы оптимизации графики
Изображения, скорее всего, будут оказывать наибольшее влияние на производительность темы по сравнению с файлами шаблонов, сценариями и стилями. Просто запустите любую тему через инструмент Speed Test в Pingdom, чтобы убедиться в этом.
Тем не менее, щедрое использование полноэкранных, смелых изображений вряд ли удивительно. Изображения придают тематике огромную эстетическую ценность, а клиенты привлекаются к теме в основном на основе ее визуального воздействия.
Хотя трудно устоять перед мощью великолепной графики, приведенные ниже рекомендации могут помочь вам создавать более быстрые темы, не жертвуя при этом эстетикой (слишком много):
- Использование как можно меньшего количества изображений всегда является хорошим руководящим принципом.
- Воспользуйтесь преимуществами режимов наложения CSS, фильтров и полупрозрачных наложений на изображениях с низким разрешением, чтобы маскировать пикселизацию и улучшать их внешний вид. Вы также можете попробовать поэкспериментировать с режимами наложения CSS и фильтрами для элементов HTML и текста, а не изображений, чтобы создать потрясающие визуальные эффекты, где это возможно.
- Убедитесь, что изображения имеют соответствующий формат и оптимизированы для Интернета.
- Где это уместно, используйте CSS-спрайты, чтобы объединить ваши изображения в большое изображение и, следовательно, сократить HTTP-запросы.
-
Попробуйте реализовать отложенную загрузку изображений . Это обеспечит более быструю загрузку страницы, и если пользователи не прокрутят местоположение
<img>Для отложенной загрузки изображений в WordPress вы можете выбрать один из нескольких хороших плагинов, таких как Lazy Load , a3 Lazy Load и Rocket Lazy Load .
Сделайте поддержку клиентов и образование ваши столпы силы
Вместо того, чтобы предлагать своим клиентам множество запутанных и трудоемких вариантов тем, попробуйте предложить полную поддержку и обучение тому, как использовать ваши темы, оптимизацию изображений, WordPress 101 и т. Д.
Вы можете сделать это используя:
- Сообщения в блоге
- загружаемые руководства
- видео уроки
- Часто задаваемые вопросы на вашем сайте
- система тикетов для более конкретных проблем, которые могут возникнуть при использовании ваших тем.
Обмен базовыми ноу-хау о ваших продуктах и платформе, для которой вы создаете, является отличным способом сделать ваши темы простыми в использовании для ваших клиентов и способствует созданию высокого уровня доверия, что лежит в основе здорового и успешного бизнеса. ,
Иногда гибкость побеждает производительность
Может быть ограниченное количество случаев, когда вы не думаете, что компрометация некоторой гибкости ради небольшого прироста производительности — это хорошая идея.
На ум приходит пара примеров.
При написании СУХОГО кода ваши клиенты могут быть недовольны
Первый пример взят от Тома Макфарлина , известного разработчика и автора тем WordPress.
В своем блоге он объясняет, почему он решил включить длинный список файлов шаблонов WordPress , тем самым идя вразрез с принципом DRY- кодирования (а также отрицательно влияющим на производительность в некоторой степени) при разработке своей темы Meyer .
Мейер был нацелен на блоггеров и цифровых издателей без особых технических знаний WordPress. Зная, что отсутствие опыта кодирования не помешало бы этой аудитории возиться с его темой, Том Макфарлин придумал способ облегчить им задачу. Он предоставил своим клиентам большое количество файлов шаблонов, которые они могли легко скопировать и вставить в дочернюю тему WordPress для настройки, не взламывая оригинальную тему.
Макфарлин пишет:
Если шаблоны определены в базовой теме, а не, скажем, в куче условных выражений для разработчиков, пользователям будет проще основывать свои шаблоны на чем-то, что уже существует…
Поэтому, если бы мне пришлось кратко изложить это, я бы сказал, что я — как и многие разработчики — хочу сохранить мой код как можно более сухим, но при этом есть компромисс в контексте разработки темы WordPress. ,
И я не думаю, что оставаться СУХОЙ — лучший способ сделать это, если вы собираетесь продвигать продукт для широкой аудитории.
Статический исходный код лучше для производительности, но не используйте его в ваших публичных темах
Мой второй пример того, как не ставить под угрозу гибкость для некоторого увеличения производительности в ваших темах WordPress, основан на рекомендациях по производительности от Кодекса.
Там вы найдете несколько отличных советов по производительности, но есть один, который я бы не рекомендовал вам использовать, по крайней мере, если вы собираетесь выпустить свою тему для широкой публики.
Это выглядит так:
Могут ли статические значения быть жестко закодированы в ваших темах? Это будет означать, что вам придется редактировать код каждый раз, когда вы вносите изменения, но для статических областей это может быть хорошим компромиссом.
Например, кодировка вашего сайта, заголовок сайта и т. Д.
Вы можете жестко закодировать меню, которые редко меняются? Избегание функций, таких как
wp_list_pages()Кодекс — Оптимизация WordPress / Производительность WordPress
Избегание ненужных обращений к базе данных и оптимизация ваших запросов SQL — отличные практики, которым должна следовать каждая тема.
Если ваша тема работает немного медленно, попробуйте найти проблемные запросы к базе данных, которые выполняются слишком долго. Вы можете использовать плагин, такой как Query Monitor, в вашей среде разработки, чтобы помочь вам с этой задачей.
Однако о жестком кодировании битов информации, таких как название сайта, пункты меню и т. Д., Не может быть и речи. Даже если ваши пользователи никогда не изменяют эту информацию после ее установки, им нужно установить ее хотя бы один раз, и они вполне справедливо ожидают, что это будет сделано с использованием динамических возможностей WordPress.
Более того, даже если пользователи вашей темы будут готовы копаться в исходном коде, им придется взломать файлы темы, чтобы добавить необходимые данные. Это почти никогда не хорошая идея, не в последнюю очередь потому, что все изменения будут перезаписаны при следующем обновлении темы.
Вывод
Кодирование тем WordPress для широкой публики может включать удовлетворение разнообразных и порой несовместимых потребностей: потребностей вашей клиентской базы, производительности веб-сайта, отсюда и потребности посетителей тех веб-сайтов, которые используют ваши темы, и даже ваши собственные потребности в качестве дизайнера тем WordPress и создатель.
В этой статье я изложил свои взгляды на решение дилеммы, с которой разработчики темы WordPress могут столкнуться между требованиями гибкости и производительности.