Локальные файлы против CDN

Если время загрузки веб-сайта вызывает беспокойство, что обычно лучше использовать при обращении к файлу JavaScript или CSS? Будет ли лучше использовать CDN или просто добавить больше HTTP-запросов?

CDN должен использоваться для всех статических файлов (.css / .js / images).

Однако иногда файлы javascript или css могут иметь динамический аспект, например включать уникальную пользовательскую строку или что-то в этом роде. В этой ситуации серверу CDN придется связываться с исходным сервером при каждом запросе, что приведет к поражению цели.

Если ваш CSS и Javascript статичны для всех пользователей, тогда использование CDN - правильный путь. Это не приведет к дополнительным HTTP-запросам, поскольку будет загружать только файлы css и js из CDN вместо вашего собственного веб-сервера (если вы не используете встроенный код). Таким образом, вместо того, чтобы пользовательский браузер загружал эти запросы с вашего сервера, они будут загружаться через CDN, нет никаких дополнительных запросов, которые вы просто меняете, куда отправлять эти запросы (опять же, если вы в настоящее время не используете встроенный код).

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

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

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

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

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

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

Использование CDN может быть как бременем, так и преимуществом для веб-сайта, все в зависимости от того, как он был реализован.

Положительные очки

1. Статический контент хранится ближе к конечному пользователю (более быстрое время загрузки)
2. Дополнительные субдомены ( cdn1.example.comи cdn2.example.comт. Д.), Это помогает с внутренним ограничением в браузерах, где они ограничивают загрузку файлов двумя одновременными файлами с одного и того же полного доменного имени одновременно. Другими словами, используя этот пример, вы будете получать доступ к HTML из www.example.comи в то же время будете загружать 2 файла cdn1.example.com, 2 файла cdn2.example.comи 2 файла cdn3.example.comсо всех трех доменов CDN, получающих доступ к одной услуге CDN и источнику.

Хостинг на CDN имеет много недостатков:

1. Конфиденциальность. Каждый раз, когда вы заходите на сайт, на котором размещены скрипты / таблицы стилей / шрифты в CDN, CDN знает о вашем посещении сайта.
2. Оффлайн время. В последние недели у cloudflare и т. Д. Было несколько часов, когда время их загрузки было очень медленным или даже в автономном режиме в течение нескольких минут. В лучшем случае ваш сайт выглядит некрасиво, когда это происходит, в худшем - он совершенно непригоден для того времени, когда у ваших конкурентов тоже возникают проблемы, и вы можете получить их клиентов, если ваш сайт был в сети, а их нет.
3. Безопасность. CDN может быть скомпрометирован (это случилось раньше). В лучшем случае ваш сервер распространяет вредоносное ПО, а в худшем - ваши данные теперь общедоступны или исчезли.

По сравнению с этим преимущества незначительны:

1. Меньше данных для загрузки: мы говорим о примерно 100 КБ скриптов на сайт. 1 изображение в низком качестве действительно имеет значение для этого. Если у вас нет веб-сайта с ограниченным числом посещений в 5 000 000 в минуту, это не будет иметь значения. И если вам, вероятно, следует настроить лучшую серверную среду с балансировщиком нагрузки и большим количеством веб-серверов, потому что использование CDN не решит ваших проблем.
2. Более быстрое время загрузки, поскольку серверы CDN ближе к клиенту: во времена, когда задержка от ЕС до США составляет около 100 мс для почти всех соединений, CSS загружается за 50 мс или 100 мс.

Нет нужды использовать CDN в производственной среде.