Повествование ведется от лица Джастина Тэдлока, разработчика WP.
Легко позабыть о том, каким WordPress был 10, 15 лет назад.
Мы избалованы. Мы избалованы обилием документации и руководств, огромным объемом знаний, накопленных за более чем десятилетний период. Мы испорчены нашим собственным опытом, характерным для энергичной юности, и этот опыт теперь ставит нас раком, ведь мы постарели вместе с нашей любимой платформой.
Мы превратились в вечно недовольных стариков. «Вот в наше время не было такого количества разных инструментов, чтобы писать код. Мы все создавали с нуля».
Ладно, это все шуточки. Я принадлежу к разработчикам того самого старого движка WordPress, по которому многие испытывают ностальгию. Думаю, что я имею право прикалываться над собой. Почему бы и нет. В какой-то степени те времена были проще. Но не совсем.
Я уже долгое время состою в сообществе WP. Всякий раз, когда в WordPress выходил новый функционал, на нас непременно обрушивалось цунами критики. У меня в памяти еще живы те дни, когда в WordPress практически не существовало документации ни для чего.
В последнее время все чаще поднимается вопрос о сложности вхождения в среду современной разработки WordPress. Этот аспект обсуждается уже несколько лет, но последняя вспышка произошла после недавнего твита Криса Вигмана:
«Чем глубже я погружаюсь в современную WP-разработку, тем больше я понимаю, почему новые разработчики не хотят с этим связываться. Это уже не тот проект, что был в прошлом. Кривая обучения сейчас очень крутая, причем вне зависимости от вашего прошлого опыта».
Около месяца назад я написал свой первый блочный плагин – всего за пару часов. Тогда же в статье я отметил, что входной барьер стал существенно выше, чем был в 2007. Сейчас, когда прошел месяц, я уже не так уверен в своих словах. Возможно, я глядел на прошлое сквозь розовые очки, позабыв о тех проблемах, с которыми я тогда столкнулся.
Если в PHP мои познания довольно хороши, то с JavaScript я отстал где-то на 10 лет. А сейчас JS в WP стал важнее, чем PHP.
В своей прошлой статье я жаловался на документацию. Но давайте будем честными. В WordPress никогда не было продуманной документации, которая позволила бы научить начинающего разработчика всем аспектам программирования. За свою карьеру я написал как минимум несколько сотен руководств. И практически каждый раз мне приходилось копаться в исходном коде проекта, чтобы разобраться в нем, что и позволило мне обучать других разработчиков. Другие разработчики зачастую поступали точно так же.
Со временем на WordPress.org появилась адекватная документация, но это не произошло в одночасье. Этот проект постоянно развивался.
Тогда же я решил написать свой первый блок на чистом JavaScript. Никаких инструментов для сборки. Никаких документаций по React. Просто чистый JS-код в моем редакторе. Мне пришлось сначала научиться ползать – только потом я уже научился ходить. Нужно было сделать так, чтобы моя первая итерация кода заработала, прежде чем я перейду к чему-то более сложному.
Через пару дней я переписал все это, используя современный JavaScript, и скомпилировал его с помощью webpack. Через неделю я создал второй плагин с расширенным функционалом.
Было ли это сложно? Да. Был ли входной барьер выше, чем когда я впервые разрабатывал плагины? Возможно. По правде говоря, я не так уж сильно и старался, поскольку сейчас у меня немного иной отрезок жизни. В 37 лет уже не так много драйва, да и меньше возможностей для получения новых навыков так же быстро, как это было в 20 лет. Но у меня есть прочный фундамент и достаточный опыт для преодоления некоторых препятствий, с которыми я столкнулся.
Была бы моя борьба жестче, если бы мне в 20 лет пришлось изучать JavaScript вместо PHP для WordPress? Сомневаюсь. Оба языка имеют крутую кривую обучения для новичков.
Первое знакомство с Subversion или Composer может быть таким же пугающим, как и первое погружение в webpack и npm. Для свежего ума, чистого листа, который предстоит заполнить знаниями в области WordPress, входной барьер будет таким же, как и для нас в свое время с PHP.
Для нас, старперов, мир перевернулся с ног на голову. Этого нельзя отрицать. Проект Gutenberg, который лежит в основе практически каждой новой возможности WP, развивается так быстро, что за ним невозможно угнаться, если при этом еще и совершенствовать свои навыки. Легко потонуть в этом омуте. Если такое происходит со мной, то я просто устраиваю себе передышку, разгружаю свои мысли, чтобы затем уже с новыми силами вернуться в строй.
Вклад в экосистему WordPress всегда был осложнен какими-нибудь препятствиями. Недостаток времени, нехватка знаний в PHP, отсутствие других навыков – все это оставило многих разработчиков на обочине проекта. В некоторой степени это поменялось. Некоторые участки стали более доступны для пользователей, чего раньше не наблюдалось. Проще всего это увидеть в контексте создания тем.
«Люди должны понимать, что разработка тем идет в сторону упрощения», – твитнула Каролина Наймарк. – «Входной порог для дизайнеров и новых разработчиков становится ниже. Когда разработчики кричат, что они не могут использовать свои хуки в блочной теме, они не смотрят в будущее, они отталкиваются только от того, что есть сейчас».
Я лично потратил больше времени на темы для блочного редактора, нежели на разработку плагинов. Авторам тем подсунули пустой холст. Возможно, когда блочные темы будут поддерживаться в ядре WP, все станет гораздо проще.
Конечно, я мог бы до тошноты писать о том, как разработка тем идет семимильными шагами. Но главное не это. Революционная часть системы заключается в том, что она идеальна для людей, не соприкасавшихся с ней в прошлом.
Вместе с релизом WP 5.8 на WordPress.org появилась первая итерация директории паттернов. Вскоре любой пользователь сможет добавлять свои собственные блочные паттерны, не написав ни единой строки кода. Люди будут просто создавать разметку в редакторе, после чего копировать ее и делиться ей с другими.
Когда появится редактор сайтов, правила игры опять изменятся. Пользователи смогут создавать дизайн всего фронтэнда без каких-то особых навыков в области программирования.
Если WordPress должен стать более сложным для разработчиков, чтобы дать пользователям такую мощь, то с этим я легко смирюсь.
Самый высокий входной барьер – как это всегда и было – касается вклада непосредственно в сам движок WordPress. Или вклада в блочный мир посредством Gutenberg.
Раздел «The Getting Started With Code Contribution» в Block Editor Handbook представляет собой гигантскую мешанину из примечаний и процедур по установке, которая может отпугнуть даже маститого разработчика. Практически все опции связаны со сторонними инструментами, а потому любые проблемы, с которыми вы столкнетесь при настройке своей системы, с высокой вероятностью приведут вас на форумы поддержки или в чаты за пределами WP. Даже внести свой вклад в разработку Gutenberg стало труднее.
Не хватает истории. У нас было полтора десятилетия, чтобы отточить наши механизмы для классического WordPress. Зачастую приходилось совершать достаточно жесткие, в чем-то неприглядные шаги, чтобы сделать пространство вокруг WP комфортным для разработчиков. При этом у нас было всего три года, чтобы довести WP до такого же естественного состояния.
Я остаюсь оптимистом. Надеюсь, что и через 15 лет у нас будут вестись дискуссии касательно нового стека технологий, внедренного в WordPress 10.0. А пока я с нетерпением жду улучшения нашей документации, расширения навыков нашего сообщества программистов и появления новых WordPress-разработчиков.
Что вы думаете по поводу разработки WordPress? Стала ли она сложнее? Ощущается ли дефицит «свежей крови» в этой области?
Источник: wptavern.com
Возникла необходимость срочно поднять свои показатели PageSpeed & Core Web Vitals? Ниже мы привели три быстрых совета, которые помогут вам это сделать.
Уже скоро нас ждет обновление Page Experience от Google. Если вы читаете эту статью, то вы, вероятно, пытаетесь сейчас оперативно устранить возникшие проблемы, проигнорированные ранее, либо ищете способы улучшить уже проделанную работу. Представители индустрий понимают, что сначала эффект будет практически незаметный, но со временем алгоритмы станут все более весомы и важны в ранжировании.
Обновление Page Experience напоминает обновление HTTPS. Когда новый алгоритм был запущен, он, как нам всем тогда казалось, не привел к перестановкам в ранжировании сайтов. Но много ли HTTP-сайтов сегодня можно видеть в топах Google? Естественно, можно возразить, что это не следствие каких-то санкций, а простой эффект от перехода к HTTPS, ведь совершить такое переключение легко, да и практически все новые сайты запускаются сразу на HTTPS.
Тем не менее, если у вас незащищенный сайт, вы столкнетесь с кучей ресурсов, которые будут иметь превосходство над вами. Возможно, это небольшое преимущество, но даже в таком случае его нельзя игнорировать.
Давайте рассмотрим следующие простые советы, как получить преимущества в ранжировании за счет улучшения показателей PageSpeed и Core Web Vitals в WordPress.
Совет 1. CloudFlare
Этот совет не является эксклюзивным для WordPress.
Мой собственный сайт имеет довольно плохие показатели Core Web Vital. Далеко не все знают, что CloudFlare предлагает бесплатный план, включающий в себя множество улучшений скорости сайта.
Еще до внедрения всех советов скорость моего сайта была следующей:
Мы подключили бесплатный тариф CloudFlare и включили компоненты оптимизации скорости:
Существенная разница! И это примерно 20 минут работы, включая создание аккаунта. После обновления до Pro-версии (примерно 20$ в месяц) и настройки практически всех параметров мы получили следующее:
+ 11 пунктов за 20 долларов. Неплохо.
Я подключил следующие настройки:
- Polish image optimization.
- Mirage.
И поскольку мой сайт был на WP, у меня была следующая опция:
В итоге я установил плагин, применил рекомендуемые настройки, после чего получил следующее:
Здесь есть кое-что веселое. У меня улучшились показатели FCP и Speed Index, но просел LCP.
Я протестировал несколько настроек, но ни одна из них не улучшила ситуацию, потому я решил отключить WordPress-плагин.
Все всегда нужно тестировать.
Совет 2. Hummingbird
В данном случае я говорю не об алгоритме Google лохматого 2013 года, а о плагине WordPress с таким названием. Я протестировал кучу разных плагинов для скорости и кэширования. Какие-то работали лучше, какие-то хуже. Но стабильно высокие результаты показал плагин Hummingbird – конечно, если вы работаете с хорошим хостингом.
Hummingbird – это не просто плагин для кэширования (ведь у нас уже есть кэширование на стороне хостинга и кэширование через CloudFlare). В данном случае кэширование Hummingbird нас вообще не будет интересовать. Что мне еще понравилось, так это то, что Hummingbird можно присоединить к CloudFlare.
Автоматическая оптимизация лично для меня оказалась провальной. Возможно, вам придется немного повозиться с настройками, чтобы понять, какие элементы можно сделать встроенными (inline) без нарушения работоспособности сайта.
Для чистоты эксперимента я отключил все функции повышения скорости и кэширования в CloudFlare. Итак, на момент написания этого раздела моя начальная позиция скорости – это 34.
Я перенес весь мой CSS и JS-код в футер и сжал его. Сделать это смогут не все, т.к. многие сайты ломаются после такого. Некоторым сайтам нужно, чтобы jQuery загружался раньше (без этого не будут работать разные слайдеры и т.д.).
Мы рекомендуем вам протестировать различные страницы, включая страницы продуктов, контактные страницы, все страницы шаблонов и т.д. Если ничего не сломалось, то супер! Можно двигаться дальше.
Сразу скажу, что конкатенация файлов лично у меня только ухудшала результаты.
В итоге мы подняли рейтинг с 34 до 58:
Нормально. Я хотел довести этот показатель как минимум до 60. Это позволяет защититься от мелких перебоев и дает возможность всегда держаться выше 50, что является пороговым значением до «плохих» результатов.
Совет 3. Asset Cleanup
Плагин Asset Cleanup – еще один способ быстро поправить показатели PageSpeed и Core Web Vitals в WordPress.
Основное назначение плагина – позволить владельцам сайтов останавливать загрузку скриптов для определенных страниц или их групп. Смотрим предложения:
Плагины шаринга в соцсетях – отличный пример. Мы используем их у нас в блоге, но они подгружаются везде на сайте.
Давайте протестируем, как они влияют на оценку производительности. После деактивации плагина Hummingbird мы получили показатель 35.
После установки и активации плагина вы увидите следующие настройки:
Здесь как нельзя кстати окажется тестовый режим, имеющийся в плагине. Некоторые скрипты вам, возможно, захочется протестировать (к примеру, скрипты слайдера на всех страницах). Вы можете отключить все скрипты и включать их по одному, тестируя функциональность. Именно так я и поступил.
После 20-30 минут работы показатель PageSpeed стал 68.
Проблемные области остались следующие:
Уверенный прогресс. А теперь давайте объединим все три совета вместе.
Комбинирование не сработало. Оценки и тайминги сильно просели. Это было неожиданно, поскольку CloudFlare и Asset Cleanup, как мне казалось, должны были хорошо взаимодействовать в связке.
Увы, только 59.
В нашем случае мы решили остановиться на одном CloudFlare.
Как вы могли заметить, в данной статье мы анализировали именно показатель для мобильных устройств. Для десктопов наши показатели с Cloud Flare стали 99:
Естественно, в вашем случае может сработать что-то другое. Мы советуем еще посмотреть в сторону Jetpack Boost.
Источник: www.searchenginejournal.com
Оптимизация веб-проекта – сама по себе довольно сложная задача, но если мы коснемся мультиязычных сайтов, здесь все становится еще запутаннее.
SEO-оптимизация мультиязычных сайтов затруднительна по двум причинам:
- нужно параллельно обслуживать несколько версий одного и того же сайта;
- нужно грамотно связывать эти версии между собой.
Документация по этому вопросу часто бывает неполной или противоречивой. Даже советы Google по этой теме слишком разрозненны и забиты техническими деталями. Я решил составить свое руководство по управлению многоязычным сайтом, чтобы сохранить ваши нервы. Все рекомендации основаны на моем личном опыте и на подробных руководствах, встречающихся в сети.
В первой главе мы рассмотрим теги hreflang.
Что представляют собой теги hreflang
Когда оптимизатор приступает к работе над мультиязычным сайтом, первым делом ему следует проанализировать структуру сайта. Под структурой я подразумеваю две стороны одной медали:
- Опыт взаимодействия (UX). Может ли пользователь легко изменить язык сайта? Видна ли кнопка переключения с одного языка на другой на всех страницах? Правильно ли заданы ссылки? Если ответ на эти вопросы – «нет», то необходимо реализовать простое, интуитивно понятное решение, которое поможет посетителям сайта переходить с одной страницы на другую.
- Техническое SEO. Понимают ли поисковые роботы, сколько версий есть у сайта? Связаны ли страницы со своими языковыми версиями (переводами на другие языки)?
Чтобы ответить на последний вопрос, который нас интересует больше всего, нужно проверить наличие тегов rel hreflang. Эти теги сообщают Гуглу (или Яндексу), какой язык используется на конкретной странице, чтобы поисковая система могла предоставить пользователю готовый результат на его языке. Теги могут стоять в хэдере сайта, в карте сайта или в HTTP-заголовке.
У тега hreflang есть своя структура:
| 01 | <link rel="alternate" href="http://www.esempio.it" hreflang="it-it" /> |
Примечание: веб-страница не будет оштрафована гуглом напрямую в случае отсутствия тега hreflang. Его цель состоит в том, чтобы пользователь мог получить подходящую версию сайта на основе поисковых предпочтений и локации. Однако отсутствие hreflang может поставить под угрозу UX, увеличить показатель отказов, и, как следствие, привести к падению позиций.
Тег состоит из следующих частей:
- href = “url”: URL-страницы на указанном языке.
- hreflang = “it”: язык страницы (в формате ISO 639-1). Также можно указывать код географической зоны (в формате ISO 3166-1 alpha-2) для стран, разговаривающих на одном и том же языке (как пример, en-gb для Великобритании, en-us для США). Можно предлагать контент для пользователей, которые живут в одной географической области, но говорят на разных языках. Пример: можно предложить контент es-us для тех, кто живет в США и говорит по-испански.
Язык – обязательная часть тега hreflang, географическую область же задавать необязательно (в основном это используется для интернет-магазинов с разными подключенными валютами).
Когда использовать теги hreflang
Теги Hreflang используются во всех случаях, когда веб-страница доступна на двух или более языках (или языковых вариантах), либо когда сайт должен выдавать разные страницы в зависимости от местоположения пользователя.
Теги используются как для подкаталогов (www.example.com/it), так и для доменов верхнего уровня (www.example.it).
Куда можно вставить эти теги
Как уже было сказано выше, есть три разных способа интеграции этих тегов на сайт:
- В карте сайта. Вы можете указать разные языка сайта в XML-карте сайта. Самый быстрый способ сделать это – сопоставить все URL с их языковыми версиями в Excel, после чего использовать этот инструмент.
- В HTTP-заголовке. Этот параметр в основном используется для файлов, отличных от HTML (к примеру, для PDF). Просто добавляем в .htaccess следующую строку:
01 Link: <http://www.esempio.it/es/file.pdf>; rel="alternate"; hreflang="es"> - В хэдере сайта (между тегами head). Это решение самое популярное, и именно его мы рассмотрим далее. Теги надо указывать вместе с другими мета-тегами в секции head страницы.
Следует придерживаться только одного из трех методов. Все они одинаково эффективны, но я лично предпочитаю обращаться к тегам в head, поскольку это самый простой в реализации вариант.
Сколько hreflang должно быть на каждой странице
На каждой странице должны быть:
- Тег hreflang, указывающий на исходную страницу.
- Теги для всех версий этой страницы (один hreflang на каждую версию).
Теги должны быть взаимными. Если страница A ссылается на B, то и страница B должна ссылаться на A.
Вот практический пример. У меня есть сайт на итальянском языке, у которого также есть французская версия. На итальянской главной странице я ставлю следующие теги:
На французской:
Другие примеры использования
Одна и та же страна, но разные языки. В этом случае мы будем использовать следующую конструкцию (пример для Швейцарии):
Один и тот же язык, но разные страны. В этом случае задаем еще и географическую область:
Разные языки и разные страны. Вот самый простой пример:
Редирект со сплэш-страницы
На сайте могут быть универсальные страницы, для которых не задан конкретный язык или регион. Обычно это страницы, позволяющие пользователям выбирать предпочтительный язык или автоматически перенаправляющие пользователей посредством геолокации на требуемую языковую страницу.
В таких ситуациях достаточно указать x-default в качестве атрибута hreflang.
| 01 | <link rel="alternate" href="http://www.example.com/" hreflang="x-default"> |
Есть специальные генераторы, которые позволяют сформировать все hreflang конструкции. Пример по ссылке.
Другие рекомендации
Тег должен находиться на уровне страницы, а не на уровне сайта. Он должен присутствовать на каждой отдельной странице.
При работе с языком, у которого имеются разные варианты написания, вы можете задавать комбинации написания и региона. Как пример, zh-Hans-TW для обозначения упрощенного китайского (zh-Hans) для пользователей в Тайване (tw).
Инструкции по добавлению языковых тегов в WordPress
При работе с WordPress можно воспользоваться плагином, который позволяет добавлять разные мета-теги в head отдельных страниц.
Самый простой и надежный вариант – HREFLANG Tags Lite.
Пункт меню HREFLANG в админке WordPress позволяет задавать требуемые параметры.
Выберите типы записей, для которых вы хотите включить плагин, после чего сохраните изменения.
Далее вам нужно будет отредактировать запись или страницу, для которой вы хотите добавить тег hreflang. На странице редактирования записи вы увидите новый пункт, который называется HREFLANG Tags.
Здесь вы можете добавить URL-адрес для поста, редактируемого в настоящий момент, а также выбрать его язык. Затем нажмите на кнопку + для добавления URL-адресов других переводов. Сохраните изменения.
Более мощные решения для создания мультиязычных сайтов:
Выполняем валидацию hreflang
Даже если вы и включили hreflang, зачастую все это может быть сделано с ошибками. Потому стоит провести валидацию hreflang через специальные инструменты.
- Sitrix hreflang tag testing tool. Этот инструмент выводит теги, заданные на вашем сайте, и позволяет узнать, имеются ли какие-либо ошибки с ними.
- Merke hreflang tags testing tool. Еще один полезный инструмент для тестирования hreflang.
- agency hreflang tag testing tool. Этот инструмент выводит ошибки с hreflang.
Источник: marsigliadigital.com