Monbanquet.fr и великий Гэтсби

Еще в декабре 2018 года Я выступал с докладом (на французском с английскими субтитрами 🇬🇧) на первой конференции JAMstack в Париже. Это не стенограмма, а письменная история отзывов, которые я дал.

Сказка о заставке

В сентябре нашей компании Monbanquet.fr пришлось покинуть наш тогдашний веб-сайт. К этому решению подтолкнули многочисленные потребности. С точки зрения бизнеса, цель заключалась в том, чтобы прояснить предложение сайта и получить простой способ заказать банкет. Технически нам нужен эффективный, оптимизированный для SEO, красивый веб-сайт. Я имею в виду, а кто нет? Верно, но на самом деле, похоже, именно этими критериями часто пренебрегают при работе с дедлайном.

Для тех, кто не знает Monbanquet.fr. Мы - французский стартап, базирующийся в Париже и Лионе, который стремится дать индустрии общественного питания новый опыт, работая с местными ремесленниками, такими как мясники, пекари и сыроделы. Благодаря им мы предлагаем невероятно свежие продукты для всех ваших деловых мероприятий (завтраки, коктейли, семинары и многое другое).

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

Имея это в виду, поток заказов стал довольно простым:

главная страница → страница мероприятия (например, завтрак) → модальный заказ → заказ отправляется в нашу систему управления продажами.

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

Вот его ревизия по скоростям 3G

Действительно, мы отправили довольно много JS, в том числе, но не ограничиваясь: angular, ngrx (система управления состоянием, подобная redux), angularfire2 (клиент для firebase), moment (библиотека манипулирования датой) , Lodash (библиотека функций служебного пояса).

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

Создать (хороший) сайт сложно.

Это утверждение может варьироваться в зависимости от вашего определения «веб-сайта». Но создание действительно отличного веб-сайта требует много времени и навыков. Признавая, что у вас есть второе, первое - вариант редко. Либо у вас впереди недели и месяцы, либо у вас есть большая команда, готовая вместе справиться с задачей, сокращая время, необходимое для запуска вашего сайта. Когда у вас нет ни того, ни другого, у вас есть несколько вариантов:

  • Положитесь на инструмент, который создаст для вас веб-сайт.
  • Срезайте углы и повышайте качество

Оба варианта - плохой выбор для компании, у которой уже есть * рабочий * веб-сайт. Здесь «работа» носит чисто технический характер: он отображает материал, и люди могут с ним взаимодействовать. Использование инструмента для воссоздания веб-сайта, вероятно, не заставит нас улучшить нашу игру с точки зрения дизайна, эргономики и производительности.

Создать хороший веб-сайт должно быть так же легко, как и плохой (если не проще).

Сейчас это не так. Для меня основные составляющие того, что делает веб-сайт приятным (если не учитывать бизнес-требования):

  • Скорость, реальная и мнимая
  • UI и анимация

В основном я буду говорить о скорости, но вернусь немного к анимации в конце этого поста.

Становится статичным

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

Как я упоминал в своем выступлении, я не углублялся в сравнительную таблицу из двадцати семи фреймворков, прежде чем остановился на Гэтсби, тесты являются сложными и требуют много времени, и вы никогда не можете быть уверены в своем выборе. Я уже несколько раз пробовал Gatsby на личном проекте, и первое, что привлекло мое внимание, - это его простота. Установка прошла безболезненно, и у меня была рабочая страница менее чем за 10 минут - npm install прилагается. После небольшого дополнительного исследования эти аргументы убедили меня.

  • Это реакция, просто старая реакция
  • Он статичный, серверов нет
  • У него отличная документация
  • Имеет растущее и активное сообщество
  • Это не зависит от данных (не важно, откуда берется контент)

Этого было достаточно, чтобы я попробовал еще немного. Поскольку я просто React, я всегда мог повторно использовать свои компоненты, если что-то пойдет не так. Но я был уверен, что видел сообщество и отличную работу команды Гэтсби, чтобы помочь людям начать работу. Давайте погрузимся.

Путь Гэтсби

Одним из интересных моментов Гэтсби является то, что он не навязывает формат данных. Его не волнует, поступает ли контент вашего сайта из блога WordPress, из серии файлов разметки или из любого другого API. Он предоставляет вам простой способ написать исходный плагин. Все эти данные, независимо от того, откуда они берутся, вводятся через запросы GraphQL в ваши реагирующие компоненты, составляющие ваши страницы. В конце концов, все, что у вас есть, - это статическая папка public /, готовая к развертыванию. Это простой простой HTML, CSS и Javascript.

Вот как это работает (с их домашней страницы)

GraphQL

Раньше я не знал GraphQL, за исключением твитов и статей, но это прошло как шарм, особенно благодаря интеграции graphiql, игровой площадки, которую Гэтсби раскручивает, пока вы разрабатываете, чтобы помочь вам возиться с запросами.

Я часто получаю реакцию, когда говорю, что Гэтсби использует GraphQL:

Но я не знаю GraphQL и не хочу тратить время на его изучение, тем более что это относительно новая идея.

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

Итак, как GraphQL используется в Gatsby и как это помогает?

Для меня это был тот факт, что независимо от того, откуда поступали данные (файлы JSON, API…), они были доступны из одного и того же простого интерфейса, подобного JSON. Используя плагины, я получал контент как из Contentful, так и из локальных файлов без необходимости реализовывать HTTP-запросы, управлять файловой системой и выполнять некоторые работы, чтобы собрать все это в одну согласованную переменную, готовую для использования приложением. Конечно, эта выборка и сборка происходят за кулисами и выполняются плагинами. Я считаю этот подход очень чистым, поскольку он не загрязняет ваше приложение нерелевантным и часто подробным кодом. Тем не менее, вы можете создать свой собственный плагин для своих нужд, и он на удивление прост и хорошо документирован (или посмотрите это живое кодирование 🇫🇷 от Николаса Гоутае).

Вишенка наверху, набрано GraphQL. Для любителей печатать это очень удобно. При получении ваших данных Гэтсби попытается определить их тип и создать для него схему GraphQL. Он работает довольно хорошо (но имеет некоторые ограничения) и может, например, помочь вам создавать с его помощью типы TypeScript.

‹GatsbyLink› и предварительная загрузка

Когда я говорю о статической генерации, я иногда получаю такую ​​реакцию:

«Круг замкнулся, мы вернулись к полноэкранному веб-сайту, отображаемому на стороне сервера».

Это не совсем неправда, но мы хотим использовать лучшее из обоих миров SSR и SPA, и GatsbyLink помогает нам в этом. Вместо классического тега привязки это усиленная ссылка (хотя это все еще ‹a href="…………………………………………………………………………………………………………………………………………………………………………………………… нажмите на ссылку.

Это делается путем загрузки следующей страницы в виде пакета Javascript, а не документа HTML. Идея состоит в том, чтобы заменять компоненты на лету без необходимости повторного рендеринга всей страницы.

Вы можете увидеть это в действии, когда я наводил курсор на разные ссылки на странице.

‹GatsbyImage› и разрешения

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

Если вы ранее пытались правильно реализовать теги image / picture, вы знаете, как сложно использовать тег ‹picture› и атрибут srcset со всеми указанными файлами разрешений.

Это не только требует времени, чтобы написать, но и создавать изображения любого размера и разрешения. Некоторые онлайн-сервисы могут сделать это за вас, но что, если вы не хотите пользоваться дорогостоящими услугами? Gatsby снова помогает вам здесь, используя свои плагины. Используя gatsby-plugin-sharp, все необходимые разрешения и размеры будут созданы и переданы вам в красивом стиле GraphQL. В конце концов, приведенный выше код был сгенерирован этим небольшим фрагментом:

Вы можете спросить, зачем нам все это делать. Почему бы не добавить простой сингл ‹img src =”… ”/› и баста? Ну ... просто потому, что от этого страдают ваши пользователи. Изображения не оптимизированы для всех устройств, размеров экрана и сетевых подключений. В то время как с gatsby-image браузер может решить, какой источник показывать на основе этих критериев, обеспечивая быстрое взаимодействие с пользователем, в то время как Gatsby помогает разработчикам.

У нас есть все, что касается скорости, ура! Но подождите, gatsby-image идет дальше. Он не только выбирает наилучшее доступное разрешение, но и загружает его лениво и визуально прогрессивно. Есть два метода, доступных с gatsby-plugin-sharp и gatsby-image.

Первый называется traced-svg и заключается в создании контура изображения, которое вы хотите отобразить в качестве заполнителя, пока загружается реальный объект. Здесь вы можете видеть, что когда я перезагружаю страницу, SVG ненадолго отображается перед тем, как изображение заменяет его.

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

Здесь вы можете наблюдать за эффектом размытия в действии, а также за отложенной загрузкой изображений, когда они попадают в область просмотра.

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

Плагины Moaaaaar

Я знаю, что это пугает и напоминает дни jQuery, когда в каждой библиотеке был плагин jQuery. В Gatsby плагины лежат в основе экосистемы. Они позволяют создавать и формировать контент до того, как он попадет в ваши компоненты.

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

После этого полный шрифт по-прежнему загружается асинхронно для обработки любого возможного динамического содержимого. Но ваш первый рендер должен быть значительно более быстрым и уменьшать FOUT. В конце концов, мы сократили примерно 50 КБ неиспользуемых символов шрифта при первом рендеринге, что немаловажно.

Примечание об анимации / взаимодействиях

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

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

Обычно анимация является долгожданным дополнением к некоторым действиям пользователя и редко бывает нужна сама по себе. Например, вы, вероятно, не будете анимировать строку меню случайным образом, из ниоткуда и без причины. Но вы можете заставить его появиться по-разному одним нажатием кнопки.

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

Пользоваться этой библиотекой было приятно, и она стала глотком свежего воздуха. Я не буду вдаваться в подробности реализации здесь (тема для более позднего сообщения), но просто знаю, что компонент Drawer и вся его логика взаимодействия охватывают не более 50 строк кода. Это включает сенсорное управление умение обращаться. Мы опубликуем код, как только он будет готов.

Добавление жестов пользователя и реагирование на них еще никогда не было таким простым и обычно занимает всего несколько строк (тем более с выпуском хуков реакции). Я рекомендую вам внимательно изучить, как сделать ваш сайт более живым с помощью этих двух пакетов, вы не пожалеете об этом. (Большое спасибо Пол)

Строить. Развертывать. Повторить.

Теперь, когда у нас есть хорошее представление о том, как Gatsby помогает разработчикам создавать отличные и быстрые пользовательские интерфейсы, как нам все это объединить? Как мы доставим все это чудо?

Ответ зависит от вас, вашего выбора, вашего стека и вашей команды. На Monbanquet.fr мы остановились на Contentful и Netlify. Они отлично подходят для наших сценариев использования. Вот аргументы, которые заставили нас зачислить:

Довольный

  • Имеет веб-интерфейс
  • Только контент, без стиля
  • Имеет плагин Гэтсби
  • Это отличное место для размещения фотографий
  • У него есть щедрый бесплатный уровень

Netlify

  • DX потрясающий (вывод сайта в сеть занял самое большее 5 минут)
  • Он строится и развертывается при каждом нажатии git.
  • У него есть URL-адрес для каждой сборки фиксации и каждой ветки
  • У него есть веб-перехватчики для запуска сборки извне.
  • Имеет сплит-тестирование на основе ветвей.
  • У него есть щедрый бесплатный уровень
  • Еще много интересных функций, которые мы еще не пробовали. (Формы, личность…)

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

Содержательное изменение → Триггеры строятся на netlify через веб-перехватчик → сайт развернут

Изменение кода → Триггеры на netlify с помощью git push → сайт развернут

В своей презентации я упомянул, что это обошлось нам в 0 евро. Это, очевидно, без учета времени разработки. Что все еще было относительно низким. Создание (правда, простого) веб-сайта, над которым работал только один человек, заняло всего 2 месяца (включая дизайн). Это довольно приятная сделка, если вы спросите меня, учитывая:

Производительность… проверяется. SEO… проверил. Мобильное взаимодействие… нативное. Управление контентом… проверено. Хостинг и процесс сборки… быстро и легко. Времени на обучение… почти ноль. Стоимость SaaS… 0 €.

Заключение

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

Является ли будущее Monbanquet.fr статичным?

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

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

Спасибо за прочтение!

Спасибо, Чарли Поли за ваш отзыв и помощь!

Следите за нашими постоянными разработками в твиттере @dot_louis и @monbanquet

Слайды: https://slides.com/dotlouis/deck-13

Доклад (на французском 🇫🇷 с субтитрами на английском 🇬🇧): https://www.youtube.com/watch?v=xLQ4to7Ubn0

#UX #UI #static #webdevelopment #gatsby #jamstack #speed #easy # react-spring # react-use-gesture #animations