tl; dr, если вы думаете об использовании «бесплатного конструктора сайтов», не делайте этого. Платите кому-нибудь, чтобы он построил вам хороший статический сайт.
Если вы знаете кого-то, кто думает о том, чтобы использовать его, скажите им, что нет, и предложите построить его для них, если можете, или предложите кого-нибудь.
Если вы разработчик JS и ваша первая мысль - какой фреймворк мне использовать… подумайте о статическом сайте, я рекомендую Hugo #savetheweb
Задний план
Когда мой сосед по дому (для удобства они теперь будут называться H) рассказал мне о своем новом сайте спортзала, и я загрузил его на свой iPhone 6 по Wi-Fi, я смотрел на белый экран, возможно, 8 секунд ... что было странно , не похоже, что в этом было много чего. Так что я снова включил его на моем MBP по Wi-Fi, и это не сильно отличалось. Как и вы… Я посмотрел на сеть / график… и был поражен 😮
Запах
Чтобы быть ясным, чтобы отобразить одну статическую страницу с несколькими словами и парой изображений
… Скачиваем весь интернет… 9 раз…
… Как только я увидел react, mobx, lodash, bluebird, zepto и еще ~ 181 запрос на рендеринг этой простой страницы, упорный JS-разработчик во мне должен был согласиться с тем, что есть такая вещь как слишком много JavaScript.
Написанный с использованием одного из тех «веб-сайтов для« бесплатных »… чрезвычайно больших» вещей (с этого момента УЖАСНЫЙ), этот сайт делает все возможное, чтобы оставить в Интернете дурную репутацию.
В технологическом пузыре, в котором я живу, разделение кода, критический CSS, критический путь в целом, кеширование, сервис-воркеры, PWA, художественное оформление, адаптивный / гибкий блок / макет сетки, прогрессивное улучшение / постепенная деградация, веб-общий доступ , инструменты скорости страницы, CDN, http / 2 до бесконечности широко обсуждаются / известны и реализуются.
но все еще…
Вы можете заплатить деньги, чтобы получить это:
Я обычно обнаружил, что вы ждете ~ 1, чтобы получить ответ с их бесплатным хостингом! Затем мой MBP перебирает весь этот JS в течение ~ 2 секунд, давая вам что-то ~ 4 секунды. Если я задросселирую до 3g …………………………………………………………………………………………………………………… ………………………………………………………………………………………………………………. Требуется ~ 18 секунд белого экран, давая вам удовольствие от логотипа на ~ 22 с.
В мире, где все болтают о высокопроизводительных PWA и соперничестве с нативными, определенно действуют веб-саботажники, и это меня очень огорчает.
99 проблем
Я просто добавлю сюда шрифт, ох, какой хороший шрифт!
Помимо плохого хостинга, когда вы создаете что-то с УЖАСНЫМ, все не намного лучше. К сожалению для пользователя, нет большого мигающего предупреждающего сообщения: «Это добавит единицу к великолепному восприятию белого экрана». Фактически, в AFAICT вообще нет масштабирования страниц, где каждое перетаскивание должно накапливать немного больше на шкале, ясно показывая неспециалисту, что они делают с конечным продуктом с точки зрения производительности.
H сказал: «Но это же Интернет, люди ждут». Затем я показал ему другой сайт, который загружался примерно за 200 мс, и он был потрясен. В то время как мы привыкли ко всему быстро и по требованию в остальной части нашей жизни, очевидно, что Интернет получает бесплатную поездку в умах некоторых людей, не делайте этого, если сайт работает медленно, поднимайтесь, не давайте их обычай 😐 (это явно сурово и, вероятно, накажет того, кто не знает ничего лучшего, но общее мнение все еще остается в силе)
И дело не только в перфомансе. УЖАСНЫЕ также поощряют плохой UX, настаивая на гамбургер-меню, странностях с кнопками браузера назад и вперед и ужасных мобильных модальных окнах. Как будто они думали, что после того, как пользователь полжизни пялился на белый экран, давай по-настоящему разозлим их 😆
Непрофессионал не знает UX, и, к сожалению, многие профессиональные дизайнеры не специализируются на нем, поэтому ответственность ложится на УЖАСНЫХ…
Я подумал об этом пару дней и пришел к выводу, что это во многом загадка, окутанная парадоксом. Непрофессионал не может собрать свой собственный конвейер и написать код от руки. Сайты, которые являются «самыми громкими» и «простыми в использовании», создают раздутые динамические SPA, которые пытаются удовлетворить потребности каждого. Так что для непрофессионала у них нет понятия о хорошем сайте, но они разочарованы УЖАСОМ и даже не знают об этом, но это намного дешевле, чем нанять подрядчика, который, честно говоря, может или не может сделать хороший сайт, в зависимости от их знаний ... и все это способствует восприятию того, что Интернет должен работать медленно.
Ответ
Итак, H упомянул, что он хотел кодировать раньше, и я почувствовал, что это была хорошая возможность познакомить его с тем, что я считаю «неправильным» в исходном сайте (далее ОС) и других сайтах, которые он создавал с таким же УЖАСОМ. Затем я мог бы отразить ОС, показать ему собранный мною технический стек, познакомить его с HTML и CSS и вообще научить его как бы ловить рыбу.
Это также дало бы мне представление о том, как люди, не являющиеся техническими специалистами, думают о сети и какие приоритеты они ставят при создании небольшого веб-сайта и т. Д., Потому что я никогда раньше не выполнял такую роль, обращенную к клиенту.
Надеюсь, этот пост в блоге, моя версия ОС и обучение H внесут еще один небольшой вклад в «решение».
Пасхальные выходные
Что мне делать - React или Mithril… никогда не приходил мне в голову. Сайту действительно не нужен JS-фреймворк ... но тогда я не могу использовать React 😔 ... поэтому я сразу перешел к gatsby #obvs. Однако, немного поиграв с ним и увидев результат, я понял, что это был не тот DX, который я искал, и конечный результат оказался не таким чистым, как я ожидал.
Я вспомнил потрясающую журнальную статью, которую я читал некоторое время назад на статичных сайтах, и что Хьюго использовал голанг, что дало мне возможность снова связаться с ним. Я нашел сайт и документацию фантастическими, cli - мечтой, сервер невероятно быстрым, и он буквально выводит твердый, чистый HTML без веб-пакета. Принято решение.
Без внешнего интерфейса я, очевидно, собирался поместить весь код в GitHub как для контроля версий, так и для справки, и определенно собирался использовать AWS, потому что AWS. Остался только бит посередине.
Я хотел использовать то, чем раньше не пользовался, просто чтобы узнать еще больше 😜 и Codeship соответствовал (жирно?) Счету. Бесплатно и легко в использовании, отметьте, отметьте, готово. Я назову это… стеком CHAWS.
Хьюго - ›GitHub -› Кодирование - ›S3 -› Cloudfront - ›Route 53
H подумал, что это слишком суетливо и много деталей, но на самом деле, выбирая службы, которые хорошо справляются с одной задачей, вы получаете что-то гораздо более простое. И УЖАСНОЕ свидетельствует о том, что попытки быть мастером на все руки не работают.
Меня не беспокоит масштабирование, кеширование, безопасность, веб-пакет или разделение кода, или какие стили реагируют на использование библиотеки стилей. Как ни странно, я продолжал сталкиваться с сообщениями в блогах от разных людей, которые также использовали один и тот же стек, когда у меня были «технические трудности» Хьюго. Так что вместо того, чтобы чувствовать себя бессовестным подражателем, это укрепило мою уверенность в том, что это был разумный выбор.
Между шоколадными яйцами и едой я собрал сайт 😋
Вне сайта
Хьюго первый
Поскольку я совершенно не знаком с Хьюго, мне казалось, что вы можете создать сайт на «верхнем уровне» или поместить все в тему и загрузить ее. Я пошел по пути тем, потому что, хотя я просто создавал один конкретный сайт, который вряд ли будет использоваться каким-либо образом, мне казалось, что другие темы могут быть созданы параллельно, и переключение между ними может быть хорошим вариантом, так что в основном там не было недостатков в использовании темы 🤔.
Одна из многих приятных особенностей Hugo заключается в том, что вы можете иметь данные на уровне сайта в toml и данные «главного вопроса» на каждую «страницу», которые можно использовать в этом месте. Используя шаблоны golang, вы можете легко получить доступ к данным на уровне сайта с помощью $ или ., а также передать контекст в partials.
Одна из основных причин, по которой я выбрал Hugo, заключалась в том, что он, казалось, был ориентирован только на написание HTML с использованием шаблонов golang, что было бы неплохо. Итак, немного разметки в index.html файле и немного CSS, и у меня был веб-сайт 😊.
Поскольку я экспериментировал со многими другими вещами, я не писал ничего с нуля с помощью атомарного CSS, поэтому я пошел с этим шаблоном, просто чтобы посмотреть, как он будет разыгрываться, на что похож DX и будет ли он легко подобрать H. Изначально весь CSS был в одном файле, и я сгруппировал селекторы по их поведению. Затем я использовал специальные селекторы для оперативности, то есть при разделении по медиа-запросам.
Основы
Глядя на ОС, из-за огромного количества блокирующих ресурсов вы долгое время ничего не видите, но в их дизайне главное - это простой логотип, ссылка на другую страницу и номер телефона. Чтобы увидеть это как можно быстрее, имело смысл просто нарисовать логотип вместо этого, что также означало бы, что он будет масштабироваться при увеличении. Это дало мне возможность поиграть с еще одной вещью, когда я возился с созданием концентрических кругов с рукописным SVG в поезде, и вуаля *.
* Потенциально это тоже может быть встроено, что еще не решено.
Среди всех этих блокирующих ресурсов шрифты являются особой обузой, когда они добавляются вместе с УЖАСНЫМ. Поэтому сначала я просто украл список шрифтов GitHub, он стандартный, красивый и очень производительный, без дополнительной загрузки!
Я ходил туда и сюда по поводу того, как делать встроенный CSS. Я собирался создать для каждой страницы свой собственный файл скелета (CSS для рендеринга содержимого «в верхней части страницы») и скомпилировать его в критически важный CSS, встроенный в верхнюю часть страницы. Однако у них были общие селекторы, и я использовал чистый CSS, а не Sass, что означало, что совместное использование стилей было непростым *. Сначала я просто разделил CSS-файл скелета и поместил его вверху как стандартную таблицу стилей.
* Кстати, по мере того, как я все больше и больше разрабатывал сайт, это заставляло меня думать, что что-то вроде Sass было бы стоящим, что я добавил в качестве задачи.
Одна из вещей (как и следовало ожидать от любого языка шаблонов), которое мне действительно нравится, - это использование партиалов: themes/onetwenty/layouts/partials/person.html. Это позволяет мне легко проводить рефакторинг и группировать похожий код, который H будет легче проверять и, как правило, повторно использовать и поддерживать. Затем вы можете ввести dicts, что даст вам удобный способ предоставления помеченных данных в ваш partial.
Итак, теперь у меня есть загрузка HTML, несколько изображений, мои скелетные таблицы CSS вверху каждой страницы и таблица стилей CSS каждой страницы внизу соответствующих страниц.
Отзывчивый
УЖАСНЫЙ, похоже, выполняет своего рода обнюхивание агентов и предоставляет сайт на основе устройства. Хотя в некоторых случаях это может быть проще разработать, я действительно считаю, что статический веб-сайт, такой как этот, естественно подходит для стандартных веб-практик и простых медиа-запросов. Это будущее доказывает это на любом устройстве, которое может выйти, и у вас есть полный контроль над тем, как вы хотите, чтобы ваш сайт выглядел на любой ширине. Если кому-то нравится иметь окна меньшего размера на своем столе / ноутбуке или нравится / нужно увеличить его веб-страницы, ваш сайт будет просто работать… в отличие от сайта УЖАСНОГО.
Может показаться, что я изо всех сил стараюсь делать как можно больше нового, и это потому, что это правда. Итак, очевидно, что в каждом блоге банкомат болтает о Grid Layout, в ОС есть таблица, надо ее использовать! Исходная таблица представляет собой изображение #naturally, которое плохо отображается на мобильных устройствах, заставляет вас увеличивать масштаб до нечеткого изображения и, конечно же, не работает на разных устройствах.
Наличие таблицы с днями вверху и столбцом для времени означало попытку втиснуть 8 столбцов данных размером менее 400 пикселей на мобильном телефоне. Вместо этого имело смысл помещать время в верхней части экрана меньшего размера, увеличивая количество столбцов до 6. Я также использовал трехбуквенные названия дней на меньших устройствах и более мелкий шрифт для удобства.
Этого было легко достичь с помощью спецификации сетки и media queries, это код для min: 768px:
grid-template-columns: repeat(8, 1fr); grid-template-rows: repeat(6, 1fr); grid-auto-flow: column;
Разметка остается той же, длинный список div, но способ, которым мы «заполняем» сетку, меняется в зависимости от ширины области просмотра. На iPad или более поздних версиях мы используем 8 столбцов, 6 строк и сначала заполняем столбцы.
По правде говоря, не до крайности… пока! Вы можете использовать их специальные префиксы, то есть IE10 + или вернуться к изображению…
В ОС, когда вы переходите на одну из страниц инструкторов, после некоторой задержки, из ниоткуда появляется модальное окно с их квалификациями. Это дезориентирует, странно и даже не подходит для мобильных устройств, поэтому вы не можете нажать на значок «X», чтобы закрыть его. Это определенно моя предвзятость, но я в значительной степени ненавижу все модальные окна, они всегда кажутся спамом (я только начал выбирать режим низкого заряда батареи, а не отменять его на своем iPhone), и почти всегда есть лучший вариант. В этом случае просто вставьте их в виде списка внизу ... потому что это то, что вы здесь, чтобы увидеть, а модальный режим ничего не приносит группе.
Сделай глоток!
Хьюго много делает, и он довольно полезен, но если вы хотите начать создавать интерфейсный конвейер, вам понадобятся некоторые интерфейсные инструменты, так что да, все станет сложнее.
Наша цель PageSpeed - 100/100, для достижения этой цели у нас есть множество проблем. Нам нужно объединить и минимизировать наш CSS, чтобы меньше обращений к серверу *, что означает более быструю отрисовку / более быстрый UX. Мы также хотим агрессивно кэшировать все наши активы, чтобы они были версированы, И мы хотим, чтобы наши стили скелета были встроены в верхнюю часть страницы, чтобы что-то можно было визуализировать, как только HTML будет проанализирован и созданы * OM и т. Д.
* это простой статический сайт без магии http / 2 push
Давным-давно я использовал Grunt, затем вышел Gulp, в котором использовался немного другой подход, основанный на сборщиках, который я в значительной степени отвергал для простых сценариев npm, прежде чем вернуться к веб-упаковке всего. Однако здесь я вернулся к Gulp, потому что накладных расходов было очень мало, и он делает то, что нужно нам: использует глобус, получает файлы, что-то с ними делает.
Вот задача gulp для минимизации CSS:
gulp.task(‘minify-css’, [‘clean’], () =>
gulp.src(`${CSS_DIR}*.css`)
.pipe(concatCss(‘bundle.css’))
.pipe(cssc(CSSC_OPTS))
.pipe(rev())
.pipe(gulp.dest(OUT_DIR))
.pipe(rev.manifest(‘manifestcss.json’))
.pipe(gulp.dest(`${THEME_DIR}/data`))
);
Мы собираем все это вместе, сжимаем, насколько можем *, версируем и записываем файл манифеста в каталог данных темы. Это означает, что мы можем ссылаться на нашу версию CSS в нашем шаблоне golang и экономить круговые запросы, агрессивно кэшируя весь наш CSS, независимо от того, на какой странице находится пользователь. Это может быть не для всех перфоманс, но здесь очень мало CSS, и это означает, что больше не нужно получать данные с сервера, в значительной степени «когда-либо» снова.
* компрессор был слишком агрессивным для меня, и мне пришлось отключить параметр consolidateViaDeclarations, чтобы он не засорял мои селекторы псевдозаполнителей, поэтому либо используйте какие-то тесты визуального сравнения и / или будьте очень осторожны.
Библиотеки версий CSS gulp, похоже, не позволяют вам удалить расширение из ключа манифеста, т.е. "bundle": “bundle.1234.css" вместо "bundle.css": “bundle.1234.css". Ссылка на ключ JSON, который содержит точку из шаблона golang ... оказалось большой головной болью, потому что он думает, что вы идете дерево объектов.
Я не смог найти хороший способ ссылаться на пакет CSS и, наконец, сдался (я уверен, что это просто ;-)) Этот способ имеет некоторую ценность в любом случае, если у вас есть несколько пакетов CSS в вашем манифесте ... просто переберите ключи и возьмем значения:
{{ range $key, $value := .Site.Data.manifestcss }}
<link rel=”stylesheet” href=”/css/dist/{{ $value }}”>
{{ end }}
Это задача встроенного скрипта, она захватывает скелет CSS, сжимает его и записывает значение в файл JSON в каталоге данных темы:
gulp.task(‘make-skeletons’, () =>
gulp.src(`${SKELETON_DIR}*.css`)
.pipe(cssc(CSSC_OPTS))
.pipe(fc2json(‘skeletons.json’, {
extname: false,
}))
.pipe(gulp.dest(`${THEME_DIR}/data`))
);
Затем мы можем вставить его в верхнюю часть каждой страницы, указав значение JSON (которое является текстом CSS) с помощью «скелетного ключа» 😜 и передать его вспомогательной функции safeCSS Hugo.
<style>{{ .Site.Data.skeletons.skeleton | safeCSS }}</style>
Очевидно, что большинство людей выбирают автоматизированное решение, которое может быть более гибким и оптимальным, чем мой индивидуальный подход, но таким образом было намного проще, надежнее и удобнее в обслуживании. У меня также был полный контроль над решением, что именно я хочу критиковать.
Наконец, мы хотим сделать HTML как можно меньше! Даже в мире http / 2 и множества параллельных запросов связывание может быть устаревшим, но мы все же хотим получить что-то небольшое по сети как можно быстрее и, возможно, сэкономить время на синтаксический анализ! Я использую базовый вариант для замены файлов HTML на месте, который запускается после того, как сайт был создан Хьюго.
gulp.task(‘minify-html’, function() {
return gulp.src(`public/**/*.html`, { base: ‘./’ })
.pipe(htmlmin({
collapseWhitespace: true,
minifyJS: true,
}))
.pipe(gulp.dest(‘./’));
});
n.b. Я не использовал опцию minifyJS, и позже заметил, что мои скрипты в нижней части страницы были жирными. Я добавил… и ничего не произошло. Поскольку теперь я пишу ES2015 + как зомби, я написал это в своем скрипте ... который молча потерпел неудачу ... поскольку он не использует Uglify harmony или babili ...
Сейчас сайт был в довольно хорошей форме, но мне показалось полезным поиграть с ним на разных разрешениях в инструментах разработки с дросселированной сетью, чтобы получить хорошее представление о критическом CSS, который вам нужен для того, чтобы он чувствовать себя «приятно» на все случаи жизни. Для меня это просто означало перемещение некоторых селекторов из файла CSS страниц в файл скелета.
Верите ли вы в магию?
Оценка PageSpeed стремительно росла, но, как и в большинстве случаев с оценками, которые я когда-либо видел ... изображения были неоптимальными, imagemagick на помощь (как предлагает Google).
Сначала я попытался установить его, как описано на собственном сайте инструмента… но мне не удалось заставить работать делегат jpeg. Так что мне стало скучно, я сдался и использовал вместо этого домашнее пиво 😏
brew install imagemagick and jpeg
Мне пришлось поиграть с этим, и предложение Google было 85. Я фактически снизил свое до 50, а в некоторых случаях до 20, на мой старый взгляд они выглядели примерно одинаково, я назвал их [name].opt.jpeg, а затем изменил размер оригиналов до правильное соотношение, чтобы поместиться на устройстве шириной 450 пикселей и называется это [name].sopt.jpeg.
Например:
convert hand-stands.jpg -sampling-factor 4:2:0 -strip -quality 50 -resize 120x30 -interlace JPEG -colorspace RGB hand-stands.sopt.jpg
Затем, используя элемент Picture, я загрузил один или другой, в зависимости от ширины области просмотра, и угу, PageSpeed был доволен.
Прирост, который вы получаете, на самом деле безумный: в среднем изображения opt были меньше на 25%, а домашний герой с измененным размером потерял 90% своего веса, увеличившись с 252 КБ до всего 25 КБ. В частности, лица тренера были отрезаны почти на 50%.
Для изображений sopt прирост в среднем составил около 95%, с домашним героем снизился с 252kb до 6kb !!!
JavaScript всегда будет появляться
Хотя это предприятие очень сильно против «JS-фреймворка и использования кувалд, чтобы ломать орехи» (хотя некоторые могут посчитать это полностью изощренным…), он нам все еще нужен для того, в чем он хорош, - для динамического написания сценариев и планирования работы.
PageSpeed не любит блокирующие скрипты, и теперь мой связанный CSS задерживает рассмотрение, потому что страница не может быть отрисована до тех пор, пока CSS не будет извлечен, проанализирован, создан CSSOM и применен к DOM. Здесь не было особых размышлений, я просто последовал совету Goog и использовал скромный JS в скрипте внизу страницы, чтобы вытащить таблицу стилей из блока noscript (чтобы она работала без JS) и вставить ее в страница, когда в конце цикла событий в данный момент времени есть запасной кадр анимации.
Все это означает, что основной поток не задерживается, анимация запуска не прерывается, и страница может быть показана пользователю без необходимости использования CSS «ниже сгиба».
Теперь, хотя у нас есть множество кешей (4 в Chrome) из коробки, лучшим из них является Cache Web API, потому что у нас есть большой контроль над ним, и он позволяет нам работать в автономном режиме, если у нас нет предпочтение яблочных фруктов. Я не стал добавлять такую библиотеку, как sw-toolbox, потому что она казалась ненужной, а написание собственного кода sw не так уж больно, и вам редко нужно его менять.
Благодаря моему довольно простому sw все изображения были кэшированы, пакет CSS кэшируется по запросу, страницы кэшируются в течение дня, что означает, что все может работать в автономном режиме, а с подключением это… быстро.
В ОС есть слайд-шоу, мы, вероятно, можем поспорить о его ценности ... но просто чтобы продемонстрировать, что нам не нужна дополнительная тонна JS, которую дает нам УЖАСНЫЙ, я создал один из ~ 15 строк неминифицированного JS. который находится в блоке сценария внизу страницы.
Мы уже на месте?
Нет, не совсем. Изображения по-прежнему загружались слишком долго, и CSS потребовалось немного времени, если вы загружаете сайт холодным, не имея вообще никакого кеша. Я хотел, чтобы самое первое посещение было радостью, а не только последующие, что вряд ли для этого конкретного сайта в его нынешнем виде.
Введите preload и prefetch. Эти маленькие красотки позволяют нам сообщать браузеру, даже не анализируя HTML, чтобы обнаружить, что вам нужен этот ресурс, я говорю вам, мне нужна вещь!
Мы preload вещи, которые мы знаем, что собираемся использовать на странице (и Chrome сообщит нам об этом в консоли, если мы этого не сделаем). Например, мы можем preload наш пакет CSS, что означает, что он будет получен НАМНОГО раньше, а это значит, что мы получим его НАМНОГО раньше, а это значит, что мы сможем раскрасить страницу НАМНОГО раньше.
<link rel=”preload” as=”style” href=”/css/dist/{{ $value }}” onload=”this.rel=’stylesheet’”>
Я оставил отложенный хакерский CSS на всякий случай.
На слабом телефоне при плохом соединении вы можете видеть, что пакет CSS не начинает загрузку до ~ 35 секунд, а это значит, что мы не видим синего поля до ~ 40 секунд.
Тогда как здесь мы получаем пакет сразу, а логотип и поле могут отображаться «всего» через ~ 10 секунд.
На домашней странице я тоже делаю что-то вроде этого:
<link rel=”preload” as=”image” href=”/images/hand-stands.opt.jpg”> <link rel=”prefetch” href=”/images/home-hero.ropt.jpg”>
который гласит: загрузите мне изображение главной домашней страницы как можно скорее, но также принесите мне героя для страницы «О нас», потому что для нас это единственное другое место, куда вы можете пойти. Пока нет больших накладных расходов на его получение (http / 2 параллельно innit), мы можем также получить его, чтобы мы могли мгновенно отображать его из нашего sw, когда пользователь переходит на страницу about. Эти очень простые подсказки действительно имеют большое значение, особенно в Chrome и, конечно, при плохом сигнале на телефоне низкого уровня.
Мы можем видеть, что без prefetch или preload для перехода с домашней страницы на верхнюю часть содержимого на сильно ограниченном телефоне низкого уровня требуется ~ 34 секунды.
С помощью pre* вы можете увидеть, что двух полосок не существует, потому что они уже были загружены и кэшированы на главной странице, и мы можем добраться до скелетного содержимого чуть более чем за 4 секунды!
С сервисными работниками наш младший телефон быстро загружает страницу, но для того же перехода требуется менее ~ 3 секунд.
Наконец ... поскольку H хотел добавить несколько шрифтов, я их тоже вставил, но с preload, так что между страницами есть только очень небольшая вспышка (в Chrome), потому что я считаю, что он рисует без веб-шрифтов, затем применяется и перекомпоновывается впоследствии . Ингредиенты сидра не такие кричащие.
<link rel=”preload” href=”/fonts/roboto-regular.woff2" as=”font”>
… И сайт построен!
Развертывать
Изначально я выбрал Codeship, потому что он дает мне интеграцию с S3 из коробки, когда я нажимаю на GitHub, и это прекрасно. Однако ... оказывается, это было не совсем то, что мне нужно. Я не мог передавать пользовательские флаги в сценарий S3, и я не мог установить Hugo с govendor в контейнере Ubuntu. Вы также не можете использовать sudo apt-install в бесплатном пакете. Вздох 😒.
Чтобы обойти мои проблемы с Hugo, в сценариях установки я загрузил дистрибутив и вручную распаковал его, я не знаю, есть ли лучший способ, но все это кэшируется AFAICT, и большинство шагов по установке занимают ~ 1,5 секунды бежать.
wget https://github.com/spf13/hugo/releases/download/v0.20.1/hugo_0.20.1-64bit.deb ar x hugo_0.20.1–64bit.deb tar xvzf data.tar.gz ./usr/bin/hugo version
Это просто оставляет фактическую сборку сайта, которая использует yarn для получения пакетов и зависимостей gulp, красиво и быстро, создает CSS, создает сайт, минимизирует HTML на месте
npm run build-css ./usr/bin/hugo npm run build-html
Что касается моих проблем с S3, я тоже скатал его вручную.
pip install awscli aws s3 sync public/ s3://one-twenty/ — acl=public-read — delete — cache-control=”max-age=1576800000" — exclude “*.html” — exclude “sw.*.js” aws s3 sync public/ s3://one-twenty/ — acl=public-read — delete — include “*.html” — include “sw.*.js”
здесь я могу синхронизировать свою корзину S3, применять заголовки cache-control на 1 год ко всему, что является версионным и неизменным, то есть не моим HTML и sw.
От перехода к мастеру до обновления моей корзины S3 - это огромные… 45 секунд. Конечно, здесь нет тестов, и это довольно простой сайт ... но все же это отличное решение с использованием полностью бесплатного стека.
Tiswas AWS
У нас есть суперпростой сайт и плавный конвейер, который выводит его на S3. Здесь мы можем сказать, что это статический веб-сайт, и указать его на index.html. Если мы возьмем URL-адрес, который нам дают http://one-twenty.s3-website.eu-west-2.amazonaws.com/, и пропустим его через PageSpeed, мы не получим 100/100 🙄 Мы По-прежнему отсутствует сжатие.
Кроме того, ему приходится каждый раз извлекать эти ресурсы из нашей корзины в Западной Европе для каждого посетителя, что далеко не идеально.
Итак, что нам нужно, так это CDN с множеством других преимуществ (HTTPS (который нам нужен для нашего ПО), региональные пограничные кеши (то есть меньше переходов), апексирование зоны, http / 2)… например, Cloudfront.
Настроить дистрибутив Cloudfront очень просто и практически не нужно объяснять. Единственное, что меня сбивало с толку, иногда настройки не сохранялись, и требуется день (по умолчанию) для закрытия пограничного кеша CDN, так что вам нужно… подождать. Например, я установил «Автоматически сжимать объект» (gzip), но он не сохранил его, поэтому мне пришлось подождать день, чтобы обнаружить это, затем исправить это, а затем еще день. Я считаю, что вы можете принудительно аннулировать объекты, но мне это не доставляло особых неудобств. Да, и вы можете подумать, что установка настраиваемого TTL означает, что он устанавливает для вас cache-control заголовки ... чего не делает, поэтому они находятся на самих объектах S3, а затем вы должны использовать параметр заголовков прямого происхождения.
Вот и все ... почти.
Сан-Франциско в Чикаго
Итак ... еще не сделали часть Route 53, так как это то, за что вам нужно заплатить ... и мы можем сделать так много бесплатно 😬
Наши оценки PageSpeed составляют 100/100 для всех страниц (кроме /about из-за карт Google и невозможности контролировать cache-control заголовки, потому что у нас нет обратного прокси для их применения, например), и H на уроке четыре, где мы собираемся узнать, что такое IDE…
Мы также наглядно продемонстрировали, насколько просто и легко создать веб-сайт, который сможет сделать буквально каждый, тем самым сохранив Интернет, ну, 2/3 - неплохо.
