devy

Front-end производительность для веб-дизайнеров и front-end разработчиков.

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

Производительность не только чрезвычайно важна, но и процесс оптимизации невероятно интересен.

В этой статье я собираюсь совместно использовать  загрузку быстрых, простых и совершенно интригующих битов знаний о производительности, чтобы действовать как учебник для начинающих веб-дизайнеров и front-end разработчиков; надеюсь, эта статья будет приличным введением для любого желающего узнать о производительности. Эти подсказки — это вещи, которые вы можете сами очень легко реализовать. Просто требуется немного хитрости и некоторые элементарные знания того, как работают браузеры. И вы готовы играть по правилам!

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

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

Основы

Есть несколько вещей, которые все дизайнеры и  front-end разработчики  будут, вероятно, знать о производительности, таких вещах как создание как можно меньшего количества запросов, оптимизируя изображения, помещая таблицы стилей в <head>;,  помещая JS перед </body>, уменьшая JS и CSS и т.д. Эти основные принципы вы уже встречали на своем пути, но есть больше … намного больше.

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

Стили вверху, скрипты внизу

Это  действительно основное правило и следовать ему, большую часть времени, должно быть довольно просто, но почему оно имеет такое значение?

CSS блокирует визуализацию потому что браузеры желают представлять страницы прогрессивно; они хотят представлять вещи, только когда доберутся к ним и по порядку . Если стили — подключены в низу страницы, браузер не может их отрендерить, пока не пройдет весь предыдущий код. Это помогает браузеру избежать перерисовки стилей, если они изменяют что-то, что было ранее представлено далее документом. Браузер не представит страницу, пока у него не будет всей доступной информации о стиле, и если вы подключаете CSS в конце документа, вы заставляете браузер ждать, блокируя визуализацию.

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

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

JavaScript прерывает этот процесс, блокируя параллельные загрузки любого и всех доменов, потому что:

Так как браузеры останавливают все другие загрузки, пока выполняется JavaScript, это хороший повод подключать JavaScript в конце документа. Я уверен, что вы все наблюдали пустые разделы страниц, где третью часть времени занимается JS, чтобы загрузиться и выполниться, и блокирует выборку и визуализацию остальной части ассетов страницы; это — блокирование JavaScript в действии.

Очевидно, однако, что современные браузеры становятся умнее. Я собираюсь дать вам выборку из электронной почты от Энди Дэвиса мне, потому что он объясняет намного лучше меня:

Современные браузеры будут загружать JS параллельно, и визуализация будет заблокирована, пока сценарий не будет выполнен (это, очевидно, должно быть загружено также).

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

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

Некоторые браузеры, например, Chrome, приоритезирует загрузку ассетовв, например, если скрипты и изображения будут оба в ожидании загрузки, то Chrome загрузит сначала скрипты.

Умный материал!

Чтобы позволить странице начать визуализацию максимально быстро, поместите свои стили сверху. Чтобы предотвратить JS, блокирующие визуализацию, поместите сценарии в нижнюю часть.

Выполняйте меньше запросов

Другая действительно очевидная и основная оптимизация производительности — просто меньше загружать. Каждый ассет, который требует страница, является дополнительным запросом HTTP; браузер требует, чтобы каждый ассет представил страницу. Каждый из этих запросов может подвергнуться поискам DNS, перенаправлением, 404  и т.д. Каждый запрос HTTP, который вы выполняете, нужно ли это для таблицы стилей, изображения, веб-шрифта, файла JS, вы делаете потенциально дорогую операцию. Уменьшение этих запросов является одной из самых быстрых оптимизаций производительности, которые вы можете сделать.

Вернемся к браузерам и параллельности; большинство браузеров только загружает ряд ассетов с каждого домена, на который ссылаются, за один раз, и JS блокирует эти загрузки. Каждый запрос HTTP, который вы выполняете, должен быть хорошо обоснован.

Максимизация параллелизации

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

У большого количества сайтов есть статические домены/ассет домены; Twitter, использует, si0.twimg.com чтобы обслуживать статический ассет:

[cce lang=»javascript»]

<link rel="stylesheet" href="https://si0.twimg.com/a/1358386289/t1/css/t1_core.bundle.css" type="text/css" media="screen">

[/cce]

Facebook использует fbstatic-a.akamaihd.net:

[cce lang=»javascript»]

<link rel="stylesheet" href="https://fbstatic-a.akamaihd.net/rsrc.php/v2/yi/r/76f893pcD3j.css">

[/cce]

Используя эти статичные ассет домены, Twitter и Facebook могут обслуживать большее количество ассетов параллельно; ассеты от twitter.com и si0.twimg.com могут быть загружены в тандеме. Это — действительно простой способ получить больше параллельных загрузок, происходящих на вашей странице, и еще лучше, когда вместе с фактической технологией CDN, которая может помочь уменьшать задержку путем обслуживания ассетов от более подходящего физического местоположения.

Это — все хорошо и замечательно, но позже мы обсудим, как обслуживание от поддоменов может фактически, при определенных обстоятельствах, быть вредным для производительности.

Вот наши основы производительности:

HTTP запросы и DNS поиск

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

Проблемой, однако, будет DNS поиск. Каждый раз (от cold cache) ссылаясь на новый домен, HTTP запрос подвергается длительному DNS поиску (где угодно между 20 и 120 миллисекундами), в котором ищет исходящий запрос, где ассет фактически живет; интернет связан IP-адресами, на которые ссылаются хосты, которыми управляет DNS.

Если у каждого нового домена, на который вы ссылаетесь, есть оплачиваемая авансом стоимость DNS поиска, вы должны быть уверены, что это будет стоить того. Если это будет небольшой сайт (как CSS Wizardry, например), то служащие ассеты от поддомена не будут, вероятно, стоить того; браузер может, вероятно, выбрать несколько под — параллелизированных ассетов от одного домена, более быстрого, чем это может выполнить DNS поиск  через многократные домены и параллелизировать их.

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

DNS поиски дорогие, таким образом, вы должны определить, какой более подходит для вашего сайта; издержки поисков или просто обслуживание всего от одного домена.

Важно помнить, что, как только от HTML требуют, скажем, foo.com, то DNS поиск для узла уже произошел, таким образом, последующие запросы к чему-либо на foo.com не подвергаются DNS поискам.

Предварительная DNS выборка

Если вы, как я, хотите иметь виджет Twitter на своем сайте, и Аналитику, и возможно некоторые веб-шрифты, то вы должны будете соединиться с некоторыми другими доменами, что означает, что вы должны будете подвергнуться DNS поискам. Мой совет состоит в том, чтобы не использовать любой и каждый виджет, тем более, не учитывая должным образом его влияние на производительность. Но для любого, который вы действительно считаете необходимыми, следующее — полезно…

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

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

Предварительная DNS выборка, именно такая, какой и должна быть и не может реализоваться более просто. Если вы должны запросить ассеты от, скажем, widget.foo.com, то вы можете предварительно выбрать DNS хост, просто добавляя это вначале в <head> вашей страницы:

[cce lang=»javascript»]

<head>
    ...
    <link rel="dns-prefetch" href="//widget.foo.com">
    ...
</head>

[/cce]

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

Этот простой элемент ссылки (который я использую на CSS Wizardry) полностью совместим и негативно не повлияет на производительность. Думайте о нем, как о прогрессивном улучшении производительности!

Дополнительная литература

Ускорьте свой сайт используя предварительную выборку

Предварительная выборка ресурса

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

Веб-шрифты и изображения, на которые ссылаются в CSS, ведут себя почти таким же способом; браузер начнет загружать их, как только он дойдет до HTML части, которая потребует их. Как я упоминал прежде, браузеры очень умны, и это — другой яркий пример этого. Вообразите, браузеры загружают изображения, на которые ссылаются в CSS, как только они увидели объявления:

[cce lang=»javascript»]

.page--home         { background-image:url(home.jpg); }
.page--about        { background-image:url(about.jpg); }
.page--portfolio    { background-image:url(portfolio.jpg); }
.page--contact      { background-image:url(contact.jpg); }

[/cce]

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

Если мы можем быть абсолютно уверены, что всегда будем использовать определенное CSS изображение, используемое на каждой странице, то мы можем обмануть браузер и загрузить его, прежде чем оно встретится с HTML, который нуждается в нем. Сделать это невероятно просто, но может быть немного грязно, в зависимости от того, как вы на это смотрите.

Грязный путь, и вероятно самый пуленепробиваемый, состоит в том, чтобы иметь скрытый <div> на каждой странице, который содержит изображения CSS как <img> элемент с пустыми alt атрибутами. Я делаю это с Wizardry CSS спрайтами; потому, что знаю, что это нуждается в использовании на каждой странице, я могу уверенно выбрать его предварительно, ссылаясь на него в моем HTML. Путь обработки браузером встроенного <img> довольно хорош: выбирает их предварительно и захватывает их супер рано, таким образом, заставляя браузер загрузить мой спрайт как <img> в моей разметке, и может начать загружать его, прежде чем CSS потребует его. Я могу получить headstart на этой загрузке, ссылаясь на (скрытое) в моем HTML.

Есть некоторая путаница вокруг второго, ‘более чистого’ пути, который сильно походит на пример предварительной DNS выборки:

[cce lang=»javascript»]

<link rel=»prefetch» href=»sprite.png»>

[/cce]

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

Путаница происходит вокруг кажущейся несоизмеримости между двумя статьями; на основе этой, от MDN, кажется, что предварительная выборка — подсказка для браузеров, чтобы возможно начать выбирать ассет предварительно, если это неактивно. Наоборот, однако, эта статья от Планеты Производительности, которая, кажется, предполагает, что браузер будет всегда выбирать ассеты предварительно, если это будет поддерживать rel =, «prefetch», и не упоминать о времени простоя. Водопады, на которые я посмотрел, кажется, предполагают, что последнее — истина, но странная причуда WebKit, посредством чего вы не можете наблюдать предварительную выборку в действии, если у вас есть открытые инструменты разработчика (разговор о Шредингере …) значит, я не могу быть на 100% уверен. Любое разъяснение по этому поводу чрезвычайно важно.

Я упоминал, что шрифты и изображения работают почти совершенно одинаково; вышеупомянутые правила применяются точно так же для файлов шрифта, но вы не можете загрузить шрифт в скрытом <div> (вы должны будете использовать ссылку предварительной выборки).

[cce lang=»javascript»]

<link rel="prefetch" href="webfont.woff">

[/cce]

В основном то, что мы делаем здесь, ‘обманываем’ браузер в загрузке ассета загодя, так, чтобы к тому времени, когда это действительно нужно было нашему CSS, у него уже был загруженный ресурс (или по крайней мере продвигающийся). Изящно!

Дополнительное литература

Ускорить ваш сайт, используя предварительную выборку

CSS и производительность

Многие утверждают, что, если вы используете домены для ассетов, вы должны обслуживать все статические ассеты ими; это включает CSS, JS, изображения и т.д.

Тем не менее, вы не должны обслуживать CSS ассетом/поддоменом …

Помните, ранее, мы обсуждали, как CSS блокирует рендеринг? Браузер хочет овладеть вашим CSS, как можно раньше; CSS находится на вашем критическом пути. Ваш критический путь — необходимое путешествие между пользователем, запрашивающим вашу страницу и затем видящий что-то. Поскольку рендеринг блокируется, CSS находится на критическом пути, а JS и изображения нет. Если вы хотите сделать эту поездку вдоль критического пути максимально быстрой, это означает — никаких DNS поисков.

Мы создавали сайт, подготовка окружающей среды которого служила всем ассетам одного хоста (например, foo.com), но когда это сводилось к созданию подготовки более живой среды, мы начали обслуживать все наши ассеты от s1.foo.com и s2.foo.com. Это означало, что все изображения, JS, CSS, шрифты и т.д. все прибывали из различных доменов, таким образом, подвергаясь DNS поискам. Проблема здесь состоит в том, что DNS поиск начинает захватывать CSS файл, фактически замедляя критический путь. Наши графики заостренны в широком масштабе, указывая на задержку, которая в теории не должна была происходить; наиболее успешная практика диктует, что вы должны использовать множество ассетов по поддоменам, правильно? Не CSS. Требуемый DNS поиск занял значительно время, что задержало рендеринг страницы.

CSS — один из худших врагов производительности, как обрисовано в общих чертах Стояном Стефановым, из-за этого блокирования рендеринга. Также стоит отметить, что браузер загрузит весь CSS, прежде чем начнет представлять вашу страницу. Это означает, что ваш print.css будет требоваться, даже если браузер только представит страницу на экране. Это означает, что любые таблицы стилей, которые только используются на основе запроса носителей (например <link rel=»stylesheet» media=»screen and (min-device-width: 800px)» href=»desktop.css»>), будут загружены, даже если они не будут необходимы.

Однако Энди Дэвис сообщил, что WebKit приоритезирует свой порядок загрузки CSS так, чтобы только необходимый CSS, чтобы первоначально представить страницу, был на первом месте, и другие стили, например, print.css задержаны до того, пока не понадобятся. Удивительно!

Знание этого о CSS позволяет нам принимать несколько решений, все базируемые вокруг знания, что CSS блокирует рендеринг, все, что требуется и находится на вашем критическом пути:

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

Дополнительная литература

CSS и критический путь

Сжатие и минификация

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

Если необходимо было выбрать что-то одно, то одно сжатие является более эффективным, чем одна только минификация. Если вы можете, однако, необходимо действительно сделать и то и то.

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

Это, взято из документов Apache:

Вы должны избегать использования .htaccess файлов полностью, если у вас есть доступ к httpd основному файлу конфигурации сервера. Использование .htaccess файлов замедлит ваш Apache http сервер. Любую директиву, которую вы можете включить в .htaccess файл, лучше установить в блоке Directory, поскольку это будет иметь тот же эффект с лучшей производительностью.

Если у вас был доступ только к .htaccess тогда, я не волновался бы; эти расходы обычно не будут беспокоить. Включение сжатия с .htaccess фактически действительно просто реализовать. Минификация не обязательно так проста, если вы не имеете процесс сборки или используете что-то типа CodeKit или препроцессор, который компилирует прямо в уменьшенный вывод.

Интересно, что главной причиной, по которой я переехал с inuit.css к Sass было, то, что я мог удобно составить уменьшенную версию.

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

Gzip, как любой алгоритм сжатия, берет любой базовый источник текста и сжимает его на основе повторных/повторяемых строк. Большинство сжатий кода действительно хорошо через gzip если есть тенденция для всего кода, чтобы повторить строки; например, фоновое изображение много раз в CSS, <strong> много раз в разметке …

Gzip действительно сожмет размер ваших ассетов в широком масштабе, и вы должны определенно включить его. Для приличного .htaccess отрывка проверьте, как HTML5 шаблон обрабатывает материал.

Сжатие вашего содержания делает гигантское сохранение. Во время записи inuit.css весит 77 килобайт. Сжатый и gzipped это весит всего 5.52 килобайт. Уменьшение и сжатие дают нам 93% сохранения. И, потому что gzip работает хорошо над  текст-бейсд ассетами, вы можете даже сжать SVGs и даже некоторые форматы файлов шрифта!

Оптимизация изображений

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

Спрайт

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

Чтобы сражаться с аспрайтабельностью определенных элементов, нам нужен так называемый ‘спрайтинг элемента’. Это — в основном пустой элемент, обычно <i>, единственное задание которого, что он должен остаться пустым и просто перенести фоновое изображение.

Я использовал их, когда я создавал Sky Bet, YouTube использует их, Facebook использет их, у Джонатана Снука есть целый раздел по ним в SMACSS.

Основная предпосылка — если спрайтинг элемента невозможен, потому что он изменчив, вы помещаете в него пустой элемент с фиксированными размерами и после приступаете к спрайту, например:

[cce lang=»javascript»]

<li>
    <a href="/profile/">
        <i class="icon  icon--person"></i> Profile
    </a>
</li>

[/cce]

Здесь мы не можем применить спрайт <li> или <a>, таким образом, у нас есть пустое <i>, который переносит значок вместо этого. Это — одна из вещей, которые я люблю больше всего в производительности; вы комбинируете умные методы, чтобы улучшить скорость страницы, также используя традиционно ‘плохую’ разметку. Прекрасный материал!

Retina изображения

Вы не нуждаетесь в ретине везде. Изображение 2x содержит в четыре раза больше пикселей, чем то же изображение в стандартном разрешении. Четыре. Раза. Хотя это не обязательно означает, в четыре раза размер файла по сети – благодаря собственному кодированию изображения – это действительно означает, что, как только изображение распаковано для рендеринга в браузере, есть в четыре раза больше обычного количество пикселей, которые нужно хранить в памяти.

Если мы остановимся и подумаем; изображение ретина чаще все (несмотря на то, что не всегда), должно было обеспечить более свежий UI для телефонов. У телефонов намного меньше памяти, чем у большинства других устройств. Ретина дробит память изображений для устройств с маленьким объемом памяти. Подумайте дважды, нужны ли вам действительно изображения ретина по всем направлениям, или вы можете найти разумный компромисс?

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

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

Если ваша статистика прощает достаточно, вы могли бы, возможно, выбрать SVGs или шрифт значка вместо растровых изображений. Я использую SVG на CSS Wizardry, что приносит мне пользу:

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

Вы можете использовать такие службы как ReSRC.it, чтобы загрузить изображения в зависимости от устройства и его контекста.

Прогрессивные JPG

Один интересный аспект производительности — восприятие производительности; не важно, что говорят вам числа, важно как скорость чувствуется.

При отображении большого JPG изображения, вы, вероятно, более, чем знакомы с его судорожной загрузкой; сто пикселей изображения, пауза, еще пятьдесят, пауза, затем скачок и еще ​​двести пикселей… тут бац…и целое изображение.

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

Чтобы включить прогрессивный JPG, вы просто должны установить соответствующий флажок при сохранении для сети и устройств в Photoshop; работа сделана!

Дополнительная литература

Прогрессивный jpegs: новая наиболее успешная практика.

Не используйте изображения вообще

Лучше, чем спрайт, и SVGs, и предотвращения ретины, может быть только избегание изображений в целом. Если вы можете 100% тиражировать проект, используя изображение, но 75% тиражируют его, используя чистый CSS, то предпочитают чистое решение для CSS (если это не приводит к еще 100 строкам кода, конечно!). Предотвращение изображений означает потенциально предотвращение запросов HTTP, но также и обслуживания пособий. Если вы можете избегать использования изображений, тогда пытается сделать именно так.

Итоги

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

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

Дополнительная литература

Если вы насладились этим, и хотят знать больше, я не могу не порекомендовать следующее:

По материалам: csswizardry.com