Какие файлы считаются очень большими при размещении на веб сайты
Веб-сайт состоит из множества файлов: текстового контента, кода, стилей, медиа-контента, и так далее. Когда вы создаёте веб-сайт, вы должны собрать эти файлы в рациональную структуру на вашем локальном компьютере, убедитесь, что они могут общаться друг с другом, и весь ваш контент выглядит правильно, прежде чем вы, в конечном итоге загрузите их на сервер. В статье Работа с файлами обсуждаются некоторые вопросы, о которых вам следует знать, чтобы вы могли рационально настроить файловую структуру для своего веб-сайта.
Файловые пути
Для того, чтобы файлы общались друг с другом, вы должны указать файлам путь друг к другу - обычно один файл знает, где находится другой. Чтобы продемонстрировать это, мы вставим немного HTML в наш файл index.html и научим его отображать изображение, которое вы выбрали в статье "Каким должен быть ваш веб-сайт?"
- Скопируйте изображение, которое вы выбрали ранее, в папку images .
- Откройте ваш файл index.html и вставьте следующий код в файл именно в таком виде. Не беспокойтесь о том, что все это значит - позже в этом руководстве мы рассмотрим структуры более подробно.
Некоторые общие правила о путях к файлам:
- Для ссылки на целевой файл в той же директории, что и вызывающий HTML файл, просто используйте имя файла, например, my-image.jpg .
- Для ссылки на файл в поддиректории, напишите имя директории в начале пути, плюс косую черту (forwardslash, слеш), например: subdirectory/my-image.jpg .
- Для ссылки на целевой файл в директории выше вызывающего HTML файла, напишите две точки. Например, если index.html находится внутри подпапки test-site , а my-image.jpg - внутри test-site , вы можете обратиться к my-image.jpg из index.html , используя ../my-image.jpg .
- Вы можете комбинировать их так, как вам нравится, например ../subdirectory/another-subdirectory/my-image.jpg .
На данный момент это все, что вам нужно знать
Примечание: Файловая система Windows стремится использовать обратный слеш (backslash), а не косую черту (forwardslash), например C:\windows . Это не имеет значения, даже если вы разрабатываете веб-сайт на Windows, вы всё равно должны использовать обычные слеши в вашем коде.
Где ваш веб-сайт должен располагаться на вашем компьютере?
Когда вы работаете на веб-сайте локально на вашем компьютере, вы должны держать все связанные файлы в одной папке, которая отражает файловую структуру опубликованного веб-сайта на сервере. Эта папка может располагаться где угодно, но вы должны положить её туда, где вы сможете легко её найти, может быть, на ваш рабочий стол, в домашнюю папку или в корень вашего жёсткого диска.
- Выберите место для хранения проектов веб-сайта. Здесь, создайте новую папку с именем web-projects (или аналогичной). Это то место, где будут располагаться все ваши проекты сайтов.
- Внутри этой первой папки, создайте другую папку для хранения вашего первого веб-сайта. Назовите её test-site (или как-то более творчески).
Какую структуру должен иметь ваш веб-сайт?
Далее, давайте взглянем на то, какую структуру должен иметь наш тестовый сайт. Наиболее распространённые вещи, присутствующие в любом проекте сайта, которые мы создаём: индексный файл HTML и папки, содержащие изображения, файлы стилей и файлы скриптов. Давайте создадим их сейчас:
- index.html : Этот файл обычно содержит контент домашней страницы, то есть текст и изображения, которые люди видят, когда они впервые попадают на ваш сайт. Используя ваш текстовый редактор, создайте новый файл с именем index.html и сохраните его прямо внутри вашей папки test-site .
- Папка images : Эта папка будет содержать все изображения, которые вы используете на вашем сайте. Создайте папку с именем images внутри вашей папки test-site .
- Папка styles : Эта папка будет содержать CSS код, используемый для стилизации вашего контента (например, настройка текста и цвета фона). Создайте папку с именем styles внутри вашей папки test-site .
- Папка scripts : Эта папка будет содержать весь JavaScript-код, используемый для добавления интерактивных функций на вашем сайте (например, кнопки которые загружают данные при клике). Создайте папку с именем scripts внутри вашей папки test-site .
Поиск подходящего хоста для вашего сайта
Сайты разделяются на две категории: дисковые сайты и серверные сайты . При разработке своего сайта важно понимать их отличие.
Дисковые сайты можно запускать на любом компьютере или даже с гибкого диска или CD-ROM . Они поддерживают только базовые функции HTML . Большинство веб- компонентов, поставляемых вместе с программой FrontPage, не действуют на дисковых сайтах.
Серверные сайты запускаются на веб-сервере, то есть на компьютере, который специально сконфигурирован для размещения сайтов. При небольших масштабах веб- сервером может быть локальный компьютер (например, ваш собственный), или это может быть сервер сети интранет вашей компании. Личные сайты часто размещаются на серверах провайдеров (поставщиков) услуг Интернет (ISP) . При более крупных масштабах веб-серверы, на которых размещены корпоративные сайты интернет , обычно принадлежат профессиональным компаниям по предоставлению веб-хостинга (Web hosting) .
Вы можете выбирать среди огромного числа компаний веб-хостинга, каждая со своими расценками и различными уровнями поддержки. Как и в случае выбора поставщика любого вида услуг - от сотовых телефонов до парикмахеров, - трудно оценить все варианты выбора и определить, какой из них наиболее подходит с точки зрения ваших требований.
Некоторые компании веб-хостинга предлагают бесплатные или очень недорогие услуги по веб-хостингу; однако будьте осторожны, поскольку это как раз такие случаи, когда вы действительно получаете то, за что платите. Надежные высокоскоростные серверы и надежные хорошо работающие специалисты никогда не бывают бесплатными или дешевыми! Сменить услуги веб-хостинга можно, но это может потребовать больших усилий, поэтому имеет смысл с самого начала принять обоснованное решение, а не учиться на собственных ошибках.
Географическое положение не должно быть существенным фактором выбора компании веб-хостинга, кроме того, что веб-хост нужно выбирать в своей стране, чтобы избежать потенциальных проблем в случае разногласий по поводу оплаты. Вам не потребуется физическое посещение офиса своей хостинговой компании, и почти все компании имеют бесплатные телефонные номера для необходимых телефонных консультаций.
Один из неплохих способов принятия решения или хотя бы сужения списка выбора до нескольких вариантов - это обратиться к людям, которые уже имеют корпоративные сайты, поддерживаемые провайдерами услуг Интернет (ISP), чтобы они высказали свое мнение о своих ISP (описали положительные и отрицательные стороны). Большинство профессиональных ISP предоставляют достаточно исчерпывающую информацию о своих сайтах, что поможет вам принять решение.
Поскольку вы являетесь разработчиком сайта на основе FrontPage, ваши возможности выбора уже ограничены, так как при использовании любых специальных функциональных средств FrontPage ваш ISP должен поддерживать расширения FrontPage Server Extensions. Компании веб-хостинга, поддерживающие FrontPage Server Extensions, рекламируют этот факт на своих сайтах. Многие из вышеперечисленных ресурсов позволят вам выполнить конкретный поиск служб хостинга, поддерживавающих средства FrontPage.
На современных web сайтах объем картинок может составлять от 30% до 70% всего размера страницы. Например, объем изображений на Хабре обычно составляет несколько мегабайт.
Большинство изображений в Web'e — это фотографии. Профильные фото в соц. сетях, альбом с телефона, профессиональные снимки и т.п. Правильная стратегия и инструменты для работы с фотографиями позволят сделать сайт быстрым для посетителей.
Формат для фотографий
Основной формат для хранения фотографий в Web'e — это JPEG. Однако иногда следует использовать и другие форматы.
Хорошо подходит для сложных изображений, т.е. как раз для фотографий. Основной принцип сжатия в этом формате — это уменьшение качества путем уменьшения детализации изображения.
Подбор показателя сжатия может уменьшить размер исходного файла в несколько раз без заметного ухудшения качества. Логика такая: чем ниже качество — тем легче файл. Обычно используют показатель качества от 80 до 90.
Это формат, разработанный специально для обслуживания изображений в Web'e. Может уменьшить размер файла в несколько раз без потери качества. Значительно лучше сжимает фотки, чем JPEG. Однако поддерживается еще не всеми браузерами.
PNG и GIF
Эти форматы не подходят для фотографий. PNG изображения сохраняются без потери качества и лучше всего подойдут для иконок и графики. Формат GIF имеет ограниченную палитру, однако поддерживает анимацию.
Загрузка фотографий на сервер
Если на вашем проекте существует необходимость загружать пользовательские фотографии, сначала необходимо выбрать принцип их хранения на сервере.
Если вы собираетесь работать с сотнями файлов, стоит выбрать древовидную структуру:
Это позволит избежать ситуации с тысячами файлов в одной папке (это тормозит работу файловой системы и вашу собственную). Лучше всего использовать вложенную структуру из папок длинной в два символа:
Инструменты
После загрузки фотографий на сервер, их следует обработать:
- Уменьшить размер до приемлемого. Нет смысла хранить и показывать оригинал фотографии размером 4000х3000 на сервере.
- Удалить все метаданные. Иногда объем такой инфы может составлять больше половины веса самого изображения.
- Провести оптимизацию для уменьшения размера файлов. Это ускорит загрузку у посетителя.
Для этого существует ряд инструментов.
ImageMagick
Сразу после загрузки фотографии на сервер, имеет смысл удалить все метаданные и изменить размер до 1000х1000:
GraphicsMagick
То же самое с помощью более производительного GraphicsMagick:
Jpegtran
Этот инструмент уменьшает размер JPEG файлов без потери качества.
cwebp
Утилита позволяет преобразовать изображение в формат Webp.
Отдача клиенту
Фотографии лучше всего отдавать Nginx'ом. Обязательно нужно настроить Cache-control и Keepalive для повышения скорости загрузки страниц:
Превью (thumbnails)
Часто нужно иметь возможность показывать небольшие версии фотографий (например, миниатюра профильной фотки).
Для этого необходимо генерировать нужные размеры при загрузке:
Тогда у каждого изображения будет соответствующая миниатюра.
Более удобный подход — генерировать превью на лету с помощью, например, Nginx image_filter модуля.
Поддержка Webp
Webp не поддерживается всеми браузерами, однако постепенно набирает популярность. Для того, чтобы извлечь пользу из этого формата, можно отдавать разные версии фотографий в зависимости от браузера посетителя.
Для каждой фотографии нужно сгенерировать webp версию:
Теперь необходимо отдать соответствующую версию картинки в зависимости от поддержки этого формата браузером:
Облака
Облачные технологии развиваются и дешевеют. Если у вас нет специфических задач по обработке фоток, лучше присмотреться к варианту использования внешнего сервиса для их хранения и отдачи.
Amazon s3
Это облачное хранилище с которым не придется думать о масштабировании. Храните терабайты и не парьтесь. Пример реализации загрузки фотографий на S3 в PHP:
После этого можно показывать фотку прямо с Амазона:
Cloudinary
Мощный сервис для работы с фотографиями в облаке. Ресайз, кроп, распознавание лиц, разные форматы, онлайн редактор и другие функции.
i.onthe.io
Мега простой сервис, распознает возможности браузера и подбирает оптимальный формат отдачи. Поддерживает URL API для ресайза и кропа.
В последнее время наметился интересный тренд — быстрое «распухание» веб-проектов до бесконечности. Объем данных многих популярных сайтов растет все быстрее и быстрее, их нужно куда-то девать, при этом эффективно бэкапить (весело будет, если файлы на 500Т потеряются :-) ), и конечно супербыстро раздавать клиентам, чтобы все их могли качать, качать, качать… на высокой скорости.
Для системного администратора задача даже редкого, ежедневного резервного копирования такого объема файлов навевает мысли о суициде, а менеджер веб-проекта просыпается в холодном поту от мысли о предстоящей профилактике датацентра на 6 часов (чтобы файлы перевести из одного датацентра в другой нужно пару раз загрузить багажник автомобиля винчестерами :-) ).
Коллеги с умным видом советуют приобрести одно из решений от NetApp, но, жаль, что бюджет у проекта в 1000 раз меньше, это вообще стартап… что делать будем?
В статье хочу разобрать частые кейсы дешевого и дорогого решения данной задачи — от простого к сложному. В конце статьи расскажу как задача решена в нашем флагманском продукте — всегда полезно сравнивать opensource-решения с коммерческими, мозгам нужна гимнастика.
Доступ в гардероб HighLoad
Если Вы хоть раз посещали конференцию HighLoad, то наверняка знаете, что на входе нужно обязательно ответить на вопрос — почему ставят nginx перед apache? Иначе дальше гардероба не пройти ;-)
Правильно, nginx или аналогичный обратный прокси позволяет эффективно раздавать файлы, особенно по медленным каналам, серьезно снижая нагрузку на сервер и повышая в целом производительность веб-приложения: nginx раздает кучу файлов, apache или php-fpm обрабатывают запросы к серверу приложений.
Такие веб-приложения живут хорошо, пока объем файлов не увеличивается до, скажем десятков гигабайт — когда несколько сотен клиентов начинают одновременно скачивать файлы с сервера, а памяти для кэширования файлов в ОЗУ недостаточно — диск, а потом и RAID — просто умрет.
Сервер статики
Чтобы более эффективно раздавать статику с разных доменов, ее выносят на отдельный сервер(а) статики:
Полезно на этом сервере использовать режим кэширования nginx и «быстрый» RAID (чтобы побольше клиентов требовалось для постановки диска «на колени»).
CDN — раздача
- Ценный клиент начал качать файл с московского сервера из Владивостока, да не из города, а с борта своей яхты. Канал конечно получился узкий.
- Случилась беда и уборщица случайно выдернула шнур питания из сервера раздачи статики, оборвав 10000 клиентов, качающих новый дистрибутив. Ну или в датацентре началась и «неизвестно» когда окончится профилактика — а точнее работы по поиску причины одновременного выхода из строя трех дизельных генераторов из двух.
- Наоборот, мог случиться такой наплыв клиентов, что стало не хватать серверной мощности раздавать одновременно столько статики, либо уже каналы загружены до предела.
В общем все понимают, что нужно быть как можно ближе к клиенту и отдавать клиенту столько статики, сколько он хочет, на максимально возможной быстрой скорости, а не сколько мы можем отдавать со своего сервера(ов).
Эти задачи в последнее время начала эффективно решать технология CDN.
Ваши файлы действительно становятся доступны клиенту на расстоянии вытянутой руки, откуда бы он их не начал качать: с Красной площади или с Сахалина — файлы будут отдаваться с ближайших ему серверов провайдера CDN.
«Вертикальное» масштабирование раздачи статики
Кружочки и колесики — распределенная файловая система
В этот момент у многих отключается левое, ответственное за логику, полушарие и их тянет к таинственным монстроподобным решениям — развернуть в нескольких датацентрах свою распределенную файловую систему. Возможно для проекта с большим бюджетом это будет выходом…
Тогда придется все это хозяйство администрировать самостоятельно, что потребует наличие видимо целого отдела эксплуатации :-)
Виртуальная файловая система
Одним из наиболее эффективных и, что важно, дешевых решений, является использование возможностей известных облачных провайдеров, дающих в аренду по очень вкусным, особенно при большом объеме данных, ценам, способ хранить неограниченный объем ваших файлов в облаке с очень высокой надежностью (гигантский DropBox). Провайдеры организовали на своих мощностях описанные выше распределенные файловые системы, высоконадежные и размещенные в нескольких датацентрах, разделенных территориально. Более того, эти сервисы, как правило, тесно интегрированы в сеть CDN данного провайдера. Т.е. вы будете не просто удобно и дешево хранить свои файлы, но и их максимально удобно для клиента раздавать.
Дело за малым — нужно настроить на своем веб-проекте прослойку или виртуальную файловую систему (или аналог облачного диска). Среди бесплатных решений можно выделить FUSE-инструменты (для linux) типа s3fs.
Однако, чтобы перевести текущее веб-приложение на эту дешевую и очень эффективную с точки зрения бизнеса технологию, нужно попрограммировать и внести ряд изменений в существующий код и логику приложения.
Модуль «Облачные хранилища» платформы «1С-Битрикс»
В нашем продукте мы тщательно проанализировали вышеописанные кейсы веб-проектов, которым нужно быстро доставлять файлы клиентам, а иногда файлов — терабайты и более и реализовали данные возможности «из коробки» в модуле «Облачные хранилища».
Мне честно нравится, что можно хранить данные отдельных модулей системы… в разных облачных хранилищах :-). Это реально диверсифицирует ваше файловое хранилище. Можно их раскидать в зависимости от адреса или типа клиента. Либо от типа информации — кто-то эффективно отдает легкую статику, кто-то тяжелый контент.
Итоги
Не важно, на чем вы пишите веб-проект — рано или поздно обязательно столкнетесь с леденящей душу проблемой лавинообразного увеличения объема файлов для хранения и раздачи и должны будете принять верное архитектурное решение.
В статье мы рассмотрели основные этапы и принципы организации раздачи файлов на веб-решениях любого размера, взвесили плюсы и минусы, посмотрели как это реализовано в платформе «1С-Битрикс». С учетом того, что объем раздаваемой веб-проектами информации очень быстро растет, данные знания актуальны и обязательно пригодятся как архитекторам веб-приложений, так и менеджерам проектов.
И конечно приглашаю всех на наш облачный сервис «Битрикс24», в котором мы активно используем вышеописанные технологии. Всем удачи!
Одна из первых вещей, которую я рекомендую своим клиентам, чтобы ускорить веб-сайты, сначала покажется парадоксом: вы должны разместить статические ресурсы на своём хостинге, отказавшись от сторонней CDN инфраструктуры. В этом коротком и, надеюсь, очень простом посте я хочу обрисовать недостатки хранения ваших статических файлов «на стороне» и потрясающие преимущества размещения их на своём хостинге.
О чём я говорю?
Это обычное дело для разработчиков — обращаться по ссылке к статическим активам, таким как библиотеки или плагины, которые находятся на сайтах и CDN ресурсах. Классический пример – jQuery.
Здесь есть ряд очевидных преимуществ, но моя цель далее в статье — разоблачить этот подход, и показать, что недостатки значительно преобладают.
(Сначала рассмотрим преимущества).
Риск: Падение скорости и Сбои
Я не буду вдаваться в слишком большое количество деталей в этом посте. У меня есть целая статья по поводу жизнеспособности третьей стороны и рисков, связанных с задержками и перебоями. Достаточно сказать, что если у вас есть какие-либо критичные ресурсы, связанные с провайдерами третьей стороны, и если провайдер страдает от сбоев и падения скорости или отключений, это довольно неприятная новость для вас. Вы тоже будете страдать от этого.
Если у вас есть какой-нибудь render-blocking CSS или синхронный JS, размещённый на сторонних ресурсах, идите и перенесите их в свою собственную инфраструктуру немедленно. Критичные активы слишком ценны, чтобы оставлять их на сторонних серверах.
Риск: Прекращение обслуживания
Это гораздо менее обычное явление, но что случится, если провайдер решит, что ему необходимо прекратить обслуживание? Это как раз то, что сделал Rawgit в октябре 2018 года, до сих пор (на момент написания статьи) грубый поиск по коду GitHub все еще даёт более миллиона ссылок на сервис, который сейчас находится в стадии закрытия, и почти 20 000 действующих сайтов продолжают ссылаться на него.
Риск: Уязвимости безопасности
Другая вещь, на которую следует обратить внимание, — это простой вопрос доверия. Если мы приносим контент из сторонних ресурсов на нашу страницу, нам приходится надеяться, что файлы, которые мы получаем, являются именно тем, что мы рассчитываем получить, и они делают именно то, что мы от них ожидаем.
Целостность Субресурсов
Надо отдать должное всем сторонним провайдерам, упомянутым до сих пор в этой статье, они делают всё, чтобы обеспечить целостность субресурсов (Subresource Integrity — SRI). SRI – это механизм, с помощью которого провайдер обеспечивает хэш (технически, хэш с последующим кодированием Base64) конкретного файла, который вы ожидаете и намереваетесь использовать. Браузер затем может проверить, что файл, который вы получили, является в точности тем, что вы запрашивали.
Ещё раз, если вы точно должны подключить к стороннему ресурсу статический контент, убедитесь, что действует SRI. Вы можете подключить SRI самостоятельно.
Расплата: Сетевые Согласования
Одна из самых больших и безотлагательных затрат, которую мы несём, — это стоимость открытия новых TCP соединений. Каждый новый ресурс, который нам необходимо посетить, требует открытия соединения, что может быть очень накладно: разрешение DNS, TCP рукопожатие, TLS согласование, всё это вносит свою лепту, и история усугубляется по мере задержек в соединении.
Я приведу пример, взятый прямо из собственной страницы Бутстрапа Getting Started. Они инструктируют пользователей подключить четыре файла.
Эти четыре файла находятся на трёх разных ресурсах, то есть, нам необходимо открыть три соединения TCP. Сколько это стоит? Ну, при достаточно быстром соединении, содержание этих статических файлов на стороне стоит 311мс, или 1,65х медленнее, чем при размещении их на собственном хостинге.
Связываясь с тремя различными источниками для обслуживания статических активов, мы в совокупности теряем ненужные 805мс на сетевые согласования.
ОК, не так уж страшно, но Trainline, мой клиент, обнаружил, что при уменьшении задержки на 300мс, посетители платят дополнительно 8 миллионов фунтов в год. Это довольно простой способ заработать 8 миллионов.
Только лишь переместив наши ресурсы на свой домен, мы полностью исключаем затраты на дополнительные соединения.
Для более медленного соединения, с большей задержкой, история намного хуже. Для 3G, сторонняя версия приходит медленнее 1.765с. Я полагал, что имелось в виду сделать наш сайт быстрее.
При соединении с большой задержкой, суммарные сетевые затраты составляют чудовищные 5.037с. Чего полностью можно избежать.
Перемещение файлов в нашу собственную инфраструктуру снижает время загрузки от 5.4с до 3.6с.
Если это недостаточный повод разместить ваши статические ресурсы у себя, я не знаю, какой ещё привести.
Preconnect
Расплата: Потеря Приоритезации
Все потоки (следовательно, ресурсы) с тем же самым TCP соединением, сохраняют приоритет, и браузер с сервером работают в тандеме, чтобы построить дерево зависимости всех этих приоритезированных потоков, чтобы мы могли вернуть критичные ресурсы быстрее и возможно, задержать доставку менее важных.
Если мы распределяем наши ресурсы по разным доменам, нам приходится открывать несколько уникальных TCP соединений. Мы не можем делать перекрёстные ссылки для приоритетов в этих соединениях, то есть мы теряем способность доставки файлов определённым хорошо продуманным способом.
Кэширование
По большому счету, хосты статических ресурсов, похоже, неплохо справляются с установлением долгоживущих директив max-age. Это имеет смысл, поскольку статический контент на версионных URL-адресах (как указано выше) никогда не изменятся. Это делает очень безопасным и рациональным усиление разумно агрессивной политики кэширования.
Тем не менее, это не всегда так, и, самостоятельно размещая свои ресурсы, вы можете разработать гораздо более индивидуальные стратегии кэширования.
Миф: Кросс-Доменное Кэширование
Более интересным является возможность междоменного кэширования активов. То есть, если множество сайтов ссылаются на одну и ту же версию jQuery, размещенную на CDN, то наверняка пользователи уже имеют этот конкретный файл на своем компьютере. Что-то вроде однорангового обмена ресурсами. Это один из самых распространенных аргументов в пользу применения стороннего поставщика статических активов.
К сожалению, не существует опубликованных доказательств, подтверждающих эти утверждения: нет оснований предполагать, что это действительно так. И наоборот, недавнее исследование Пола Кальвано намекает на то, что может иметь место обратное:
Есть ощутимый разрыв между возрастом кэша ресурсов CSS и веб-шрифтов 1-й и 3-й стороны. 95% шрифтов 1-й стороны старше 1 недели по сравнению с 50% сторонних шрифтов, которые имеют возраст менее 1 недели. Это дает веские основания для самостоятельного размещения веб-шрифтов.
В общем, кажется, что сторонний контент кэшируется хуже, чем собственный.
Еще более важно то, что Safari полностью отключил эту функцию из-за опасения злоупотреблений в отношении конфиденциальности, поэтому технология общего кэша не может работать на момент написания этой статьи для 16% пользователей во всем мире.
Короче говоря, хотя теоретически это хорошо, нет никаких доказательств того, что кросс-доменное кэширование каким-то образом эффективно.
Доступ к CDN
Еще одно широко распространенное преимущество обращения к поставщику статических ресурсов заключается в том, что он, скорее всего, будет использовать мощную инфраструктуру с возможностями CDN: глобальное распределение, масштабируемость, низкая задержка и высокая доступность.
Так как это абсолютно верно, если вы заботитесь о своей производительности, вам следует запускать свой собственный контент из CDN. С уровнем текущих цен на хостинг остаётся очень мало оправданий, почему вы не используете это для своих ресурсов.
Другими словами: если вы думаете, что вам нужен CDN для вашего jQuery, вам понадобится CDN для всего.
Размещайте статические ресурсы у себя на хостинге
На самом деле, есть очень мало причин оставлять свои статические ресурсы в чужой инфраструктуре. Возможные выгоды часто являются мифом, и даже если нет, компромиссы просто не стоят этого. Загрузка ресурсов из разных источников происходит значительно медленнее. В течение следующих нескольких дней потратьте десять минут на аудит ваших проектов и возьмите все сторонние статические ресурсы под свой контроль.
Небольшое отступление о регистре и пробелах
Вы заметите, что в этой статье, мы просим вас называть папки и файлы полностью в нижнем регистре без пробелов. Это потому что:
- Многие компьютеры, в частности веб-серверы, чувствительны к регистру. Так, например, если вы положили изображение на свой веб-сайт в test-site/MyImage.jpg , а затем в другом файле вы пытаетесь вызвать изображение как test-site/myimage.jpg , это может не сработать.
- Браузеры, веб-серверы и языки программирования не обрабатывают пробелы последовательно. Например, если вы используете пробелы в имени файла, некоторые системы могут отнестись к имени файла как к двум именам файлов. Некоторые серверы заменяют пробелы в вашем имени файла на "%20" (символьный код для пробелов в URI), в результате чего все ваши ссылки будут сломаны. Лучше разделять слова дефисами, чем нижними подчёркиваниями: my-file.html лучше чем my_file.html .
Говоря простым языком, вы должны использовать дефис для имён файлов. Поисковая система Google рассматривает дефис как разделитель слов, но не относится к подчёркиванию таким образом. По этим причинам, лучше всего приобрести привычку писать названия ваших папок и файлов в нижнем регистре без пробелов, разделяя слова дефисами, по крайней мере, пока вы не поймёте, что вы делаете. Так в будущем вы столкнётесь с меньшим количеством проблем.
Что должно быть сделано?
К настоящему моменту структура вашей папки должна выглядеть примерно так:
Аннотация: Изучив эту лекцию, вы сможете: конфигурировать компьютер как персональный веб-сервер, находить компанию для веб-хостинга или поставщика (провайдера) услуг Интернет.
Нет никакого смысла в прохождении всех трудностей создания привлекательного информативного творческого сайта, если никто его не увидит. Кульминацией вашей работы является момент, когда вы делаете свой сайт доступным внешнему миру, публикуя его в интранет или интернет . Публикация сайта в первый раз известна также под названием запуска сайта.
Для сайта публикация означает копирование всех файлов этого сайта на веб- сервер . После публикации сайта он считается "действующим"; это означает, что предназначаемая группа людей (в случае интранет ) или любой человек (в случае интернет ) могут видеть ваш сервер в своих браузерах. Вы можете публиковать веб- сервер тремя способами:
В этой лекции описывается, как и когда вы можете публиковать ваш сайт, созданный с помощью FrontPage. Для первого упражнения вам не потребуются какие-либо учебные файлы. Для остальных упражнений будет использоваться учебный сайт, который хранится в папке Office XP SBS\FrontPage\Chap21.
Важно. Во втором упражнении этой лекции показано конфигурирование вашего компьютера как персонального веб-сервера. В четвертом упражнении вы опубликуете сайт на вашем персональном веб-сервере, поэтому вам нужно выполнить второе упражнение, прежде чем перейти к четвертому.
Читайте также: