- Оглавление
- HTML Proofer
- amphtml-валидатор
- RuboCop
- Трэвис-CI
- AMP Pages
- AMP Sitemap Conflict
- AMP SEO Исправления
- AMP Видео
- Исправление <Head>
- Исправление поста
- Результаты
- Другие улучшения
- Плагины
- Сайт Wiki
- Меньше кода больше
- Заключение
Когда я в прошлом году заглянул на свой сайт, мне понадобилась помощь. В этом не было ничего страшного, но определенно были области, которые нуждались в улучшении. Для начала я ничего не тестировал (не судите меня). Как бы я проверить вещи? Перебив проект и настроив Трэвис-CI конечно.
Затем мой сайт был немного громоздким. CSS был чрезмерным, мне не нужно было меню заголовка JavaScript, у меня были ненужные вложенные теги HTML, и мне все еще не нравилось, как некоторые элементы рухнули на мобильных устройствах.
Последнее серьезное изменение, которое я хотел реализовать, было AMP ( ускоренные мобильные страницы ) сделать проще для мобильных устройств попадающих в мой блог. Это привело к кроличьей норе дальнейших изменений.
Ссылка на исходный код сайта прямо перед публикацией этого блога; но может быть полезно проверить более поздние версии кода, чтобы увидеть, как все изменилось.
Оглавление
тестирование
Мой сайт нуждался в тестировании. У меня не было оправдания. С каждой добавленной новой функцией был еще один шанс, что что-то ускользнет и испортит мой производственный выпуск. После добавления AMP я бы вручную проверил каждую страницу в Google Chrome, используя тег # development = 1 в своем URL. Для каждого изменения макета HTML, я бы пропустил закрывающий тег. Это нужно изменить.
HTML Proofer
Моим первым улучшением в тестировании моего сайта было добавление HTMLProofer , HTMLProofer «представляет собой набор тестов для проверки вашего вывода HTML. Эти тесты проверяют, являются ли ссылки на изображения допустимыми, имеют ли они теги alt, работают ли ваши внутренние ссылки и т. Д. Он предназначен для проверки всех ваших результатов ».
Круто, верно? После настройки RubyGem я обнаружил несколько неработающих тегов HTML, несколько 404 исходящих ссылок и недостающие теги alt на изображениях. Несколько проблем решены.
amphtml-валидатор
После того, как я внедрил AMP (подробнее об этом позже), мне понадобился лучший способ тестирования, а не открытие браузера и проверка каждой страницы с помощью инструментов разработчика Chrome. amphtml-валидатор в помощь; инструмент командной строки пакета Node.js, который проверяет HTML-файлы AMP.
С помощью небольшого Ruby-Fu я смог добавить выполнение пакета Node.js в мой Rakefile. Он находит все файлы * .html в моем каталоге AMP и передает их по одному в amphtml-валидатор. Я проверяю состояние выхода пакета Node.js, уведомляю пользователя о сбое и продолжаю свой день.
Rakefile
desc «Тестирование проверки AMP веб-сайта»: amp do помещает «Запуск AMP Validator ...». желтый bold amp_dir = '_site / amp' system ("find # {amp_dir} -iname * .html | xargs -L1 amphtml-validator"), если $ CHILD_STATUS. exitstatus. нуль? ставит «AMP Validator успешно завершен». , зеленый означает «Сбой валидатора AMP». , красный полужирный выход ($ CHILD_STATUS. exitstatus) конец конецRuboCop
Когда я работал над запросом на извлечение для другого проекта, тесты Rake проекта познакомили меня с RuboCop , RuboCop - это статический анализатор кода для Ruby, который обеспечивает соблюдение Ruby Style Guide , Это был аккуратный маленький инструмент, который я добавил в свой Rakefile, чтобы гарантировать, что написанный мной код Ruby будет понятен другим. Это не было значительным изменением, но оно было для того, чтобы держать себя в курсе принципов сообщества (с которыми у меня было очень мало опыта).
Я добавил это в свой проект, установив RuboCop RubyGem и добавив его файл конфигурации. Файл конфигурации исключает каталог, который в настоящее время нарушил бы сборку Travis-CI.
.rubocop.yml
AllCops: Исключить: - vendor / ** / * # Игнорировать каталог сборки Travis-CIТрэвис-CI
Добавление тестов было отличным. Но мне также понравилась идея, что, если я буду вдали от среды сборки, я смогу внести небольшие изменения в свой телефон, протестировать его и развернуть на производстве. Это было немного несбыточной мечтой для меня. Я знал, что как только я добавлю тесты, я не смогу полностью положиться на сборки GitHub. Аналогично, если я хочу добавить специальные плагины или RubyGems, попрощайтесь со сборками GitHub.
Но Трэвис-CI спасает день! Travis-CI будет следить за изменениями кода в моем репо, извлекать его, тестировать, и если он пройдет, он может переместить мою папку _site / в мою ветку GH-Pages (где GitHub будет развернут онлайн). Довольно круто, а?
Я наткнулся на эту идею от Savas Labs, которая написала в блоге прошлой осенью о том, как они развернуть на GitHub Pages с помощью Travis-CI , Они были не первыми, но мне понравились некоторые идеи, которые они использовали. Они будут вводить запросы извлечения в исходную ветвь, тестировать ее и развертывать в основной ветке для GH-страниц на основе результатов тестирования. Я последовал примеру. Я внес некоторые изменения в скрипты, например, как я кеширую разные каталоги и полагаюсь на встроенные версии Node.JS, но идея остается той же.
Я на самом деле немного горжусь этим, но мое время сборки сейчас составляет около 1½ минуты, а развертывание занимает всего 15 секунд. Это было достигнуто путем:
Читать дальше на Travis-CI кеширование документов ,
AMP Pages
Начиная с середины 2016 года я хотел реализовать AMP ( ускоренные мобильные страницы ) на моем сайте. В случае, если вы не знали, это упрощенная версия веб-страницы, сильно оптимизированная для мобильного рендеринга и сокращения времени загрузки. Он также имеет свои особые ограничения.
Если бы было что-то, что могло бы ускорить работу в Интернете для любых читателей, мне было бы интересно. Моя самая большая проблема заключалась в том, что Jekyll еще не реализовал несколько макетов. Это означало, что мне нужно было полагаться на внешний плагин для генерации страниц AMP. Хорошо, что я настроил Travis-CI!
Я повернулся к Усилитель-Джекил (который теперь является RubyGem!), чтобы добавить макет AMP. Было несколько небольших изменений, которые мне нужно было сделать. Я должен был понять, как правильно добавить видео удалите страницы AMP из моей карты сайта и измените канонический URL на моих страницах AMP, используя Jekyll-SEO-Tag.
AMP Sitemap Conflict
Во избежание дублирования результатов AMP-страницы не необходимо в карте сайта если они не являются отдельными страницами. Ссылка на них в <head> обычной страницы достаточно. Так как Джекил-карта сайта ничего не знал о моих амбициях AMP, мне пришлось вручную установить значение по умолчанию в моем front-mater макета amp.html, чтобы они не были включены.
_layouts / amp.html
--- макет: amp карта сайта: ложь ---Достаточно просто.
AMP SEO Исправления
Затем мои страницы AMP конфликтовали с Джекил-SEO-Tag , Каждая страница AMP будет содержать свой канонический URL-адрес как таковой, хотя в действительности она должна ссылаться на обычную версию веб-страницы.
Это было решено путем обмана. Я называю это обманом, потому что это не надежное решение. Если я когда-нибудь включу site.ampdir в мои SEO-теги на странице AMP, этот текст будет удален.
Новый метод изменения канонического URL-адреса на страницах AMP достигается путем удаления первого экземпляра site.ampdir из моего page.url на страницах, макет которых имеет тип amp. Затем я перестраиваю каноническую ссылку в том же формате, что и Jekyll SEO Tag, и обновляю JSON-LD с помощью небольшого фильтра замены.
Если мой канонический URL страницы AMP содержал / amp, вот так:
HREF = "https://www.kyleniewiada.org/amp/blog/2017/02/improving-jekyll-2017/"Теперь это будет изменено на:
HREF = "https://www.kyleniewiada.org/blog/2017/02/improving-jekyll-2017/"Всякий раз, когда я хватаю тег SEO, я сначала проверяю свой «парсер», чтобы исправить это. Вот как я это делаю.
_includes / амп-check.html
{% capture seo_text%} {% seo%} {% endcapture%} {%, если включить. src == "SEO"%} <! - Предполагается, что AmpDir всегда является первым экземпляром в page.url в зависимости от того, как его создает amp-jekyll -> {% assign canonical_amp = page. URL | absolute_url%} {% assign canonical_amp_removed = страница. URL | remove_first: site.ampdir | absolute_url%} {{seo_text | replace: canonical_amp, canonical_amp_removed}} {% endif%}Теперь все, что мне нужно сделать, это вызвать Jekyll-SEO-тег с {% include amp-check.html src = "SEO"%} в <head> моего макета. Задача решена.
AMP Видео
Видео AMP требует немного изящества для реализации. У них должен быть специальный файл JS, загруженный в голову, и они должны следовать правильному руководство по усилителю видео ,
Исправление <Head>
Чтобы получить этот специальный файл JS , я решил, что самым простым способом будет добавить переменную frontmatter в каждое сообщение, указывающее, какие специальные файлы AMP JS необходимы. Тогда я бы проверил это в <head>. Например, сообщение в блоге со встроенным видео будет иметь:
Тогда макет AMP <head> будет включать:
_includes / амп / head.html
{% if page.amp содержит 'video'%} <script async custom-element = "amp-video" src = "https://cdn.ampproject.org/v0/amp-video-0.1.js"> </ скрипт> {% endif%}Исправление поста
Теперь, когда у <head> были правильные зависимости, мне пришлось выяснить, как встроить видеофайл в мой блог, подходящим образом для каждого макета страницы.
Это было достигнуто с помощью небольшого включения, которое получило бы параметры из поста с указанием типа видео и других специальных свойств.
Я бы добавил видео к своему сообщению с:
{% включают видео. html src = "/assets/files/2016/03/bug_example.mp4" poster = "/assets/files/2016/03/bug_example_poster.png" controls = "loop"%}Тогда видео включает в себя правильно вставить видео для AMP и макетов по умолчанию.
_includes / video.html
<! - Способ реализации AMP-Video. -> {% назначить высоту = включить. высота | по умолчанию: "420"%} {% assign width = include. ширина | по умолчанию: "700"%} {% assign type = include. тип | по умолчанию: "normal"%} {%, если тип содержит 'normal'%} {% if page. layout == 'amp'%} <amp-video height = "{{height}}" width = "{{width}}" poster = "{{include. poster}}" layout = "отзывчивые" элементы управления {{include , элементы управления}}> <div fallback> Ваш браузер не поддерживает видео HTML5 </ div> <source type = "video / mp4" src = "{{include. src}}" /> </ amp-video> {% else%} <video width = "{{width}}" control {{include. элементы управления}}> <source src = "{{include. src}}" type = "video / mp4" /> <p> Ваш браузер не поддерживает видео HTML5 </ p> </ video> {% endif%} {% endif%}В приведенном выше коде сначала проверяется, является ли тип видео из поста «обычным» встроенным видео или видео YouTube (не показано). Затем он проверяет, имеет ли макет веб-страницы тип amp. Если это также верно, то он вставит правильный HTML-макет для видео AMP. В противном случае будет вставлено видео с обычным HTML5.
Вы можете найти более подробную информацию или любые обновления моей реализации на репо вики ,
Результаты
Теперь, когда я запускаю тесты amphtml-validator, все мои AMP-страницы проходят.
Запуск AMP Validator ... _site / amp / blog / 2013/04 / где-то для запуска / index.html: PASS _site / amp / blog / 2013/09 / restoring-vintage-with-3d-printing / index.html : PASS ... _site / amp / blog / 2016/07 / fixing-no-google-profile-for-contact / index.html: PASS _site / amp / blog / 2017/01 / back-up-android-nougat- cats / index.html: PASS AMP Validator успешно завершен.Объяснение моего метода тестирования находится ранее в этом посте.
Другие улучшения
Помимо тестирования / сборки, я внес несколько других улучшений в свой веб-сайт. Я исправил конфликты со страницами AMP и другими плагинами, добавил вики к репозиторию сайта и выпустил небольшое графическое обновление с использованием фирменного стиля и баннеров.
Плагины
Ранее в этом посте я говорил о том, как я использовал Travis-CI для создания и развертывания моего сайта. Сборка за пределами GitHub предоставила мне свободу использовать мои собственные плагины или RubyGems вместо того, чтобы ограничивать себя GitHub-страницы допустимые зависимости , Один из них я уже упоминал; Усилитель-Джекил. Это использовалось для реализации макета AMP в моих сообщениях в блоге.
Единственный пользовательский RubyGem, который я использую, - это Jekyll-SEO-Tag. Ну ... вилка Jekyll-SEO-Tag. То есть, пока они, надеюсь, не примут мою тянуть запрос , Мой запрос на извлечение исправляет и обновляет JSON-LD для сообщения в блоге, чтобы соответствовать текущим рекомендациям Google. Но сейчас у меня есть особая запись в моем Gemfile, указывающая на мою форк.
Gemfile
group: jekyll_plugins do git 'https://github.com/aav7fl/jekyll-seo-tag.git' do gem 'jekyll-seo-tag', ветвь: 'testing' конец конецСайт Wiki
Я добавил вики на мой сайт репо чтобы другие могли создать свой собственный проект с моего сайта, если бы захотели. Кроме того, файл README.md для моего репо становился слишком большим, чтобы включать всю информацию о том, как создавать, настраивать и развертывать мой веб-сайт. Это означало, что я мог вносить отдельные изменения в документацию, не добавляя еще один коммит кода.
Меньше кода больше
Наконец, я внес существенные улучшения в CSS, улучшил макет веб-страницы и исправил оставшиеся ошибки, которые мог найти (глядя на вас, MS Edge…). Ниже приведен довольно полный список основных изменений, которые я сделал. Они не заслуживают своего отдельного раздела, но все же стоит упомянуть
- Убран CSS нормализован / сильно упрощен
- Удалена сложная навигация по заголовкам JavaScript (только для CSS3)
- Переключил пост-навигацию и нижний колонтитул, чтобы использовать Flexbox, который быстро сворачивается
- Переключено на теги HTML5 (<main>, <article>, <footer>)
- Исправлены ошибки изображения баннера SVG, которые существовали в Edge / IE и iOS Safari
- Edge / IE не будет отключать баннер SVG, если он удовлетворяет следующим условиям:
- Установить как фоновое изображение CSS
- Отображается с background-size: cover;
- Растянуто слишком широко (оно исчезнет сразу). Это было решено добавлением x = "0" y = "0" к тегу <filter> в моем SVG-файле. Что за ошибка ...
- iOS Safari будет отображать баннер с дымчато-белой дымкой при использовании фильтра Gaussian Blur, поскольку он каким-то образом конфликтует с фоновым слоем. Это было решено удалением фоновой заливки из SVG и обработкой этого фона <DIV> :.
- Edge / IE не будет отключать баннер SVG, если он удовлетворяет следующим условиям:
- Добавлены наборы значков (например, Apple-Touch-Icon) с использованием RealFaviconGenerator с обновленными цветами
У меня было упоминание читателя WebsitePlanet альтернатива RealFaviconGenerator. WebsitePlanet генерирует кучу разных размеров одновременно; так что имейте это в виду, если один сайт делает это лучше, чем другой.
Заключение
Как бы я ни старался оставаться полностью в экосистеме GitHub Pages, это не соответствовало моим потребностям. Но это было хорошо. Это дало мне возможность ознакомиться с другими средами сборки и другими инструментами, которые раньше были недоступны. Это дало мне возможность взглянуть на другие проекты с открытым исходным кодом, узнать об их процессе и внести свой вклад в мою собственную работу.
Если у вас есть какие-либо вопросы или сомнения по поводу того, как или почему я что-то сделал, или у меня не было ясного объяснения, не стесняйтесь комментировать об этом ниже, и я постараюсь ответить вам.
Как бы я проверить вещи?Круто, верно?
Нуль?
Довольно круто, а?
