DE{CODE}: 2022 — год разработчика WordPress.

Никогда не было лучшего времени, чтобы специализироваться на разработке WordPress. WordPress продолжает пожирать Интернет как любимая в мире система управления контентом (CMS) и даже самая популярная безголовая CMS. На этой основной сессии DE{CODE} 2022 основатель и директор по инновациям WP Engine Джейсон Коэн обсуждает проблемы и возможности, которые ждут разработчиков WordPress, а также проекты, над которыми работает WP Engine, чтобы облегчить их жизнь.

Посмотрите полное видео ниже!

Слайды сессии:

Полный текст стенограммы

ДЖЕЙСОН КОЭН : Привет и добро пожаловать на DE{CODE}, ежегодную конференцию WP Engine, где мы чествуем разработчиков WordPress. Меня зовут Джейсон Коэн, и я основатель WP Engine. Я хочу начать DE{CODE} этого года с убеждения, что 2022 год — это год разработчика WordPress. Я собираюсь объяснить, почему я считаю, что в этом году так много обещаний и возможностей для всех нас, а затем я хочу поговорить о том, как вы можете ускорить свою карьеру на этом рынке.

Итак, позвольте мне начать с вопроса: каждое сообщество разработчиков программного обеспечения чем-то известно, так чем же известны разработчики WordPress? Я бы сказал, что разработчики WordPress известны созданием красивых веб-сайтов, которые нравятся издателям. Итак, вот что я имею в виду: мы все знаем, что существуют миллионы веб-сайтов, использующих WordPress, но у вас также есть такие люди, как Under Armour, многонациональный бренд одежды, который использует WordPress и нанимает разработчиков WordPress.

Продажи Under Armour в прошлом году составили 5 миллиардов долларов, поэтому они не используют WordPress только потому, что он бесплатный. Они могут позволить себе купить любое программное обеспечение, какое захотят. Они используют WordPress, потому что он соответствует их требованиям, и они нанимают разработчиков WordPress, потому что вы знаете, как учесть эти требования и создать красивые, легко обновляемые веб-сайты. Как этот.

Или National Geographic, это один из самых уважаемых медиа-брендов в мире, и Nat Geo нуждается в красивых, легко обновляемых веб-сайтах со сложным управлением цифровыми активами, которые могут обрабатывать мультимедийные возможности. Поэтому, конечно, они нанимают разработчиков WordPress. Это вариант использования, которым вы знамениты. А как насчет техники? Будет ли современная технологическая компания использовать WordPress?

Да, команда Dropbox может создать CMS с нуля, если захочет, или использовать любую из постоянно появляющихся технологий Site Builder. Но Dropbox предпочитает работать с WordPress и разработчиками WordPress для тех частей своего сайта, которые должны быть привлекательными и удобными для публикации. Как насчет варианта использования, когда маркетинговая команда хочет использовать технологию внешнего интерфейса, отличную от WordPress?

Итак, они хотят использовать WordPress для CMS, но что-то другое для внешнего интерфейса. Могут ли они по-прежнему использовать WordPress? Конечно, это и есть безголовый WordPress. Таким образом, они могут сделать выбор, как это сделал Android Authority, и использовать безголовый WordPress. Таким образом, Android Authority по-прежнему использует WordPress в качестве CMS для управления авторами, контентом, мультимедиа и всеми вещами, которые необходимы для управления серверной частью веб-сайта, но передняя часть обрабатывается другой структурой.

И когда бренду нужен безголовый подход, такой как авторитет Android, он все равно звонит разработчикам WordPress, потому что им нужна производительность и безопасность несвязанного веб-сайта, конечно, но им нужен сайт, соответствующий их рабочему процессу публикации и всем другим вещам, которые они хотят. Мы пришли к выводу, что за последние почти 20 лет их веб-сайт работал на WordPress. И разработчики WordPress знают, как это сделать.

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

Вот почему я говорю, что 2022 год — это год разработчика WordPress, потому что вы освоили то, что нужно каждому издателю, и эти потребности не изменились, они просто ускорились. Например, каждому издателю нужен органический трафик из поисковых систем, таких как Google, конечно, они нужны, и люди все еще постоянно говорят о том, как это сделать. Это новое? Нет, очевидно, нет. По сути, одни и те же статьи публиковались годами, и разработчики WordPress являются экспертами в этом.

Как насчет A/B-тестирования? Или еще лучше, без тестирования кода A/B? Это модно. Это инновационно, верно? Теперь вам придется карабкаться и изучать эти новые инструменты. Ну, за исключением того, что вы этого не делаете, потому что занимаетесь этим годами. Например, эта идея тоже получила венчурное финансирование восемь лет назад. Мол, здесь нет никаких изменений. А/Б-тестирования кода еще нет, и вы уже знаете, как это делать. Вы уже являетесь экспертами во всем этом. Это мило.

Многие из вас также знают о недавних изменениях в поиске Google, которые используют опыт страницы в качестве фактора ранжирования. Работа со страницей означает такие вещи, как скорость страницы и другие вещи, и вы также можете узнать об этом в обновлении Core Web Vitals. Вносил ли когда-либо Google подобные изменения, на которые вам приходилось реагировать? Ну да, на самом деле все время, да? И вы знаете, как это сделать.

Да, это новый инструмент, но делать веб-сайты быстрыми, имея это в виду, не ново, и Google уже давно использует скорость страницы в качестве фактора ранжирования и пытается сделать вывод, будет ли посетитель сайта удовлетворен в течение длительного времени. . Это все вещи, в которых вы уже разбираетесь. Так что в каком-то смысле мир не меняется. И это приятно праздновать, потому что, когда дело доходит до обслуживания издателей таким образом, разработчики WordPress уже опережают конкурентов. Вы уже эксперты.

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

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

Таким образом, такие вещи, как A/B-тестирование и SEO, могут меняться очень медленно и принципиально не меняются вообще, но технологии меняются, и вы должны быть в курсе всего, и именно об этом я хочу поговорить в следующие 20 минут. Что это за вещи? Итак, какие из этих захватывающих новых изменений в технологиях, на которые, я думаю, вам следует обратить внимание, а может быть, и принять? Я хочу дать вам представление о том, что я вижу в качестве очага интересных изменений в нашем пространстве.

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

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

Теперь хорошая новость для нас заключается в том, что многие достижения в Интернете открывают возможность предоставления таких адаптивных возможностей. Итак, давайте объясним это. Покажем несколько примеров. Как это работает? Итак, вот реальный пример: у интернет-журнала было требование использовать форумы HubSpot для сбора потенциальных клиентов. Почему форумы HubSpot? Поэтому форумы HubSpot используют метод, называемый прогрессивными полями.

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

Это отличный пример адаптивного опыта. Но есть компромисс. Использование этого стороннего скрипта, такого как форумы HubSpot и другие в этом примере, замедляло работу веб-сайта. На самом деле, их мобильная оценка маяка была всего 40 из 100, что означает, что их сайт медленный и означает, что они не будут занимать столь высокие позиции в SEO. Итак, вам нужен этот адаптивный опыт, но он вызывает проблемы со скоростью. Что вы делаете по этому поводу?

Вот тут-то и появляется новая техника под названием Partytown. Таким образом, Partytown перемещает сторонние скрипты, подобные этому, из основного потока движка JavaScript браузера и загружает их в отдельный поток. Таким образом, это означает, что сайт становится интерактивным намного быстрее, поэтому пользователи не блокируются от действий, взаимодействия, а оценка маяка увеличилась с 40 до 90 только благодаря использованию Partytown с той же классной адаптивной функциональностью.

Таким образом, вы можете иметь адаптивные скрипты, которые действительно крутые, но медленные, и сделать их не медленными. Это круто. Это то, что вы, как архитектор, должны делать, чтобы сделать веб-сайты ваших клиентов великолепными. Так что это способ сделать JavaScript быстрым. Еще одна важная часть производительности — это средства массовой информации, о которых вы, возможно, уже знаете, но подождите. Так что всем, но особенно издателям с большим количеством медиа, нужны красивые, большие изображения, которые отлично смотрятся.

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

Таким образом, простое переключение на изображения AVIF может значительно ускорить этот журнальный сайт или любой другой сайт. Теперь самое смешное. Я сказал, вы, наверное, знаете это. Я делал презентацию о AVIF в прошлом году, когда ему было всего несколько месяцев, а теперь, год спустя, вы им пользуетесь? Нет, почти никто не пользуется. По данным W3Techs, менее 0,1% веб-сайтов используют AVIF, даже с WebP его используют менее 4% веб-сайтов.

Таким образом, это методы, которые в некотором смысле устарели или должны быть известны, и все же вы все еще находитесь на переднем крае, если используете их. Это действительно простой способ ускорить работу веб-сайтов, что, конечно же, хорошо для пользователей и хорошо для SEO с форматами изображений, и люди до сих пор, как правило, не делают этого. Теперь вы можете обнаружить, что WordPress не поддерживает AVIF, но поддерживает изображения WebP.

Так что, возможно, WebP достаточно хорош для вашего клиента, использующего обычный WordPress, или, может быть, это еще одна причина использовать безголовый WordPress, потому что тогда намного проще автоматически поддерживать AVIF. Это зависит от вас, чтобы жонглировать требованиями клиента, жонглировать техническими возможностями и выяснить, как правильно все это объединить. Но я думаю, как архитектор, просто игнорировать это — не лучший вариант. Я думаю, вам следует разработать здесь какую-то технику, потому что это очень простой способ помочь вашим клиентам.

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

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

Итак, мы все привыкли к тому, что на данный момент я думаю, что я возьму свой сайт и протестирую его на размер мобильного телефона, а затем протестирую его на iPad, а затем протестируйте его для ноутбука, возможно, протестировали еще раз для сверхширокого экрана, но это уже три или четыре вещи, которые я получил на тест. Но теперь — а как насчет каждого из этих случаев, что, если размер шрифта установлен очень большим? Это все еще выглядит правильно? Вы это тестируете? Как насчет светлого режима по сравнению с темным режимом? Это еще раз 2 количество вещей, которые вы должны проверить.

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

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

Итак, следующая вещь, которую я собираюсь показать, это кое-что действительно изящное, и я лично очень рад, что мы получаем CSS и HTML, потому что я хотел этого. И на самом деле, я даже лично написал код, чтобы попытаться сделать это на JavaScript, потому что очень этого хотел. И теперь он нативно подходит для CSS и HTML, а это значит, что он будет доступен везде. И Performant, и все остальные инструменты будут его поддерживать. И поэтому я очень взволнован этим.

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

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

Теперь посмотрите, что текущий CSS не поддерживает это. Он просто говорит, что весь экран широкий, поэтому вы широкий, а не да, экран может быть широким, но вы находитесь в колонке, поэтому вам все равно нужно вести себя так, как будто вы разговариваете по телефону. Это то, что делают контейнерные запросы. Очень взволнован этим. Теперь это всего лишь часть еще большей тенденции, которая представляет собой переход к восприятию веб-страниц не как целой веб-страницы, а с точки зрения компонентов. Кусочки страницы.

Теперь, как разработчик PHP, вы привыкли разделять некоторые вещи. Сюда идут стили, сюда идут функции, сюда идут целые макеты страниц и так далее. Но переход на компоненты — это больший сдвиг. Это говорит о том, что часть внутри страницы должна состоять из этих многократно используемых отдельных компонентов. Основополагающая технология Интернета, такая как CSS и HTML, движется к компонентам, как вы только что видели с этим компонентом, таким как мышление, где мой размер должен основываться на мне, а не на более широкой странице.

Вы также можете увидеть этот тип мышления, конечно, в Гутенберге. Таким образом, пользователи WordPress больше не пишут эти длинные страницы. Они собирают блоки. Блоки являются компонентами. Единицы, которые вы можете повторно использовать и собирать любым удобным для вас образом, будь то фрагменты контента, такие как текст, заголовок или изображение, или макеты, такие как столбцы и вкладки, и многое другое.

И, конечно же, полное редактирование сайта идет еще дальше. Теперь размещение всей страницы, также с блоками, которые являются компонентами, — это то, как мы делаем это с WordPress, так что это сдвиг, который вы должны принять как разработчик WordPress, чтобы не остаться позади. Потому что независимо от того, смотрите ли вы на это с точки зрения базовой технологии, такой как HTML и CSS, или смотрите ли вы на то, куда WordPress уже ушел и куда он движется с Гутенбергом и полным редактированием сайта, все это указывает на то, что вы должны думать о вещах в компонентах, возможно, даже разрабатывать такие вещи, как компоненты.

И это даже верно, когда вы смотрите на более широкую сеть фронтенд-разработки, например, на безголовые веб-сайты и мир JavaScript, это точно такая же история. Таким образом, такие JavaScript-фреймворки, как React, View и angular, которые почти все используют, с самого начала были основаны на компонентах. Годами. Вы не помещаете вещи в отдельные файлы, вы помещаете компоненты в отдельные файлы и используете их повторно.

Итак, дело в том, что независимо от того, используете ли вы JavaScript с безголовым, используете ли вы WordPress или просто пишете HTML и CSS в чистом виде, вам все равно нужно думать о компонентах. Так что в этом есть большая ценность. Это похоже на то, как объектно-ориентированное программирование инкапсулирует данные и код. Точно так же веб-компоненты инкапсулируют внешний вид, поведение, а также данные и код, и делают их пригодными для повторного использования, что потрясающе.

Еще одна вещь, помимо возможности повторного использования и компоновки, заключается в том, что их можно индивидуально тестировать. Итак, мы возвращаемся к тестированию, о котором мы говорили. Таким образом, вы можете взять компонент, даже, скажем, кнопку, а затем протестировать его в различных контекстах. Как выглядит кнопка, когда текст большой или маленький? Как выглядит кнопка в разных браузерах? Как выглядит кнопка в светлом или темном режиме и так далее.

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

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

Хитрость заключается в том, что эту новую технологию нужно изучать и внедрять, чтобы вместо того, чтобы оставаться позади, вы использовали такие вещи, как адаптивный опыт, а также инструменты, лежащие в его основе, и компоненты для создания этих вещей. Презентации DE{CODE} призваны помочь вам в этом. Итак, в DE{CODE} у нас есть трек для безголового WordPress, вы можете узнать, когда использовать безголовый для клиента, когда не использовать безголовый. У нас есть семинары, которые помогут вам начать работу с безголовым с нуля очень быстро, буквально за считанные минуты. Так что, если вам это вообще интересно, посмотрите их.

У нас также есть прорывы для электронной коммерции и управления WordPress и другими темами. И мой совет заключается в том, что в течение дня, когда вы просматриваете все эти сеансы, вы впитываете то, что можете, делаете заметки и т. д., но вы ищете одну, две или три вещи, которые вы говорите, хорошо, эти это то, что я собираюсь попробовать. Я собираюсь научиться этим вещам. Я собираюсь попытаться внести эти вещи в проект. Я собираюсь стать хорошим в этом. Может быть, я даже вернусь к своим существующим клиентам и скажу: «Эй, давайте обновим ваш сайт, чтобы использовать это».

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