Где хранить css файлы
Обновлено: 04.07.2024
Веб-сайт состоит из множества файлов: текстового контента, кода, стилей, медиа-контента, и так далее. Когда вы создаёте веб-сайт, вы должны собрать эти файлы в рациональную структуру на вашем локальном компьютере, убедитесь, что они могут общаться друг с другом, и весь ваш контент выглядит правильно, прежде чем вы, в конечном итоге загрузите их на сервер. В статье Работа с файлами обсуждаются некоторые вопросы, о которых вам следует знать, чтобы вы могли рационально настроить файловую структуру для своего веб-сайта.
Где ваш веб-сайт должен располагаться на вашем компьютере?
Когда вы работаете на веб-сайте локально на вашем компьютере, вы должны держать все связанные файлы в одной папке, которая отражает файловую структуру опубликованного веб-сайта на сервере. Эта папка может располагаться где угодно, но вы должны положить её туда, где вы сможете легко её найти, может быть, на ваш рабочий стол, в домашнюю папку или в корень вашего жёсткого диска.
- Выберите место для хранения проектов веб-сайта. Здесь, создайте новую папку с именем web-projects (или аналогичной). Это то место, где будут располагаться все ваши проекты сайтов.
- Внутри этой первой папки, создайте другую папку для хранения вашего первого веб-сайта. Назовите её test-site (или как-то более творчески).
Небольшое отступление о регистре и пробелах
Вы заметите, что в этой статье, мы просим вас называть папки и файлы полностью в нижнем регистре без пробелов. Это потому что:
- Многие компьютеры, в частности веб-серверы, чувствительны к регистру. Так, например, если вы положили изображение на свой веб-сайт в test-site/MyImage.jpg , а затем в другом файле вы пытаетесь вызвать изображение как test-site/myimage.jpg , это может не сработать.
- Браузеры, веб-серверы и языки программирования не обрабатывают пробелы последовательно. Например, если вы используете пробелы в имени файла, некоторые системы могут отнестись к имени файла как к двум именам файлов. Некоторые серверы заменяют пробелы в вашем имени файла на "%20" (символьный код для пробелов в URI), в результате чего все ваши ссылки будут сломаны. Лучше разделять слова дефисами, чем нижними подчёркиваниями: my-file.html лучше чем my_file.html .
Говоря простым языком, вы должны использовать дефис для имён файлов. Поисковая система Google рассматривает дефис как разделитель слов, но не относится к подчёркиванию таким образом. По этим причинам, лучше всего приобрести привычку писать названия ваших папок и файлов в нижнем регистре без пробелов, разделяя слова дефисами, по крайней мере, пока вы не поймёте, что вы делаете. Так в будущем вы столкнётесь с меньшим количеством проблем.
Какую структуру должен иметь ваш веб-сайт?
Далее, давайте взглянем на то, какую структуру должен иметь наш тестовый сайт. Наиболее распространённые вещи, присутствующие в любом проекте сайта, которые мы создаём: индексный файл HTML и папки, содержащие изображения, файлы стилей и файлы скриптов. Давайте создадим их сейчас:
- index.html : Этот файл обычно содержит контент домашней страницы, то есть текст и изображения, которые люди видят, когда они впервые попадают на ваш сайт. Используя ваш текстовый редактор, создайте новый файл с именем index.html и сохраните его прямо внутри вашей папки test-site .
- Папка images : Эта папка будет содержать все изображения, которые вы используете на вашем сайте. Создайте папку с именем images внутри вашей папки test-site .
- Папка styles : Эта папка будет содержать CSS код, используемый для стилизации вашего контента (например, настройка текста и цвета фона). Создайте папку с именем styles внутри вашей папки test-site .
- Папка scripts : Эта папка будет содержать весь JavaScript-код, используемый для добавления интерактивных функций на вашем сайте (например, кнопки которые загружают данные при клике). Создайте папку с именем scripts внутри вашей папки test-site .
Файловые пути
Для того, чтобы файлы общались друг с другом, вы должны указать файлам путь друг к другу - обычно один файл знает, где находится другой. Чтобы продемонстрировать это, мы вставим немного 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, вы всё равно должны использовать обычные слеши в вашем коде.
Что должно быть сделано?
К настоящему моменту структура вашей папки должна выглядеть примерно так:
Летом проходил курсы веб-разработчиков битрикс (для начинающих), во всех примерах CSS, JS и прочее хранилось в /templates/папка_шаблона/.
+ в компонентах часто необходимо визуально оформить вывод информации с скриптами и стилями соответственно, которые в итоге лежат в папке компонента и подключается при необходимости.
В чем собственно проблема.
Наш руководитель сказал вынести css и js в корень, к примеру /assets/css и /assets/js - вроде бы все ок, это не чего не значит.
Мне сказали так:
| Цитата |
|---|
| вынеси все стили за пределы папки bitrix/ которая является системной |
| Цитата |
|---|
| я хочу это обсудить и понять почему именно так, а не иначе |
| Цитата |
|---|
| 1. потому как на папку /bitrix вполне верятно настроить исключительные права, которые не дадут доступа для низжелащих папок 2. папку в корне /static/ можно вынести в CDN для оптимизации 3. простота обновления 4. нельзя пользователю показывать реальные пути до системных папок |
Собственно я хочу узнать мнение участников сообщества по поводу таких аргументов и что вы вообще думаете на эту тему.
Про CDN меня потому что тоже поразило, т.к. я полез в настройки этого модуля и там нет указания каких либо директорий, а только указывается адрес сайта с которого собирается статика, я так понял это все происходит в автоматическом режиме.
Я хочу просто разобраться и сделать определенные выводы для себя.
Мне тоже интересно мнение участников, пока напишу свое.
| Цитата |
|---|
| senty пишет: Летом проходил курсы веб-разработчиков битрикс (для начинающих), во всех примерах CSS, JS и прочее хранилось в /templates/папка_шаблона/. |
Олично, как тебе обучение?
| Цитата |
|---|
| 1. потому как на папку /bitrix вполне верятно настроить исключительные права, которые не дадут доступа для низжелащих папок |
Не нужно ставить такие права, в папке bitrix много файлов, редактируемых разработчиком. Т.е. выставление таких прав - это ошибка.
| Цитата |
|---|
| senty пишет: 2. папку в корне /static/ можно вынести в CDN для оптимизации |
в CDN попадает файлы только из /upload/ и /bitrix/
Совсем не понятно. Если речь об удобстве редактирования в одном файле, то можно все стили компонентов сложить в один файл в шаблоне. Иногда так действительно удобно. О скриптах так не скажу.
| Цитата |
|---|
| senty пишет: 4. нельзя пользователю показывать реальные пути до системных папок |
Мне тоже интересно мнение участников, пока напишу свое.
| Цитата |
|---|
| senty пишет: Летом проходил курсы веб-разработчиков битрикс (для начинающих), во всех примерах CSS, JS и прочее хранилось в /templates/папка_шаблона/. |
Мне все понравилось, жду следующие курсы. Не успел все лекции пройти из второй части, но и эту проблему вы решили.
Собственное только один ваш ответ разъясняет все аргументы предоставленные коллегой по поводу размещения стилей и скриптов в корне.
Еще один важный момент вспомнил.
По моей логике (я не настолько опытный веб-разработчик и чаще всего я только предполагаю и пытаюсь узнать действительность) одна важнейших составляющих CMS - это как раз таки компоненты и модули, которые лежат себе в своих папочках и ни кого не трогают и могут подключать свои JS и CSS (которые хранятся в директории компонента/модуля). Это я на тот момент описал так:
| Цитата |
|---|
| возьмем случай с компонентом, когда нам необходимо добавить какой-либо функционал за рамками проекта, где еще требуется визуальное оформление с использованием css и js, мы все это дело размещаем в папке bitrix/components/папка компонента |
| Цитата |
|---|
| вообще считается моветоном, потому как увеличивает время загрузки страницы (причем значительно) и ее общую семантику, про это я уже говорил |
3 CSS (или JS), но на этот случай в Битрикс есть стандартный функционал, который объединяет CSS и JS.
| Цитата |
|---|
| Цитата возьмем случай с компонентом, когда нам необходимо добавить какой-либо функционал за рамками проекта, где еще требуется визуальное оформление с использованием css и js, мы все это дело размещаем в папке bitrix/components/папка компонента |
Я надеюсь речь о размещении в шаблоне по пути bitrix/components/папка компонента ? Из курса должны были запомнить что раздел с компонентами из пространства имен bitrix менять нельзя.
Как я писал выше, стили компонентов можно размещать и в общем файле стилей, если в проекте так удобнее, все зависит от задач. Ну и механизм объединения файлов стилей упрощает работу, если удобнее хранить стили в шаблоне компонента.
Как, всё-таки, правильно подключать стили и js файлы?
Во многих источниках указано, что наиболее верным является такой способ: css в начале(в head), а js в конце, перед закрытием . Но когда я смотрю на крупнейших ресурсах как это сделано, то получается везде по-разному, а ведь, как я понимаю, крупнейшие ресурсы заботятся о скорости загрузки сайта в первую очередь. Кто-то всё размещает в head, кто-то и так, и сяк.
Или тут есть какие-то "подводные камни" на которые стоит обратить внимание? Просто весьма интересно. Сам всегда размещаю css в начале, а все js в конце.
Крупнейшие ресурсы проверяли на скорость? Действительно все быстрые? Просто интересно, не подумайте ничего. Парочку как-то проверяла, а там о скорости и речи нет.Почему модель css вверху, js внизу более привлекательная?
Тут важный момент это то, что браузер загружает страницу сверху вниз
Сценарий №1
Есть страница на которой скрипты и стили вверху
Примерный сценарий ее загрузки будет такой:
- Загрузка стилей
- Загрузка скриптов
- Загрузка остальной разметки
В данном сценарии есть недостаток, до момента отображения непосредственно контента страницы браузер должен загрузить стили и скрипты, что дает довольно большую задержку если это крупный ресурс.
Сценарий №2
Есть страница на которой стили вверху, а скрипты перед закрывающим тегом body
Примерный сценарий ее загрузки будет такой:
- Загрузка стилей
- Загрузка разметки
- Загрузка скриптов
В данном сценарии есть преимущества по сравнению с первым, до момента отображения непосредственно контента страницы браузер должен загрузить только стили, а скрипты он загрузит в последнюю очередь, что позволяет пользователю быстрее увидеть содержимое страницы.
Почему стили стоит оставлять вверху? Если стили также как и скрипты перенести вниз страницы то разметка после загрузки будет не стилизована, что будет выглядеть довольно некрасиво до момента загрузки стилей.
Размер: 18,4 Мб.
Длительность: 14 мин. 45 сек.
Сегодня у нас на повестке дня вопрос хранения файлов, которые есть у вас на сайте.
Я хочу рассказать вам о некоторых из способов, которые можно использовать для этих целей.
Вообще почему этот вопрос актуален? Ведь, казалось бы - храни себе все необходимые файлы на сервере хостера - и все будет ок.
Это так, но только с рядом оговорок:
1. Как правило, хостеры не выдают изначально большого пространства под ваши проекты.
2. Вы можете перейти на более дорогой тарифный план, и вам прибавят места, которые вы можете использовать.
Но здесь тоже есть свой минус. Скажем, ваш сайт не требователен именно к вычислительным ресурсам хостинга, т.е. его посещает не такая уж и толпа людей.
Поэтому выходит так, что вы получаете дополнительное место под файлы, однако ежемесячно переплачиваете за потенциально доступные вам вычислительные ресурсы, которые вам точно не пригодятся.
3. И, наконец, не все хостеры адекватно относятся к генерации вами достаточно большого объема трафика. Поэтому, если ваши файлы будут скачивать слишком уж активно, вас могут попросту отключить, т.к. вы создаете чрезмерную нагрузку на сервер.
Учитывая все эти моменты, стоит серьезно задуматься о том, где хранить ваши файлы, особенно, если их много, и скачивают их часто.
Краткий обзор урока (все подробности смотрите в видео):
Начнем с, наверное, самого известного решения, которое, увы, уже почти ушло в прошлое.
Это сервис Яндекс.Файлы, т.е. знаменитый Народ. Я сам пользуюсь этим сервисом до сих пор, хотя сейчас он как таковой уже упразднен и Яндекс предлагает использовать вместо него свой более новый сервис Яндекс.Диск.
Те файлы, которые были закачаны еще на Народ, успешно там хранятся, однако, я подозреваю, что Яндекс все настойчивее будет переводить всех именно на Яндекс.Диск, т.к. им очень накладно хранить огромные объемы информации бесплатно.
Вместо безлимитного народа на Яндекс.Диске вам выделяется не очень-то много места под файлы (10 Гб. по умолчанию).
При этом у вас на компьютере будет папка, с которой будет совершаться синхронизация, т.е. то, что вы положите в эту папку, будет закачано на Яндекс.Диск, и наоборот - то, что вы закачаете через веб-интерфейс на Яндекс.Диск, будет сохранено на ваш компьютер.
Вы можете создавать свою структуру папок и файлов так, как вам будет удобно. Также есть возможность делать файлы личными и публичными. Личные доступны только вам, публичные же могут скачать любые люди, которые имеют ссылку на этот файл.
Несомненное достоинство сервиса - его бесплатность, поэтому для хранения относительно небольших объемов информации он подходит очень хорошо. Сейчас я использую его для хранения части архивов с видеоуроками, которые публикую на сайте.
Однако, наряду с достоинствами, у Яндекс.Файлов есть и свои недостатки. Я бы назвал два основных:
1. Нет возможности использовать этот сервис как классический хостинг.
Что я имею в виду? Вот смотрите, когда вы закачали файл (скажем, какое-то изображение) себе на хостинг, то в коде страницы вы указываете адрес до этого изображения в атрибуте src, в результате чего изображение выводится на экран в браузере.
Здесь это невозможно. Все, что вы можете - это дать другим людям возможность скачать это изображение - использовать его как иллюстрацию в статье не получится.
2. Второй недостаток - это имиджевая составляющая.
Понятно, что если вы раздаете со своего сайта какие-то файлы и уроки бесплатно, то Яндекс.Диск - прекрасное решение. Но если вы что-то продаете, например, обучающие видеокурсы и т.п. вещи, которые много весят, то было бы не очень профессионально давать человеку ссылки на скачивание, ведущие на Яндекс.Диск.
Ваш покупатель, скорее всего, ожидает получить ссылки в вашем домене, либо ссылки, которые выдают факт того, что файлы хранятся на каком-то специальном сервере. Яндекс.Диск выглядел бы здесь не очень уместно.
Какие альтернативы есть у этого сервиса?
Сразу скажу, что здесь не будет подробного обзора сервисов, я расскажу еще о двух решениях, которыми пользовался и продолжаю пользоваться сейчас.
Amazon Simple Storage Service (Amazon S3) — онлайновая веб-служба, предлагаемая Amazon Web Services, предоставляющая возможность для хранения и получения любого объёма данных, в любое время из любой точки сети, так называемый файловый хостинг.
Я пользуюсь этим сервисом уже более полутора лет, хотя в настоящее время использую его в качестве резерва на случай возникновения проблем с другим сервисом, о котором я расскажу чуть позже.
Зарегистрировавшись в этом сервисе, вы получаете возможность создавать свою структуру папок и хранить в них неограниченное количество файлов. Идея похожа на Яндекс.Диск.
Точно так же, как и там, вы можете разрешать или запрещать доступ к файлам, однако возможностей здесь больше.
Из минусов для русскоговорящего пользователя я бы отметил то, что интерфейс полностью английский, и изменить язык возможности нет.
Второй момент - это то, что для пользования им вам понадобится завести долларовую карточку, с которой Amazon будет ежемесячно списывать плату за пользование услугами Amazon S3.
И, наконец, не самые низкие цены. Поскольку сервис рассчитан, в первую очередь, на страны Запада, стоимость их услуг находится на соответствующем уровне.
Конечно, хранить там небольшие объемы информации, которые скачиваются не очень часто, вполне можно, однако не очень рекомендовал бы вам хранить там много больших файлов, которые скачиваются часто - в этом случае ежемесячный чек может быть вполне ощутимым.
Я пользуюсь им уже более полугода и очень доволен как качеством самих услуг, так и уровнем технической поддержки.
Они предлагают очень широкий спектр услуг, однако я на данный момент использую только "Облачное хранилище".
Принцип использования все тот же. Вы создаете нужные вам папки (здесь они называются контейнерами) и помещаете в них файлы, которые должны быть доступны для скачивания.
Вы можете загружать новые файлы как через веб-интерфейс, так и по протоколу FTP, используя одну из специальных программ, которые будут вам предложены.
К плюсам данного решения можно отнести следующие моменты:
1. Все на русском языке, удобно и понятно;
2. Привычные способы оплаты (от электронных денег и до банковских карт);
3. Отличная техническая поддержка (реагирует в течение 15-20 минут);
4. Приятные цены.
Т.е. если в Яндекс.Диске нет возможности добавить изображение и вывести его на экран браузера, то здесь у вас такая возможность есть.
Когда это может пригодиться?
Это может быть актуально, если вы ожидаете приток на ваш сайт большого количества людей одновременно.
В этом случае вы можете разместить все медиа-файлы (изображения, анимацию, видео и др.) на серверах Selectel, а в коде веб-страницы просто указывать пути до этих файлов.
Так вы можете разгрузить ресурсы своего хостинга и предотвратить его падение при большом наплыве посетителей.
Разумеется, этот подход отлично работает, если нет других ограничивающих факторов, скажем, ограничения по количеству одновременных подключений к базе данных. Т.е. наиболее актуален такой подход при работе с высоконагруженными страницами со статической информацией.
Ну что ж, вот в общем-то все, что я хотел вам рассказать по данному вопросу, по данным сервисам. Я надеюсь, что этот небольшой обзор был для вас полезен, если перед вами уже встал вопрос о хранении файлов сайта.
Если же пока он не актуален, это может произойти уже в самом ближайшем будущем, и на этот случай у вас уже есть полезная информация.
На этом я заканчиваю, спасибо вам за внимание!
Если краткий текстовый обзор вам не до конца понятен, то изучите полную версию урока в видеоформате на этой странице выше.
С уважением, Дмитрий Науменко.
P.S. Занимаетесь веб-разработкой? Присмотритесь к премиум-урокам по различным аспектам сайтостроения, а также к бесплатному курсу по созданию своей CMS-системы на PHP с нуля. Все это поможет вам быстрее и проще освоить веб-технологии: начиная с HTML и CSS и заканчивая JavaScript, PHP и SQL.
Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!
Читайте также: