С момента появления интернета веб-разработка прошла очень длинный путь. Это было удивительное путешествие от модемов до оптоволоконных схем. С ростом скорости передачи данных пользователи стали нетерпеливы. Люди ожидают, что их повседневные задачи будут решены здесь и сейчас. Это привело к необходимости создавать сайты, которые работают быстро и без задержек. Но есть большая проблема, которую мы, как разработчики, должны как-то решать: мы не можем контролировать конфигурацию устройств, с которых пользователи обращаются к нашим сайтам. Это могут быть как мощные, так и слабые машины, с быстрым или медленным подключением к интернету. Поэтому мы должны как можно лучше оптимизировать свои сайты, чтобы они удовлетворяли требованиям любых пользователей. Веб-разработчики выработали несколько принципов создания сайтов, которые быстро работают даже на самых слабых устройствах. Здесь описаны некоторые из этих принципов. Подчеркну, что они размещены в произвольном порядке. И последнее: чтобы сохранять баланс между оптимизацией и своевременной поставкой функционала, всегда делитесь и переиспользуйте свой код, точнее — компоненты. Это можно делать с любым репозиторием безо всякой специальной подготовки, достаточно лишь воспользоваться инструментом вроде Bit (Github). В наши дни изображения и видео стали высокого качества и прекрасно доставляются. Но главной проблемой является размер файлов. Согласно Jecelyn, в среднем веб-страница состоит из 5 Мб одних только изображений. В некоторых странах это может быть очень дорого для пользователя, особенно при использовании мобильного интернета. К тому же большой объём данных может приводить к проблемам со скоростью загрузки сайта, особенно при низкой скорости подключения. Всё это негативно влияет на ваш сайт. WebP — современный графический формат, позволяющий хранить изображения как с потерей качества, так и без потерь, ещё больше уменьшая размер файлов. Он разработан в Google. В последнее время формат набирает популярность, особенно среди крупных технологических компаний, в основном благодаря своей эффективности и поддержке со стороны Google. WebP напрямую конкурирует с форматами вроде JPG и PNG. Достоинства: Размер WebP-изображений без потери качества на 26 % меньше PNG. Размер WebP-изображений с потерей качества на 25–34 % меньше JPEG при эквивалентном качестве SSIM. WebP без потерь также поддерживает прозрачность. Сравнение WebP без потери качества и PNG. Источник: InsaleLab. Здесь вы можете подробнее почитать о WebP и других новых форматах. Веб-кеширование — это ключевая архитектурная возможность HTTP-протокола, предназначенная для снижения сетевого трафика с одновременным улучшением предполагаемой отзывчивости системы в целом. Кеши есть на всех стадиях пути данных от сервера к браузеру. Простыми словами, веб-кеширование позволяет повторно использовать HTTP-ответы, сохранённые в кеше, для однотипных HTTP-запросов. В жизни мы не можем внедрять агрессивное кеширование, поскольку кеши наверняка будут чаще всего возвращать устаревшие данные. Поэтому для сохранения баланса между долговременным кешированием и реагированием на потребности меняющегося сайта необходимо применять собственную политику кеширования, внедряя подходящие алгоритмы очистки кеша. Поскольку каждая система уникальна и обладает своим набором требований, нужно потратить достаточное количество времени на создание политик кеширования. Чтобы добиться идеальной политики кеширования, необходимо найти тонкую грань между использованием агрессивного кеширования, и возможностью сбрасывать конкретные записи при изменениях. Здесь вы можете больше узнать об основах кэширования. Бывают сайты, на которых отображается контент огромных объёмов. Например, изображения в высоком разрешении, большая коллекция аудиозаписей и т.д. Большой размер файлов может сильно повлиять на длительность загрузки страницы. Но ваши пользователи не заходят ждать, пока всё загрузится. Стратегия под названием «ленивая загрузка» поможет снизить объём первично загружаемых данных, а также ускорить загрузку страницы, не уменьшая содержимое. Методика подразумевает откладывание загрузки некритичной информации при загрузке самой страницы, это делается позже, по мере необходимости. Но бывают и ситуации, когда может потребоваться заранее загрузить содержимое. В этом случае можно прибегнуть к «жадной загрузке». Есть ещё предварительная загрузка, при которой содержимое грузится после первичной загрузки страницы.  Не существует одного идеального подхода для всех сайтов. Вам придётся проанализировать и выбрать стратегию наиболее подходящую под ваши требования. Здесь вы можете подробнее почитать о стратегиях загрузки. Нет смысла делать стабильно работающее веб-приложение, если оно долго выполняет свои задачи. Могут возникать ситуации, когда серверу приходится обрабатывать тяжёлые задачи, на которые тратится значительное время. Очевидно, что пользователям не понравится ждать завершения этого процесса. Ускорить вычисления можно двумя способами. Во-первых, масштабируя и расширяя архитектуру, чтобы она могла быстрее обрабатывать такие задачи. Но этот подход значительно повышает расходы на эксплуатацию серверов. Во-вторых, вы можете оптимизировать алгоритмы. Этим нужно заняться до масштабирования архитектуры. Оптимизированные алгоритмы могут значительно ускорить обработку, а значит и ускорить отклик системы. Но помните, что оптимизации должны быть тщательно продуманы. Вам придётся проанализировать имеющееся решение и понять, можно ли его усовершенствовать. Это потребует времени и терпения. Эффективный API — один из ключевых факторов универсального веб-приложения. Одна из главных ошибок неопытных разработчиков заключается в том, что они начинают проектировать API, не понимая его концепции. Вы обязаны разбираться в преимуществах и компромиссах разных архитектур, а также понимать последствия применения стилистических ограничений в создаваемом продукте. Очевидно, что не бывает универсальной архитектуры, способной решить любые проблемы. Разным продуктам требуются разные схемы, удовлетворяющие бизнес-целям и требованиям. Сегодня одной из самых популярных тем является GraphQL. Вам всегда найдут аргументы в пользу GraphQL и REST. Очень рекомендую почитать эту статью, чтобы лучше разобраться в проектировании API.  Вы можете грузить скрипты синхронно или асинхронно. В первом случае загрузка страницы может замедлиться. Если хотя бы с одним файлом возникнет проблема или он будет долго грузиться, то система не запустится и будет ждать завершения. Браузер остановит отрисовку страницы в ожидании завершения исполнения JavaScript-кода. Такой подход чреват задержками при загрузке сайта. А при асинхронной загрузке, даже если какой-то один файл будет загружаться долго, остальные продолжат загружаться приложением. Параллельная загрузка скриптов сильно ускоряет загрузку приложения, и проблемы с отдельными скриптами не влияют на исполнение всех остальных скриптов. Здесь можно почитать об этом подробнее. Вам не хватит одной оптимизации, чтобы обеспечить нужную скорость загрузки сайта. Придётся позаботиться обо всех аспектах вашего веб-приложения, чтобы добиться нужного прироста производительности. И это может быть связано со всем, что находится между сервером и браузером. Представьте несколько порезов на теле, через которые вы теряете кровь. Нужно найти и перевязать все порезы, чтобы полностью остановить кровопотерю. Ваше тело сможет залечить несколько порезов, но если их слишком много, то выжить будет затруднительно. Так и с веб-приложением: чтобы легко достичь бизнес-целей, вам придётся удерживать на минимальном уровне все эти «утечки производительности».