Если вы разрабатываете проекты на ExtJS, то наверняка в вашем дереве исходных кодов есть сам дистрибутив библиотеки и вы его подключаете на всех страницах, где используются ее возможности. И храните саму библиотеку также у себя на хостинге. Это, конечно, правильный и простой подход, но имеет свои ограничения. Во-первых, в большинстве случаев именно ExtJS будет самым большим компонентом страницы, ведь его общий объем около 1 Мб, а значит и будет тормозить страницу, пока браузер не загрузит всю библиотеку. Как выход, все рекомендуют настраивать сжатие (например, mod_deflate, хорошо, что браузеров, которые не понимают сжатый контент, теперь почти нет, а у кого есть, тот, как говорится, сам себе злобный буратино), теги кеширования и т.п. Ну и на крайний случай — собирать под свой проект, или даже под каждую страницу, свою версию библиотеки, включая туда необходимые компоненты. Я уже писал о структуре фреймворка и расположенном на сайте конструкторе, который сможет автоматически сформировать вам ваш личный дистрибутив.

Однако теперь есть еще одна возможность хранить эти подключаемые файлы. Существуют такие системы как CDN — Content Delivery Networks, которые имеют собственную сеть географически разнесённых серверов, которые подключены к мощным скоростным каналам и находятся поблизости от пользователя, запрашивающего тот или иной файл. Если он хранится в CDN, то отдача файла будет происходить с сервера, который ближе всего к пользователю, а значит — файл загрузится быстрее.

В партнерстве с компанией CacheFly, ExtJS теперь может хранить свои сборки в такой сети. Кроме самих JS файлов хранятся так же и стилевые файлы (ext-all.css, который также достаточно объемный). Более того, теперь создавая собственную сборку фреймворка через веб-интерфейс, вы можете сразу поместить ее в CDN и использовать напрямую, просто поменяв ссылки. Учтите, что если ваш вариант сборки фреймворка уже кем-то используется, то новый файл не будет создаваться, а вам просто выдадут ссылку на уже закешированный.

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

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

Честно говоря, грузится не медленнее уж точно. В частности из-за того даже, что загрузка идет с другого хоста, а значит параллельно браузер запрашивает другие файлы, а это важно, так как одновременное количество запросов к одному домену ограничено. Проверяя доступность сайта по пингу, в среднем значения были на уровне или ниже данных для моего сервера, хотя когда я проверял в прошлый раз, различие было значительнее, раза в полтора, на пользу CacheFly. Так что советовать что-то сложно — это надо лично пробовать, однако хуже не будет, это уж точно.