Под номером четыре это веб-шрифты. Иногда проблема заключается в совокупном весе нескольких файлов шрифтов, но чаще всего это не так, страдает воспринимаемая производительность (в основном из-за того, когда появляются веб-шрифты).
К счастью, в этой ситуации можно задать простой вопрос: WWZD - Что бы сделал Зак?
3. Изображения
На третьем месте - изображения. Их стало больше, и кажется, что они все время становятся больше. И все же в нашем распоряжении больше инструментов, чем когда-либо - лучшие форматы файлов и отличная поддержка браузерами адаптивных изображений. Черт возьми, теперь у нас даже появилась возможность отложить загрузку изображений в HTML.
Таким образом, как и в случае с веб-шрифтами, кажется, что влияние изображений на производительность можно преодолеть, если вы уделите им немного времени и внимания.
2. Наш JavaScript
Просто упускают из виду, что первое место занимает JavaScript, который мы отправляем по трубе нашим многострадальным пользователям. В самом коде нет ничего плохого - я уверен, что он очень хорош. Его чертовски много. И это настоящее узкое место в производительности, особенно на мобильных устройствах.
Так что перестаньте присылать столько JavaScript - решение столь же простое, как Инструкции Монти Пайтона по игре на флейте.
1. Чужой JavaScript
На первом месте с пулей - это вся чушь, которую кто-то советует нам размещать на наших веб-сайтах. Аналитика. Объявления. Трекеры. Маяки. «Это всего лишь один маленький сценарий», - говорят они. А потом этот маленький сценарий вызывает другой, и еще, и еще.
Это так обидно, когда вы посвятили свое время и энергию своей стратегии загрузки веб-шрифтов, оптимизации изображений и разделению JavaScript… только для того, чтобы чужой JavaScript просто засрал на весь ваш хороший бюджет производительности.
Вот что действительно раздражает: когда я хожу на конференции по производительности или участвую в обсуждениях производительности, вы знаете, кого нигде не найти? Люди, создающие сторонние скрипты.
Повествование о производительности внешнего интерфейса заключается в том, что мы, разработчики, должны нести ответственность за работу наших веб-сайтов. Но наибольшее влияние на производительность оказывают сторонние скрипты.
Решение есть, но не техническое. Мы могли отказаться от добавления избыточных (и во многих случаях неэтичных) сторонних скриптов на создаваемые нами сайты.
У меня очень много проблем с проектом Google AMP, но я полностью осознаю, что он решает политическую проблему:
В HTML-документе AMP не допускается использование внешнего JavaScript. Это касается сторонних библиотек, рекламных скриптов и скриптов отслеживания. Это нормально для меня.
Причины запрета связаны с производительностью, и я полностью с ними согласен. Большие раздутые библиотеки JavaScript - одно из главных убийц производительности в Интернете.
Но как мы можем извлечь урок из AMP и применить его ко всем нашим веб-страницам? Если мы просто откажемся быть одним из тех, кто добавит эти сторонние скрипты, нас уволят, и появится кто-то еще, кто захочет отравить веб-страницы сторонними скриптами. Ничто не мешает компаниям делать это.
Пока не…
Предположим, мы все заключим договор, что будем солидарны с любым из наших коллег-разработчиков в подобной ситуации. Что-то вроде объединения. Союз, если хотите.
Есть власть на фабрике, власть на земле, власть в руках рабочего, но все это ни к чему не приведет, если мы вместе не встанем.
Изначально это было размещено на моем собственном сайте.
