Pojedynczy ogromny plik .css vs. wiele mniejszych określonych plików .css? [Zamknięte]

Czy istnieje korzyść z posiadania pojedynczego pliku .css potwora zawierającego elementy stylu, które będą używane na prawie każdej stronie?

Myślę, że ze względu na łatwość zarządzania chciałbym wyciągnąć różne typy CSS do kilku plików i dołączyć każdy plik do mojego głównego, <link />czy to źle?

Myślę, że tak jest lepiej

1. position.css
2. buttons.css
3. tables.css
4. copy.css

vs.

1. site.css

Czy widziałeś jakieś problemy z robieniem tego w jedną stronę w drugą stronę?

Kompilator CSS, taki jak Sass lub LESS, to świetna droga. W ten sposób będziesz w stanie dostarczyć pojedynczy, zminimalizowany plik CSS dla witryny (który będzie znacznie mniejszy i szybszy niż zwykły pojedynczy plik źródłowy CSS), przy jednoczesnym zachowaniu najładniejszego środowiska programistycznego, ze wszystkim starannie podzielonym na komponenty.

Sass i LESS mają dodatkową zaletę zmiennych, zagnieżdżania i innych sposobów ułatwiających pisanie i obsługę CSS. Gorąco polecam. Teraz osobiście używam Sass (składnia SCSS), ale wcześniej użyłem LESS. Oba są świetne, z podobnymi korzyściami. Po napisaniu CSS za pomocą kompilatora, jest mało prawdopodobne, że nie chciałbyś się bez niego obejść.

http://lesscss.org

http://sass-lang.com

Jeśli nie chcesz się bawić w Ruby, ten kompilator LESS dla komputerów Mac jest świetny:

http://incident57.com/less/

Lub możesz użyć CodeKit (przez tych samych facetów):

http://incident57.com/codekit/

WinLess to graficzny interfejs użytkownika systemu Windows do kompilacji MNIEJ

http://winless.org/

Trudno na nie odpowiedzieć. Obie opcje mają swoje zalety i wady.

Osobiście nie lubię czytać jednego OGROMNEGO pliku CSS, a jego utrzymanie jest bardzo trudne. Z drugiej strony podzielenie go powoduje dodatkowe żądania HTTP, które mogą potencjalnie spowolnić działanie.

Moja opinia byłaby jedną z dwóch rzeczy.

1) Jeśli wiesz, że Twój CSS NIGDY nie zmieni się po jego utworzeniu, zbudowałbym wiele plików CSS na etapie programowania (dla czytelności), a następnie ręcznie je połączę przed uruchomieniem (w celu zmniejszenia żądań HTTP)

2) Jeśli wiesz, że od czasu do czasu zmienisz swój CSS i musisz zachować jego czytelność, zbudowałbym osobne pliki i używałbym kodu (pod warunkiem, że używasz jakiegoś języka programowania), aby je połączyć czas kompilacji środowiska wykonawczego (minimalizacja / kombinacja środowiska wykonawczego jest świnią zasobów).

W przypadku obu opcji zdecydowanie zalecam buforowanie po stronie klienta, aby jeszcze bardziej ograniczyć żądania HTTP.

EDYCJA:
Znalazłem tego bloga, który pokazuje, jak łączyć CSS w czasie wykonywania, używając tylko kodu. Warto rzucić okiem (choć sam tego jeszcze nie testowałem).

EDYCJA 2:
W czasie projektowania postanowiłem używać osobnych plików oraz procesu kompilacji w celu zminimalizowania i połączenia. W ten sposób mogę mieć oddzielny (zarządzalny) css podczas tworzenia i odpowiedni monolityczny zminimalizowany plik w czasie wykonywania. Nadal mam pliki statyczne i mniejszy narzut systemowy, ponieważ nie wykonuję kompresji / minimalizacji w czasie wykonywania.

Uwaga: jeśli chodzi o kupujących, zdecydowanie polecam użycie narzędzia bundler jako części procesu kompilacji. Niezależnie od tego, czy budujesz z poziomu IDE, czy ze skryptu kompilacji, program pakujący może być uruchamiany w systemie Windows za pomocą dołączonego exelub może być uruchamiany na dowolnym komputerze, na którym jest już uruchomiony plik node.js.

Wolę wiele plików CSS podczas programowania. W ten sposób zarządzanie i debugowanie jest znacznie łatwiejsze. Sugeruję jednak, aby przy okazji wdrożenia użyć narzędzia minimalizacji CSS, takiego jak YUI Compressor, które scali twoje pliki CSS w jeden plik monolityczny.

Chcesz oba światy.

Chcesz wielu plików CSS, ponieważ twoje zdrowie psychiczne jest straszną rzeczą do stracenia.

Jednocześnie lepiej mieć pojedynczy, duży plik.

Rozwiązaniem jest posiadanie mechanizmu, który łączy wiele plików w jeden plik.

Jednym z przykładów jest coś takiego

<link rel="stylesheet" type="text/css" href="allcss.php?files=positions.css,buttons.css,copy.css" />

Następnie skrypt allcss.php obsługuje łączenie plików i ich dostarczanie.

Idealnie byłoby, gdyby skrypt sprawdzał daty modyfikacji we wszystkich plikach, tworzy nowy kompozyt, jeśli którykolwiek z nich się zmieni, następnie zwraca ten kompozyt, a następnie sprawdza nagłówki HTTP If-Modified, aby nie wysyłać zbędnego CSS.

To daje najlepsze z obu światów. Działa świetnie również dla JS.

Posiadanie tylko jednego pliku CSS jest lepsze dla czasu ładowania stron, ponieważ oznacza to mniej żądań HTTP.

Posiadanie kilku małych plików CSS oznacza, że ​​tworzenie jest łatwiejsze (przynajmniej tak myślę: posiadanie jednego pliku CSS na moduł Twojej aplikacji ułatwia rzeczy) .

Istnieją więc powody w obu przypadkach ...

Rozwiązaniem, które pozwoliłoby uzyskać najlepsze z obu pomysłów, byłoby:

• Aby rozwinąć za pomocą kilku małych plików CSS
  • tj. łatwiejsze do opracowania
• Aby mieć proces kompilacji aplikacji, który „łączy” te pliki w jeden
  • Ten proces kompilacji może również zminimalizować ten duży plik, btw
  • To oczywiście oznacza, że ​​twoja aplikacja musi mieć pewne elementy konfiguracyjne, które pozwalają na przejście z „trybu wielu plików” do „trybu mono-plików”.
• I do wykorzystania w produkcji tylko duży plik
  • tzn. szybsze ładowanie stron

Istnieje również oprogramowanie łączące pliki CSS w czasie wykonywania, a nie w czasie kompilacji; ale robienie tego w czasie wykonywania oznacza zjedzenie nieco więcej procesora (i oczywiście wymaga trochę mechaniki buforowania, aby zbyt często nie generować dużego pliku)

Historycznie jedną z głównych zalet x posiadania pojedynczego pliku CSS jest większa szybkość przy korzystaniu z HTTP1.1.

Jednak od marca 2018 r. Ponad 80% przeglądarek obsługuje teraz HTTP2, co pozwala przeglądarce na jednoczesne pobieranie wielu zasobów, a także na wyprzedzanie. Posiadanie jednego pliku CSS dla wszystkich stron oznacza większy niż konieczny rozmiar pliku. Przy odpowiednim projekcie nie widzę żadnej przewagi w robieniu tego poza łatwiejszym kodowaniem.

Idealnym projektem dla HTTP2 dla najlepszej wydajności byłoby:

• Posiadaj podstawowy plik CSS, który zawiera wspólne style używane na wszystkich stronach.
• Umieść CSS specyficzny dla strony w osobnym pliku
• Użyj CSS push HTTP2, aby zminimalizować czas oczekiwania (plik cookie może być użyty, aby zapobiec powtarzaniu wypychania)
• Opcjonalnie oddziel nad foldem CSS i popchnij to najpierw, a później załaduj pozostały CSS (przydatne w przypadku urządzeń mobilnych o niskiej przepustowości)
• Możesz również załadować pozostały CSS witryny lub określonych stron po załadowaniu strony, jeśli chcesz przyspieszyć ładowanie stron w przyszłości.

Monolityczne arkusze stylów oferują wiele korzyści (które są opisane w innych odpowiedziach), jednak w zależności od ogólnej wielkości dokumentu arkusza stylów możesz napotkać problemy w IE. IE ma ograniczenia dotyczące liczby selektorów, które odczyta z jednego pliku . Limit wynosi 4096 selektorów. Jeśli jesteś monolityczny arkusz stylów będzie miał więcej niż to, będziesz chciał go podzielić. To ograniczenie tylko pokazuje jego brzydką głowę w IE.

Dotyczy to wszystkich wersji IE.

Zobacz blog Ross Bruniges i stronę MSDN AddRule .

Jest punkt zwrotny, w którym korzystne jest posiadanie więcej niż jednego pliku css.

Witryna z ponad 1 milionem stron, o których przeciętny użytkownik może zobaczyć tylko powiedzmy 5, może mieć arkusz stylów o ogromnych proporcjach, więc próba zaoszczędzenia na nakładzie pojedynczego dodatkowego żądania na ładowanie strony przez masowe początkowe pobranie jest fałszywa gospodarka.

Rozciągnij argument do skrajnego limitu - to tak, jakby sugerować, że powinien istnieć jeden duży arkusz stylów dla całej sieci. Wyraźnie bezsensowne.

Punkt zwrotny będzie jednak różny dla każdej strony, więc nie ma twardej i szybkiej reguły. Będzie to zależeć od liczby unikalnych css na stronę, liczby stron i liczby stron, które przeciętny użytkownik może rutynowo napotykać podczas korzystania z witryny.

Zwykle mam garść plików CSS:

• „globalny” plik css do resetowania i stylów globalnych
• „modułowe” określone pliki css dla stron, które są logicznie pogrupowane (może każda strona w kreatorze płatności lub coś takiego)
• „css” określone pliki css dla przesłonięć na stronie (lub, umieść to w bloku na indywidualnej stronie)

Nie jestem zbytnio zainteresowany wieloma żądaniami stron dla plików CSS. Większość ludzi ma przyzwoitą przepustowość i jestem pewien, że istnieją inne optymalizacje, które miałyby znacznie większy wpływ niż łączenie wszystkich stylów w jeden monolityczny plik CSS. Kompromis polega na szybkości i łatwości konserwacji, a ja zawsze skłaniam się w stronę łatwości konserwacji. Kompresory YUI brzmią całkiem fajnie, być może będę musiał to sprawdzić.

Wolę wiele plików CSS. W ten sposób łatwiej jest zamieniać „skórki”, jak chcesz. Problem z jednym plikiem monolitycznym polega na tym, że może on wymknąć się spod kontroli i jest trudny do zarządzania. Co jeśli chcesz niebieskie tło, ale nie chcesz zmieniać przycisków? Po prostu zmień plik tła. Itp.

Może rzucisz okiem na kompas , który jest strukturą tworzenia kodu CSS typu open source. Opiera się na Sass, więc obsługuje fajne rzeczy, takie jak zmienne, zagnieżdżanie, mixiny i import. Szczególnie importowanie jest przydatne, jeśli chcesz zachować osobne mniejsze pliki CSS, ale automatycznie połączyć je w 1 (unikając wielu powolnych połączeń HTTP). Compass dodaje do tego duży zestaw wstępnie zdefiniowanych miksów, które są łatwe w obsłudze w różnych przeglądarkach. Jest napisany w Rubim, ale można go łatwo używać z dowolnym systemem ....

oto najlepszy sposób:

1. utwórz ogólny plik css z całym udostępnionym kodem
2. wstaw cały określony kod css strony do tej samej strony, w tagu lub używając atrybutu style = "" dla każdej strony

w ten sposób masz tylko jeden css z całym udostępnionym kodem i stroną HTML. przy okazji (i wiem, że to nie jest właściwy temat) możesz również kodować swoje obrazy w base64 (ale możesz to również zrobić z plikami js i css). w ten sposób redukujesz jeszcze więcej żądań HTTP do 1.

SASS i LESS sprawiają, że to wszystko jest naprawdę sporne. Deweloper może skonfigurować skuteczne pliki składników i podczas kompilacji połączyć je wszystkie. W SASS możesz wyłączyć tryb skompresowany podczas programowania, aby ułatwić czytanie, i włączyć go ponownie w celu produkcji.

http://sass-lang.com http://lesscss.org

Ostatecznie potrzebny jest pojedynczy zminimalizowany plik CSS, niezależnie od stosowanej techniki. Mniej CSS, mniej żądań HTTP, mniejsze zapotrzebowanie na serwerze.

Zaletą pojedynczego pliku CSS jest wydajność przesyłania. Każde żądanie HTTP oznacza odpowiedź nagłówka HTTP dla każdego żądanego pliku, co wymaga przepustowości.

Służę CSS jako plik PHP z typem mime „text / css” w nagłówku HTTP. W ten sposób mogę mieć wiele plików CSS po stronie serwera i użyć PHP obejmuje wypchnięcie ich do jednego pliku na żądanie użytkownika. Każda nowoczesna przeglądarka odbiera plik .php z kodem CSS i przetwarza go jako plik .css.

Możesz po prostu użyć jednego pliku css do wydajności, a następnie skomentować następujące sekcje:

/******** Header ************/
//some css here

/******* End Header *********/


/******** Footer ************/
//some css here

/******* End Footer *********/

itp

Używam Jammit do zarządzania moimi plikami css i używam wielu różnych plików dla zapewnienia czytelności. Jammit wykonuje całą brudną pracę związaną z łączeniem i kompresowaniem plików przed wdrożeniem w środowisku produkcyjnym. W ten sposób mam wiele plików w fazie rozwoju, ale tylko jeden plik w produkcji.

Dołączony arkusz stylów może obniżyć wydajność ładowania strony, ale im więcej stylów, tym wolniej przeglądarka wyświetla animacje na stronie, na której jesteś. Jest to spowodowane ogromną ilością nieużywanych stylów, które mogą nie znajdować się na stronie, na której jesteś, ale przeglądarka nadal musi to obliczyć.

Zobacz: https://benfrain.com/css-performance-revisited-selectors-bloat-expensive-styles/

Zalety dołączonych arkuszy stylów: - wydajność ładowania strony

Wady dołączonych arkuszy stylów: - wolniejsze zachowanie, które może powodować niepewność podczas przewijania, interaktywność, animację,

Wniosek: Aby rozwiązać oba problemy, w przypadku produkcji idealnym rozwiązaniem jest spakowanie całego css w jeden plik, aby zapisać na żądania HTTP, ale użyj javascript do wyodrębnienia z tego pliku, css dla strony, na której jesteś, i zaktualizuj za jej pomocą nagłówek .

Aby dowiedzieć się, które współdzielone komponenty są potrzebne na stronę i aby zmniejszyć złożoność, dobrze byłoby zadeklarować wszystkie składniki, których używa ta strona - na przykład:

<style href="global.css" rel="stylesheet"/>
<body data-shared-css-components="x,y,z">

Stworzyłem systematyczne podejście do rozwoju CSS. W ten sposób mogę wykorzystać standard, który nigdy się nie zmienia. Najpierw zacząłem od systemu siatki 960. Następnie stworzyłem pojedyncze linie css dla podstawowych układów, marginesów, wypełnienia, czcionek i rozmiarów. Następnie łączę je w razie potrzeby. To pozwala mi zachować spójny układ we wszystkich moich projektach i wielokrotnie korzystać z tych samych plików css. Ponieważ nie są one specyficzne. Oto przykład: ---- div class = "c12 bg0 m10 p5 biały fl" / div --- Oznacza to, że pojemnik ma 12 kolumn, wykorzystuje bg0 ma marginesy 10 piks. Dopełnienie 5, tekst jest biały i unosi się lewo. Mógłbym łatwo to zmienić, usuwając lub dodając nowy - To, co nazywam „lekkim” stylem - Zamiast tworzyć jedną klasę z tymi wszystkimi atrybutami; Po prostu łączę pojedyncze style, kodując stronę. To pozwala mi tworzyć dowolną kombinację stylów i nie ogranicza mojej kreatywności ani nie powoduje tworzenia ogromnej liczby podobnych stylów. Twoje arkusze stylów stają się o wiele łatwiejsze w zarządzaniu, zminimalizowane i pozwalają na wielokrotne ich używanie. Ta metoda okazała się fantastyczna do szybkiego projektowania. Nie projektuję też już najpierw w PSD, ale w przeglądarce, co również oszczędza czas. Ponadto, ponieważ stworzyłem również system nazewnictwa dla moich środowisk i atrybutów projektu strony, po prostu zmieniam plik obrazu podczas tworzenia nowego projektu. (Bg0 = tło ciała zgodnie z moim systemem nazewnictwa) Oznacza to, że gdybym wcześniej miał biały tło z jednym projektem po prostu zmieniając go na czarny oznacza po prostu, że w następnym projekcie bg0 będzie czarnym tłem lub innym obrazem .....