25 лучших советов по созданию сверхбыстрого сайта!!!

Недавно я провел прямой эфир, в котором рассказал о том, что, по моему мнению, «25 лучших» вещей, которые я сделал для своего сайта (dustinbrett.com), чтобы сделать его «БЫСТРЫМ». Видео длится более 2 часов, поэтому я смог рассказать о нем достаточно подробно. Встроенное видео находится внизу этой статьи.

В этой статье я постараюсь кратко описать каждый совет и добавить скриншот/ссылки.

1. Сеть доставки контента (CDN)

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

В случае с CloudFlare я использую их бесплатный тарифный план и направляю через них DNS для dustinbrett.com. Он указывает на мой реальный веб-сервер, куда CloudFlare обращается для получения файлов, когда кэш становится недействительным/очищенным. CloudFlare также имеет множество настроек и переключателей, чтобы сделать все еще быстрее. Я привел ссылку на информацию о бесплатном плане и их руководство по оптимизации скорости сайта.

  • https://www.cloudflare.com/en-ca/plans/free/
  • https://developers.cloudflare.com/fundamentals/get-started/task-guides/optimize-site-speed/

2. HTTP/2 & HTTP/3

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

  • https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol
  • https://en.wikipedia.org/wiki/HTTP/3#Comparison_with_HTTP/1.1_and_HTTP/2

3. Сжатие Brotli по сравнению с GZip

Еще один простой трюк на стороне сервера — включить сжатие Brotli, если оно поддерживается. Он считается преемником GZip и, похоже, действительно делает вещи меньше, что в идеале означает быстрее, и в данном случае, похоже, так и есть.

  • https://en.wikipedia.org/wiki/Brotli
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Encoding

4. HTTP-заголовки

Это важный параметр, и в идеале он должен иметь по умолчанию какие-то вменяемые значения, но бывают случаи, когда, если вы не установите правила, вы будете обслуживать файлы, которые не кэшируются и запрашиваются каждый раз. В одном случае я столкнулся с проблемой с файлами .ini, которые сервер не знал, что это текст, и поэтому передавал их с Content-Type application/octet-stream, который также устанавливал Cache-Control на max-age=0. Я заметил это не сразу, когда просматривал заголовки запросов загрузки страниц в DevTools->Network. Решением на стороне сервера было правильно связать эти расширения с MIME-типами, такими как text/plain, которые имели вменяемое значение Cache-Control в 1 неделю. Урок заключается в том, чтобы убедиться, что вы посылаете правильные заголовки кэша своим пользователям, чтобы их браузеры знали, что не нужно запрашивать что-то у вашего сервера без необходимости.

  • https://developers.cloudflare.com/cache/about/cache-control/
  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types

5. Ранние подсказки

У меня смешанные чувства по поводу этого предложения, поскольку я не смог заставить его правильно работать с моими отзывчивыми изображениями, которые используют srcset (<img>)/imagesrcset (<link>). Теоретически это кажется очень полезной функцией, и если бы у меня были другие файлы, с которыми я хотел бы это сделать, я бы подумал об этом. Но моим идеальным вариантом использования сейчас были бы только изображения, а для этого мне нужно дождаться сервера, который поддерживает отзывчивый заголовок Link. Я буду рад, если мне докажут, что я ошибаюсь, но мне казалось невозможным, если ваши изображения основаны на dpi, чтобы 103 Early Hints зависели от dpi запрашивающего браузера и отправляли ему только соответствующее изображение, а не все разрешения. Для тех, кто использует нереагирующие заголовки link и находится на CloudFlare или любом другом сервере, поддерживающем 103 Early Hints, эта функция кажется хорошей, так как она сообщит вашим пользователям о необходимости получить изображения еще до того, как они увидят ваш HTML с тегами предварительной загрузки <link>.

  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103
  • https://developer.chrome.com/blog/new-in-chrome-103/#http103
  • https://developer.chrome.com/blog/early-hints/
  • https://developers.cloudflare.com/cache/about/early-hints/

6. Обработка начального CDN MISS

Это отчасти совет, хотя чем больше я над ним думаю, тем больше сомневаюсь в его полезности. Для таких сайтов, как мой, которые находятся в стадии интенсивной разработки, мне кажется, имеет смысл часто очищать кэш, поскольку я меняю довольно много файлов на еженедельной основе. Из-за этого каждый пограничный сервер должен зайти на мой медленный веб-сервер, прежде чем он сможет кэшировать файл, чтобы передать его ближайшим пользователям. Я делаю следующее: посещаю сайт и убеждаюсь, что в HTTP-заголовках CloudFlare вместо MISS при кэшировании с граничного сервера отображается HIT. Но когда я думаю об этом, я понимаю, что он просто кэширует его на граничном сервере, который я случайно посетил. Поэтому для меня это быстрее, так как последующие посещения будут HIT, но для пользователей по всему миру они получат этот медленный начальный запрос, если кто-то на их граничном сервере еще не запустил MISS.

  • https://developers.cloudflare.com/cache/about/default-cache-behavior/#cloudflare-cache-responses

7. Заголовок HSTS

Я не уверен в том, какой прирост производительности это может дать, но мне нравится идея, что мой домен будет где-то в списке браузера, который говорит: «Всегда посещайте этот домен по HTTPS». Делая это, вы можете избежать минутного замедления от пользователей, которые могут посетить ваш сайт по HTTP и в идеале перенаправляются на HTTPS.

  • https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
  • https://hstspreload.org/?domain=dustinbrett.com

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

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

  • https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types
  • https://developer.mozilla.org/en-US/docs/Web/HTML/Element/link#attr-type

9. fetchpriority

Это еще одна новая функция, доступная пока только в браузерах Chromium, но если ваши пользователи поддерживают ее, то, похоже, ее стоит использовать. Концепция fetchpriority может быть использована для img, fetch и link. Для любых запросов, которые я хочу выполнить как можно быстрее, я указываю high приоритет.

  • https://wicg.github.io/priority-hints/#link
  • https://web.dev/priority-hints/

10. HTML Minify / Удаление тегов

Мне всегда нравилось иметь минимальное количество HTML, когда это возможно, поэтому найти html-minifier-terser было довольно приятно, так как он удалял теги, которые я считал необходимыми, но оказалось, что это не так. Такие теги как <head>, <body>, </html>. Также кавычки часто не нужны. Этот инструмент минификации довольно хорошо справляется с удалением бесполезного HTML. Затем я также запускаю скрипт, который удаляет другие теги, которые мне не нужны, например <noscript> и некоторые данные Next.js JSON, которые мне не нужны.

  • https://github.com/terser/html-minifier-terser
  • https://validator.w3.org/
  • https://nextjs.org/docs/basic-features/pages#static-generation-recommended
  • https://github.com/DustinBrett/daedalOS/blob/main/scripts/minifyHtml.js

11. Минимизация/упрощение изображений

Еще одна вещь, которую я обычно стараюсь делать — это как можно меньше изображений. Я упоминаю об этом в других советах, но одним из полезных способов является минификация. Я использую инструмент Windows FileOptimizer для сжатия без потерь всех моих изображений. Я также использую SVGO для уменьшения размеров SVG, поскольку часто значение path может быть упрощено без потери данных/качества. Наконец, еще один метод упрощения, который я использую, но который может быть не совсем идеальным для всех, — это использование минимального набора фавиконов. Я использую абсолютный минимум — просто файл favicon.ico в корне сайта и никакой поддержки HTML для указания на версии высокого разрешения. В зависимости от условий использования вам может понадобиться несколько тегов favicon, но минимальная установка — это идеальный вариант.

  • https://nikkhokkho.sourceforge.io/static.php?page=FileOptimizer
  • https://github.com/DustinBrett/daedalOS/blob/main/scripts/createIcons.bat
  • https://jakearchibald.github.io/svgomg/
  • https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/The_head_metadata_in_HTML#adding_custom_icons_to_your_site
  • https://en.wikipedia.org/wiki/Favicon

12. WEBP vs PNG vs AVIF

Когда речь заходит о том, какой формат изображения использовать, это немного зависит от того, какой тип изображения вы хотите представить. Если это фотография с потерями, снятая на камеру, то, возможно, AVIF будет идеальным вариантом. Если это миниатюра/иконка без потерь, то WEBP может дать лучшие результаты, особенно если вам не нужны некоторые новые возможности AVIF. Но пока ваши пользователи поддерживают это, я думаю, мы должны с радостью перейти на современные форматы изображений AVIF/WEBP вместо JPG/PNG для большинства случаев, так как, по моему опыту, это то же визуальное качество в меньшем файле.

  • https://avif.io/blog/comparisons/avif-vs-webp/
  • https://caniuse.com/webp
  • https://developers.google.com/speed/webp/docs/cwebp

13. Ленивая загрузка / Наблюдатель пересечений

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

Другой способ ленивой загрузки я использую для всех иконок, которые представляют файлы или папки. Он не загружает иконку, пока не обнаружит, что изображение попало в область просмотра. В случае динамических иконок, которые требуют захвата самого файла, для них я использую JavaScript и Intersection Observer для запуска функции getIcon, когда кнопка иконки попадает в область просмотра.

  • https://developer.mozilla.org/en-US/docs/Web/Performance/Lazy_loading
  • https://nextjs.org/docs/advanced-features/dynamic-import
  • https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import

14. Тестирование Lighthouse / GTMetrix / WebpageTest

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

  • https://github.com/GoogleChrome/lighthouse
  • https://pagespeed.web.dev/
  • https://gtmetrix.com/
  • https://www.webpagetest.org/

15. Web Workers & Offscreen Canvas

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

  • https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
  • https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas
  • https://developer.mozilla.org/en-US/docs/Glossary/Main_thread
  • https://partytown.builder.io/

16. Ориентируйтесь на современные браузеры (избегайте полифиллов и ES5)

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

  • https://caniuse.com/?search=es6
  • https://github.com/browserslist/browserslist

17. Расширенные настройки библиотеки

Это зависит от того, какие библиотеки и фреймворки вы используете. В моем случае, 3 места, где я смог добавить дополнительные оптимизации, это Next.js, Framer Motion & Styled Components. Во всех случаях есть расширенные конфигурации, которые я люблю просматривать, чтобы найти небольшие улучшения, которые я могу добавить, когда это возможно. Всякий раз, когда я добавляю что-то из npm, я ищу расширенные настройки конфигурации, просто чтобы знать, что возможно, и нравятся ли мне настройки по умолчанию.

  • https://nextjs.org/docs/advanced-features/compiler
  • https://www.framer.com/docs/guide-reduce-bundle-size/
  • https://styled-components.com/docs/tooling#dead-code-elimination

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

  • https://nodejs.org/api/fs.html
  • https://github.com/DustinBrett/daedalOS/blob/main/scripts/searchIndex.js
  • https://github.com/DustinBrett/daedalOS/blob/main/scripts/preloadIcons.js
  • https://github.com/DustinBrett/daedalOS/blob/main/scripts/fs2json.js

19. Анализатор пучков

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

  • https://www.npmjs.com/package/webpack-bundle-analyzer

20. Встроенный CSS

Загрузка CSS в элемент <head>, как мне кажется, до сих пор считается одним из самых быстрых способов донести стиль до пользователя. Одно из преимуществ использования стилизованных компонентов и большинства CSS-in-JS решений заключается в том, что они могут инкрустировать соответствующий CSS в статический HTML файл, чтобы он был готов к работе как можно быстрее. Я лично не использую файлы CSS, но если кто-то пойдет по этому пути, другие советы, такие как CDN, предварительная загрузка ссылок и ранние подсказки, могут улучшить загрузку этих файлов.

  • https://styled-components.com/
  • https://github.com/callstack/linaria

21. Отложите JavaScript

Этот совет поставляется бесплатно с некоторыми фреймворками, которые уже используют этот атрибут, но полезно помнить, что если у вас есть теги <script> в <head>, вы можете использовать defer, чтобы они не блокировали парсер и могли выполняться после DOMContentLoaded.

  • https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#attr-defer

22. Системные шрифты

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

  • https://systemfontstack.com/
  • https://developer.mozilla.org/en-US/docs/Web/CSS/font-family

23. Асинхронное декодирование изображений

Мне нечего сказать по этому поводу, кроме того, что, судя по описанию, если вы хотите «уменьшить задержку при отображении другого контента», вам следует использовать decoding=async. Это, скорее всего, имеет очень незначительную разницу, но, возможно, для больших изображений это может быть заметным изменением.

  • https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decoding

24. Отзывчивые изображения

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

  • https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images
  • https://caniuse.com/mdn-html_elements_link_imagesrcset
  • https://developer.mozilla.org/en-US/docs/Web/CSS/@media/resolution

25. Определите размеры изображения

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

  • https://caniuse.com/?search=aspect-ratio
  • https://web.dev/cls/

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

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

Оцените статью
devanswers.ru
Добавить комментарий