Статический хостинг сайтов: кто самый быстрый? AWS, Google, Firebase, Netlify или GitHub?

Я размещаю этот сайт на AWS с 2012 года, и многое изменилось в облачном бизнесе. Поэтому мне стало интересно, является ли AWS Cloudfront лучшим местом для размещения моего статического веб-сайта. А как насчет Google Cloud Storage, Firebase Hosting, Netlify или GitHub Pages? Как они складываются?

Ну давай узнаем!

Я начал с создания учетной записи в нескольких публичных облаках, которые позволяют размещать статические веб-сайты. Статические веб-сайты создаются с использованием только HTML, CSS и Javascript, поэтому базового хранилища достаточно. Я закончил тем, что создал учетную запись на этих услугах:

Я также создал простой веб-сайт для размещения всех этих услуг. Я просто взял домашнюю страницу своего сайта со всеми принадлежащими ему активами и загрузил ее на все эти сервисы. Домашняя страница размером около 10 КБ (только HTML).

Чтобы проверить производительность каждого сервиса, я подписался на бесплатную 14-дневную пробную версию Pingdom. Они измеряют время работы и время отклика от их всемирная сеть зондовых серверов , Я создал одну проверку для каждого сервиса и использовал только конечные точки HTTPS. Я также добавил /index.html к каждому URL, чтобы не тратить время на разрешение документа индекса. Я настроил каждую проверку для запуска каждую минуту в течение следующих 10 дней .

В последний день я прекратил проверки и загрузил исходные данные CSV для анализа.

Давайте немного поговорим о том, как я настроил каждый сервис.

Netlify, GitHub Pages и Firebase Hosting - самые простые варианты для размещения статического сайта. Просто дайте им ваши файлы, и они будут размещать их для вас. Конфигурации практически нет, и вы не можете связываться с настройками. Так что я не сделал!

S3 и Google Storage немного сложнее. Для хранения ведра вы должны выбрать регион. На S3 я выбрал регион eu-london и в качестве регионального сегмента Google я выбрал europe-west2 (который также находится в Лондоне).

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

Итак, прежде чем мы углубимся в результаты: каковы мои ожидания?

  • Платный сервис превзойдет бесплатные альтернативы. Это имеет смысл, потому что вы платите за то, чтобы они были быстрыми!

  • Google Cloud , вероятно, будет очень быстрым, в конце концов, это Google. То же самое для Firebase, так как они являются частью Google!

  • CloudFront - это то, что я использую для своего сайта, и это не сутулость. Надеемся, что результаты будут отражать это.

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

  • GitHub Pages используется многими проектами с открытым исходным кодом, поэтому я думаю, что это также должно быть хорошо!

Хватит с ожиданиями. Давайте посмотрим, как они на самом деле складываются друг против друга ...

Так как же выглядели результаты? Ну вот обзор Pingdom:

Ну вот обзор Pingdom:

С первого взгляда можно сказать, что GitHub Pages - самый быстрый и что все работают достаточно стабильно. Netlify, однако, несколько странно. Он работает очень быстро, но имеет огромный всплеск на графике.

Давайте внимательнее посмотрим. Я экспортировал все необработанные данные в CSV и проанализировал их в Excel. Давайте начнем с самой основной статистики: среднее и среднее время отклика со стандартным отклонением.

Есть несколько вещей, которые сразу же привлекают наше внимание:

  • S3 намного медленнее по сравнению с другими
  • Netlify имеет высокое стандартное отклонение, которое может указывать на нестабильную производительность
  • Другие сервисы практически одинаковы по производительности

S3, выполняющий значительно хуже, чем другие, связан с тем фактом, что ведро S3 привязано к региону. В моем случае регион ЕС-Запад-1, который находится в Лондоне. Pingdom проводит тесты со всего мира, и это означает, что их европейские серверы будут быстрее реагировать по сравнению с серверами в США или Азии. Плохая производительность S3 ожидалась. Он не использует CDN (для этого предназначен CloudFront), и его привязка к определенному региону не помогает.

Единственная причина, по которой я включил S3 в этот тест, состояла в том, чтобы сравнить его с региональным сегментом Google. Со стороны Google мы видим что-то смешное: региональные и мультирегиональные показатели почти одинаковы. Google довольно расплывчато в том, как это происходит. На их веб-сайте упоминается, что они кэшируют ваш контент по всему миру, но они не обсуждают детали. Тем не менее, приятно видеть, что это работает так хорошо из коробки!

Netlify, с другой стороны, страдает от скачков в своей производительности (как мы могли видеть на сайте Pingdom). Это среднее и среднее время отклика очень хорошее, но отклонение слишком велико. Может быть, что-то делать с их «гибридным» решением CDN?

Точечная диаграмма всех времен отклика четко показывает различия в производительности Netlify:

Точечная диаграмма всех времен отклика четко показывает различия в производительности Netlify:

Это становится еще более очевидным, когда мы рисуем блокпост данных:

Это становится еще более очевидным, когда мы рисуем блокпост данных:

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

Мы также можем сделать некоторые другие интересные наблюдения:

  • Firebase хостинг не только быстрый, но и очень последовательный! Самое высокое время отклика все еще намного быстрее, чем максимальное время отклика других сервисов.
  • S3 является более низким максимальным значением, чем CloudFront, может быть, проблема в измерении? Тем не менее, другие результаты испытаний CloudFront намного быстрее и последовательнее по сравнению с S3.
  • Мультирегиональное ведро Google зафиксировало более высокий максимум, чем региональное ведро. Это немного странно, но, опять же, это ошибка измерения. Если вы посмотрите более внимательно, вы увидите, что для подавляющего большинства измерений многорегиональный сегмент работает немного лучше.
  • GitHub Pages можно сравнить с Firebase Hosting и Google Storage. Очень высокая производительность от бесплатного сервиса без реальных жестких ограничений.

Итак, пришло время сделать некоторые выводы. Все эти сервисы являются отличным вариантом для размещения ваших статических сайтов.

Лучшим универсальным исполнителем, без сомнения, является хостинг Firebase . Мало того, что это быстро, это было самым последовательным во время моего теста.

За Firebase следует GitHub Pages . У них более быстрое среднее и среднее время отклика, но стандартное отклонение несколько выше.

За ними следуют CloudFront и Google Storage . Я снова был удивлен тем, как хорошо ведро Google работает без какой-либо дополнительной настройки.

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

S3 (без CloudFront) был значительно медленнее, чем другие, но этого следовало ожидать, учитывая, что по умолчанию он не использует CDN.

Это немного сложно. Если вы хотите совершенно бесплатное решение, то вам обязательно стоит рассмотреть GitHub Pages. Вы должны сделать свой сайт открытым исходным кодом, хотя.

Не хотите делать свой сайт открытым исходным кодом, но все же хотите разместить его бесплатно? Ну, тогда Firebase Hosting, вероятно, ваш лучший выбор. Это не совсем бесплатно, но у него есть бесплатный уровень, который должен быть достаточным для небольших сайтов. Netlify также вариант здесь и должен работать хорошо в большинстве случаев.

Для платных решений нет особой разницы. Если вам нужна скорость, как AWS CloudFront, так и хранилища Google - отличные варианты. Выбор между ними затруднен, поэтому попробуйте выбрать тот, с которым вы уже знакомы, или тот, который дешевле цены.

Хотите сделать свой собственный анализ? Экспорт сырых CSV из Pingdom доступен на GitHub ,