Один сервис AWS, который мгновенно заставлял мой сайт почувствовать себя быстрее везде
25 июня 2025 г.Было время, когда я думал, что быстрый сервер означал быстрый сайт.
Но я был неправ.
Независимо от того, насколько оптимизирован мой код, пользователи из Европы или Азии наблюдали медленное время нагрузки.
Между тем, для меня все хорошо, потому что мой сервер был в той же стране.
Так что я начал копать.
Именно тогда я нашел настоящее узкое место:расстояние.
Решение?
AWS Cloudfront.
Это не просто улучшило мое время нагрузки - это пополам для пользователей по всему миру.
Вот как именно я это сделал.
Шаг 1: Понимание проблемы
Мой сайт был размещен на экземпляре EC2 в Вирджинии (США-восток-1).
Отличное выступление в США.
Ужасно везде.
Когда посетитель в Германии загрузил мою домашнюю страницу, просьба должна была пройти через океан.
Это был не сервер - это была поездка.
Даже с GZIP, управлением кешем и оптимизацией изображений я все еще терял 2–4 секунды при начальной загрузке страницы.
Не идеально, если вы заботитесь о скорости отскока.
Шаг 2: Что такое Cloudfront?
CloudFront - это сеть доставки контента AWS (CDN).
Он распространяет ваше статическое (и даже динамическое) контент по местам 300+ краев по всему миру.
Когда пользователь посещает ваш сайт, CloudFront обслуживает контент изБлижайший сервер Edge, не ваш сервер происхождения.
Это означает, что меньше пройденных миль, более быстрое время отклика.
Это также разумно кэширует содержание, уменьшая нагрузку на бэкэнд.
Идеально подходит для страстных веб-сайтов, спа-салонов или любого сайта, который обслуживает повторный трафик.
Шаг 3: Подготовка моего контента для Cloudfront
Перед использованием Cloudfront я позаботился о том, чтобы у моего сайта был:
- Статические активыХранится на S3 (Images, CSS, JS)
- HTML -файлыразвернуто через S3 (мой сайт был статичным, но это работает с EC2 или другими бэкэнами)
- ПравильныйКонтент-типЗаголовки в файлах (важно для кэширования)
- ПравильныйКонтроль кэшаМетаданные установлены на объектах S3 (так что Cloudfront знает, что кешю и как долго)
Без этого Cloudfront все равно будет работать, но не очень хорошо.
Плохие заголовки = без кеша = без победы.
Шаг 4: Создание распределения Cloudfront
Вот как именно я его настроил:
- Открытая консоль AWS> CloudFront
- Щелкнул«Создать распространение»
- ПодДомен происхождения, Я выбрал свое ведро S3 (то, что хостил мой сайт)
- ЛевыйПуть происхожденияпусто (так как я хотел подавать все ведро)
- НаборПолитика протокола зрителя«перенаправить HTTP на HTTPS»
- ПодПоведение кеша по умолчанию, Я включил:
- Кэширование на основе заголовков: Нет (для улучшения хитов кеша)
- Автоматически сжатие объектов: Да
- ДляЦеновой класс, Я выбрал «Использовать все места края» для максимального глобального охвата
Наконец, я создал распространение.
На развертывание потребовалось около 15 минут.
Шаг 5: Соединение моего домена
CloudFront дает вам домен по умолчанию, какd1234.cloudfront.netПолем
Не очень хорошо для производства.
Чтобы использовать мой пользовательский домен (www.mysite.com):
- Я пошелМаршрут 53(или ваш поставщик DNS)
- Создал аCnameУказывание записи
www.mysite.comк моему домену Cloudfront - В Cloudfront, подАльтернативные доменные имена (CNAME)Я добавил
www.mysite.com - НастроитьСертификат SSLВ ACM (My Manager Sertificate Manager) Amazon) для моего домена
- Связал его в распределение Cloudfront
После этого мой домен проработал через Cloudfront - в целом, во всем мире и быстро.
Шаг 6: Измерение результатов
Я не просто хотел «почувствовать» разницу.
Я хотел доказательства.
Итак, я запустил тесты, используя:
- Google PageSpeed Insights
- WebpageTest.org(С серверами в Азии и Европе)
- Маяк в Chrome Devtools
Перед CloudFront (Германия тестовый сервер):
- Время до первого байта (TTFB): ~ 900 мс
- Полная нагрузка: ~ 3,5 секунды
После Cloudfront:
- TTFB: ~ 200 мс
- Полная нагрузка: ~ 1,6 секунды
Это более чем в 2 раза быстрее.
И в некоторых регионах это было даже быстрее, чем это.
Шаг 7: тонкая настройка поведения кеша
Через неделю я заметил, что некоторые файлы не обновлялись, как и ожидалось.
Оказывается, я установилДлинный кеш продолжительностьВ файлах JavaScript.
Чтобы исправить это, я:
- Обновленные метаданные объекта S3 для использования
Cache-Control: max-age=3600, must-revalidate - В Cloudfront, созданповедение кешаЧтобы установить разные правила для:
/index.html→ короткий кеш (1 минута)/static/*→ Длинный кеш (1 месяц)
- ВключеноНедействительностьКогда я нажимал обновления (тоже можно сделать через CLI)
Это дало мне лучшее из обоих миров:
Быстрое кэширование + гибкость для обновления контента при необходимости.
Что вы должны знать перед использованием Cloudfront
Вот несколько простых уроков, которые я усвоил:
- Используйте S3 + CloudfrontЕсли вы обслуживаете статический сайт. Это дешево и надежно.
- Всегда настройте заголовкиПолем Без правильного
Content-TypeиCache-Control, производительность прибывает. - CloudFront журналыЗолотая жила. Используйте их, чтобы увидеть, откуда приходит ваш трафик и что кэшируется.
- Осторожно провести недействительнуюПолем Недействительность Cloudfront является мощной, но избегайте частых недействительных полных дорожек-они стоят денег и времени.
- Ценовой класс имеет значениеПолем Если ваш трафик находится в основном в одном регионе, используйте региональную настройку краев, чтобы снизить затраты.
Последние мысли
Вам не нужен сложный бэкэнд, чтобы стать глобальным.
Вам не нужно 10 инженеров или CDN в 10 тысяч долларов в месяц.
Вам нужно четкое понимание того, где разбивается ваша производительность, и простой инструмент для его исправления.
Для меня это была AWS Cloudfront.
Это позволило мне обслуживать мой сайт быстрее, везде, без изменения ни одной строки кода.
Результаты были реальными.
Разница была видна.
А настройка? Всего несколько кликов.
Если вы используете сайт общедоступного и еще не использовали Cloudfront, вы оставляете скорость на столе.
Оригинал