@import w CSS i Sass – czym różni się import w obu podejściach

Różnica między @import w CSS i w Sass polega przede wszystkim na momencie działania (przeglądarka vs. etap kompilacji), liczbie zapytań HTTP oraz możliwościach modularizacji i ponownego użycia kodu. W nowoczesnych projektach @import w CSS jest raczej odradzany, a w Sass – oficjalnie oznaczony jako przestarzały na rzecz systemu modułów (@use i @forward).

Dlaczego w ogóle potrzebujemy `@import`?

Rozdzielanie CSS na mniejsze pliki (np. base.css, layout.css, components.css) ułatwia:

utrzymanie kodu,
współpracę w zespole,
ponowne użycie tych samych modułów w różnych projektach.

Trzeba jednak odpowiedzieć na kluczowe pytanie: gdzie i kiedy te pliki są łączone w całość?

W czystym CSS łączenie odbywa się w przeglądarce użytkownika przy użyciu @import w arkuszu.

W Sass/SCSS łączenie odbywa się podczas kompilacji – zanim plik trafi do przeglądarki.

To fundamentalna różnica, która wpływa na wydajność, architekturę kodu, a pośrednio także na dostępność.

`@import` w czystym CSS – jak działa naprawdę?

Składnia i podstawy

Najprostszy przykład:

@import url("reset.css"); @import url("layout.css"); @import url("components/buttons.css");

body { font-family: system-ui, sans-serif; }

Najważniejsze właściwości tej reguły warto zebrać w krótkich punktach:

pozycja w arkuszu – reguła musi znajdować się na początku pliku, przed właściwymi regułami,
zakres źródeł – można importować z tego samego serwera (ścieżki względne) lub z dowolnego adresu w internecie (zewnętrzny URL),
priorytet kaskady – działa podobnie do <link rel="stylesheet">; importowany arkusz ma taki sam priorytet jak arkusz, do którego został dołączony,
media queries – można je dodać bezpośrednio w @import.

Przykład użycia z media queries:

@import url("print.css") print; @import url("large.css") screen and (min-width: 1280px);

Wydajność: `@import` dzieje się w przeglądarce

W CSS import następuje w czasie działania strony (runtime), a przeglądarka wykonuje osobne zapytanie HTTP dla każdego importowanego pliku.

Jeżeli mamy:

@import url("base.css"); @import url("layout.css"); @import url("components.css");

to przeglądarka wykona trzy dodatkowe zapytania HTTP, oprócz głównego arkusza.

W praktyce oznacza to:

dłuższy czas ładowania CSS,
potencjalne opóźnienie renderowania (tzw. render‑blocking CSS),
większe ryzyko chwilowej „gołej” strony bez stylów.

Z punktu widzenia dostępności użytkownicy ze słabszym łączem lub na urządzeniach mobilnych mogą dłużej czekać na poprawnie ostylowaną stronę, a osoby wrażliwe na nagłe zmiany interfejsu mogą doświadczać problemów z orientacją.

Te konsekwencje wynikają bezpośrednio z faktu, że @import w CSS działa po stronie przeglądarki i generuje dodatkowe HTTP requesty.

Dlaczego dziś `@import` w CSS jest odradzany?

@import w CSS to rozwiązanie o słabej wydajności; zamiast niego lepiej wstawić kilka <link rel="stylesheet"> w HTML i świadomie je optymalizować lub skompilować jeden zminifikowany plik CSS przy użyciu narzędzi (bundlerów, preprocesorów, PostCSS itd.).

Najkrócej:

Plusy – prostota, znajomość, możliwość importu zewnętrznych arkuszy z internetu, wykorzystanie media queries w @import.

Minusy – dodatkowe zapytania HTTP, opóźnienie ładowania, konieczność umieszczania @import na początku arkusza, gorsza kontrola nad wydajnością.

`@import` w Sass/SCSS – co robi inaczej?

Sass (w wersji składni SCSS) jest preprocesorem CSS – najpierw piszesz pliki .scss, a następnie są one kompilowane do jednego lub kilku plików .css.

Kompilacja zamiast importu w przeglądarce

W Sass @import działa inaczej: importy są łączone podczas kompilacji projektu, a kompilator scala je do jednego arkusza CSS, dzięki czemu przeglądarka zwykle pobiera tylko jeden plik.

Przykład:

// main.scss @import "base"; @import "layout"; @import "components/buttons";

body { font-family: system-ui, sans-serif; }

Po kompilacji do main.css przeglądarka wykonuje jedno zapytanie HTTP (zakładając, że w HTML podłączasz tylko main.css), a zawartość wszystkich modułów trafia do jednego pliku.

Sass-owy @import daje modularizację bez kosztów wydajności po stronie użytkownika.

Składnia i import wielu plików

W Sass możemy importować wiele plików naraz:

@import "base", "layout", "components/buttons";

Co warto wiedzieć o sposobie działania tego mechanizmu:

rozszerzenia – pliki mogą mieć rozszerzenia .scss lub .sass, których nie trzeba podawać,
miejsce scalania – dyrektywa @import dołącza treść importowanego pliku dokładnie w miejscu, w którym się pojawia,
udostępniane konstrukcje – z importowanych plików możesz korzystać zdefiniowanych tam zmiennych, mixinów i funkcji.

Przykład:

// _variables.scss $primary-color: #0b5ed7; $spacing: 1rem;


// _button.scss

@import "variables";

.button { padding: $spacing; background: $primary-color; }

Po kompilacji zmienne i mixiny są „spłaszczone” do zwykłych deklaracji CSS, a przeglądarka widzi już tylko wynik.

Partials – pliki cząstkowe Sass

Sass ma koncepcję plików cząstkowych (partials), czyli modułów, które same nie są kompilowane do CSS, ale mogą być importowane do głównego pliku.

plik cząstkowy ma nazwę z podkreśleniem, np. _buttons.scss, _variables.scss,
tylko plik główny (np. main.scss bez podkreślenia) jest kompilowany do CSS,
w pliku głównym używasz @import do łączenia wszystkich części.

// main.scss @import "variables"; @import "typography"; @import "components/buttons"; @import "components/forms";

Taka organizacja projektu jest:

modularna,
łatwiejsza w utrzymaniu,
gotowa do kompilacji do jednego zoptymalizowanego pliku CSS.

Kiedy Sass zostawia `@import` jako zwykłe CSS?

Sass w pewnych sytuacjach nie scala plików, tylko pozostawia @import w wynikowym CSS (zachowuje się wtedy jak CSS-owy import). Dzieje się tak, gdy spełniony jest któryś z warunków:

importowany plik ma rozszerzenie .css,
ścieżka zaczyna się od http:// lub https://,
ścieżka jest ujęta w url(),
w @import występują media queries.

Przykłady:

// 1. Zostanie przepisane do CSS jako @import url(...) @import "https://example.com/styles.css";


// 2. Również zwykły CSS

@import url("print.css") print;

// 3. Ten import zostanie wczytany i scalony (brak .css, brak http/url/media) @import "variables";

To zachowanie jest przydatne, gdy chcesz wstrzyknąć zewnętrzny CSS (np. z CDN), a jednocześnie korzystasz z Sass do modularizacji własnego kodu.

CSS `@import` vs. Sass `@import` – porównanie

Poniżej zestawienie kluczowych różnic:

Aspekt	`@import` w CSS	`@import` w Sass/SCSS
Miejsce działania	w przeglądarce (w czasie działania).	podczas kompilacji (czas budowania).
Liczba zapytań HTTP	osobne zapytanie dla każdego importu.	zwykle jeden wygenerowany CSS (brak dodatkowych zapytań).
Wymagane położenie w arkuszu	na początku arkusza, przed regułami.	dowolne miejsce (nie musi być na początku).
Importowanie Sass/SCSS	brak – tylko CSS.	możliwość importu plików `.scss`/`.sass` z mixinami, zmiennymi itd.
Partials (pliki cząstkowe)	brak pojęcia partiali.	wspierane (`_file.scss`).
Dostęp do zmiennych i mixinów	brak (czysty CSS).	pełny dostęp do zmiennych, funkcji i mixinów z importowanych plików.
Wydajność	gorsza: wiele HTTP requestów, możliwe opóźnienia.	lepsza: scalanie do jednego pliku, mniej requestów.
Wpływ na dostępność (pośredni)	możliwe opóźnione ładowanie stylów.	stabilniejsze ładowanie kompletnego CSS.
Status w ekosystemie	wciąż część specyfikacji, ale odradzana w nowoczesnych projektach.	przestarzałe w Sass na rzecz `@use`/`@forward`.

Sass: `@import` zostało oznaczone jako przestarzałe

W dokumentacji Sass znajduje się wyraźna informacja, że @import jest przestarzałe (deprecated), a zespół Sass zaleca korzystanie z systemu modułów: @use i @forward.

Powody, dla których @import w Sass uznano za problematyczne, to m.in.:

tworzenie globalnej przestrzeni nazw (wszystkie zmienne i mixiny stają się globalne),
możliwość wielokrotnego wczytania tych samych plików,
trudność w śledzeniu, skąd pochodzą konkretne zmienne i mixiny,
utrudniona refaktoryzacja dużych projektów.

Nowa dyrektywa @use jest podobna do @import, ale z istotnymi różnicami:

dany plik jest importowany tylko raz, niezależnie od liczby @use w projekcie,
członkowie (zmienne, mixiny, funkcje) są domyślnie nazwani przestrzennie (np. buttons.$primary-color), co zapobiega konfliktom nazw,
członkowie zaczynający się od _ lub - są traktowani jako prywatne – nie są udostępniane na zewnątrz.

Przykład (zamiast @import):

// _colors.scss $primary: #0b5ed7; $danger: #dc3545;


// _buttons.scss

@use "colors";
.button-primary { background: colors.$primary; }

.button-danger { background: colors.$danger; }

// main.scss @use "buttons";

Zamiast „wylewania” wszystkiego do globalnego zakresu, @use wymusza jawne przestrzenie nazw, co w dużych projektach znacznie poprawia czytelność i bezpieczeństwo refaktoryzacji. Ostrzeżenia kompilatora typu „@import is deprecated” pojawiają się coraz częściej – nowoczesne projekty Sass powinny więc przechodzić na @use/@forward.

Wpływ wyboru mechanizmu importu na wydajność i dostępność

Wydajność ładowania

Najważniejsze wnioski dla praktycznej optymalizacji:

dodatkowe importy w CSS oznaczają dodatkowe zapytania HTTP i dłuższy czas blokowania renderu,
kompilacja w Sass pozwala serwować zwykle jeden zminifikowany plik CSS,
mniejsza liczba requestów przyspiesza wczytywanie i obniża czas do FCP/FMP.

W praktyce oznacza to szybszy czas do „pierwszego sensownego renderu” (FMP/FCP), co jest ważne zarówno dla UX, jak i dla SEO.

Dostępność

Wybór mechanizmu importu wpływa pośrednio na komfort korzystania z interfejsu:

stabilniejsze ładowanie stylów zmniejsza „przeskakiwanie” layoutu i dezorientację,
mniej nagłych zmian wizualnych sprzyja osobom z trudnościami poznawczymi,
przewidywalność stylów ułatwia korzystanie osobom używającym powiększeń, czytników ekranu i trybów wysokiego kontrastu.

Praktyczne przykłady i rekomendacje

Jak nie organizować stylów w nowych projektach

Przykład raczej do unikania:

 <head> <link rel="stylesheet" href="css/main.css"> </head>
/* css/main.css */ @import url("reset.css"); @import url("layout.css"); @import url("components.css");

/* ...dalej reguły... */

Dlaczego to problematyczne?

każdy @import generuje dodatkowe zapytanie HTTP,
musisz pilnować, by @import był na początku pliku,
w praktyce trudniej to optymalizować (cache, preloading itd.).

Lepsze podejścia to osobne <link> w HTML, gdy stylów jest niewiele, albo one‑file bundling (Sass/PostCSS/Webpack/Vite) w większych projektach.

Organizacja Sass z (jeszcze) użyciem `@import`

W istniejących projektach możesz spotkać taki układ:

// main.scss @import "base/reset"; @import "base/typography"; @import "layout/grid"; @import "components/buttons"; @import "components/forms"; @import "utilities/helpers";

Każdy z plików zwykle ma nazwę z podkreśleniem (np. _buttons.scss) i odpowiada za konkretny aspekt projektu (komponent, layout, utilities). To wciąż poprawny wzorzec modularizacji, ale warto planować migrację na @use/@forward.

Organizacja Sass z użyciem modułów (`@use`, `@forward`)

Docelowo, zgodnie z zaleceniami Sass, struktura może wyglądać tak:

// _colors.scss $primary: #0b5ed7; $secondary: #6c757d;


// _typography.scss

$font-base: system-ui, sans-serif;
body {

  font-family: $font-base;

}
// _buttons.scss

@use "colors";
.button { background: colors.$primary; }
// _index.scss – moduł wygodny do importu

@forward "colors";

@forward "typography";

@forward "buttons";

// main.scss @use "index";

Zalety takiego podejścia:

wyraźne przestrzenie nazw (brak „globalnego bałaganu”),
kontrola nad tym, co jest eksportowane (@forward) i co jest prywatne,
każdy moduł ładowany tylko raz,
lepsza skalowalność w dużych projektach.

Co wybrać w nowych projektach?

W czystym CSS

Jeśli nie używasz preprocesorów, postępuj tak:

unikaj @import w CSS jako głównego mechanizmu łączenia plików,
używaj <link rel="stylesheet"> w HTML,
rozważ narzędzia budujące (bundlery), które scalają i minifikują CSS.

@import w CSS może się przydać sporadycznie (np. dołączanie zewnętrznego arkusza z internetu), ale nie powinien być „kręgosłupem” architektury.

W Sass/SCSS

Jeśli korzystasz z Sass, rekomendacje są jasne:

nie zaczynaj nowych projektów od @import – mechanizm jest przestarzały,
stosuj @use do pobierania modułów,
korzystaj z @forward do re-eksportu modułów z plików indeksujących,
w kodzie legacy planuj stopniową migrację z @import na @use/@forward.

Podsumowanie różnic w jednym zdaniu

CSS @import importuje arkusze w przeglądarce, generuje dodatkowe zapytania HTTP i jest dziś raczej odradzany; Sass @import scala pliki w czasie kompilacji i daje dostęp do zmiennych oraz mixinów, ale sam mechanizm jest już przestarzały na rzecz modułów @use/@forward.