Czy powinienem podzielić duży plik zapytań o media CSS na osobne pliki dla każdego rozmiaru ekranu?


19

Pracuję nad responsywną witryną projektową, aby dostarczać treści dla wszystkich rozmiarów ekranu. Mam zapytania o media dla 5 różnych „kroków”, a plik CSS ma około 30 Kb.

Czy lepiej byłoby podzielić to na osobne pliki i uczynić je podobnymi do tego:

<link rel='stylesheet' media='screen and (min-width: 701px) and (max-width: 900px)' href='css/medium.css' />

czy powinienem przechowywać je w jednym pliku CSS?

Aktualizacja: Chciałem tylko dodać, że moim głównym zmartwieniem była szybkość otwierania / renderowania stron w różnych przeglądarkach / urządzeniach, a nie łatwość programowania.


Czy grunt / webpack / jakiekolwiek wtyczki istnieją, aby pobrać pojedynczy plik css i podzielić go na wiele plików oddzielonych zapytaniem o media? Wtedy zapewne można uzyskać łatwość programowania, jaką zapewnia jeden plik monolitu, a także optymalizację szybkości oddzielnych plików.
Kevin Wheeler,

Odpowiedzi:


16

Myślę, że to naprawdę zależy od tego, co uważasz za najłatwiejsze w rozwoju i co pomaga utrzymać porządek w arkuszu stylów.

Jedynym prawdziwym minusem, który mogę wymyślić podczas dzielenia, jest to, że jeśli atrybut elementu pojawi się we wszystkich arkuszach stylów, musisz zaktualizować 5 oddzielnych plików, aby go zmienić (zamiast pojawiać się obok siebie w jednym miejscu).

Zgodnie z odpowiedzią na ten post, przeglądarki niezależnie od tego pobiorą wszystkie arkusze stylów, więc dzielenie rozdzielczości nie oznacza oszczędności pasma: /programming/16657159/when-using-media-queries-does-a -phone-load-non-relevent-queries-and-images


Czy w tym wpisie, który umieściłeś w linku, wiesz, co rozumie przez „to ograniczenie CSSOM”?
DisgruntledGoat

1
Model obiektowy CSS - dev.w3.org/csswg/cssom - Wierzę, że to określa sposób obsługi CSS, i myślę, że ograniczenie, do którego się odwołuje, nie będzie mieć modelu, który obsługuje takie style w sposób bardziej oszczędzający przepustowość sposób.
Richard B,

3
Chociaż nie jest to oszczędzanie pobierania, jest w pewnym sensie. Przeglądarka nada priorytet pasującym linkom do zapytań o media, a nie niepasującym. Dopasowany plik css zablokuje renderowanie strony, podczas gdy niepasujące przeglądarka ma niższy priorytet do pobrania i wcale nie blokuje renderowania strony. Również po podzieleniu możesz użyć js do warunkowego pobrania, jeśli chcesz zapisać i połączyć.
dalore

4

Zależy to nieco od tego, co chcesz osiągnąć: czy starasz się przyspieszyć ładowanie strony, czy też ułatwiasz rozwój?

Jeśli celujesz w to drugie, możesz użyć wielu arkuszy, ale to wszystko jest kwestią preferencji. Najłatwiej jest mi użyć jednego dużego pliku, ponieważ daje to przegląd wszystkich zadeklarowanych stylów.

Jeśli chcesz szybciej ładować stronę, najlepszym rozwiązaniem byłoby zminimalizowanie liczby żądań, ponieważ narzut jest dość duży. Ponadto możesz zachować wersję programistyczną dla siebie i podawać zminimalizowane css w sieci (uważam YUI za dobrą metodę: http://www.refresh-sf.com/yui/ ).

Ponadto postaram się zoptymalizować sam css. Możesz spróbować połączyć klasy, które są bardzo podobne, na przykład:

.bold-and-italic { font-weight: bold; text-style: italic; }

Można przekształcić w:

.bold { font-weight: bold; }
.italic { text-style: italic; }

Trzeba tylko nieznacznie zmienić HTML z <span class="bold-and-italic">foo bar</span>na<span class="bold italic">foo bar</span>

Mogę zdecydowanie zasugerować, aby spojrzeć na Bootstrap ( http://getbootstrap.com ), ci faceci wykonali świetną robotę, dzieląc klasy na wiele „podklas”.

Mam nadzieję, że to pomoże.


1
Klasy nazwane po stylu mają złą formę. Równie dobrze możesz po prostu dodać atrybut stylu, jeśli idziesz do tego. Lepiej nazwać klasy logiczne. Like.important
dalore

4

Prawdopodobnie najlepiej jest mieć tylko jeden plik CSS, ale aby go zminimalizować i zgzipować. Zakładając, że twoje 30KB są przed tym, prawdopodobnie zmniejszysz rozmiar pliku do około 5 KB z minimalizacją (usuwanie białych znaków) i gzippingiem.

Rozdzielenie prawdopodobnie przyspieszy, ale tylko pod pewnymi warunkami.

  • Musisz upewnić się, że za każdym razem ładowany jest tylko jeden arkusz stylów - w przeciwnym razie potrzebujesz dwóch lub więcej żądań HTTP, które same mają narzut, co przynajmniej częściowo zniweczy zysk z mniejszego rozmiaru pliku. Aby to zrobić, nie wystarczy po prostu podzielić arkusz stylów i wstawić wiele <link>tagów z różnymi atrybutami multimediów, przeglądarki wydają się ładować wszystkie <link>edytowane arkusze stylów niezależnie od zapytań o media (dzięki @cimmanon za te informacje, nie wiedziałem o tym) .
  • Liczba reguł CSS współużytkowanych przez arkusze stylów musi być mała - w przeciwnym razie każdy z wielu arkuszy stylów musiałby zawierać wszystkie wspólne reguły, a zatem miałby prawie rozmiar oryginału.
  • Używasz preprocesora CSS (lub czegoś podobnego), więc można zarządzać takimi samymi fragmentami kodu w 5 arkuszach stylów.

Ponadto: nie optymalizuj przedwcześnie. Rób to tylko, jeśli masz problemy z wydajnością.


3
Warto zauważyć, że jeśli używasz <link rel="stylesheet" />znacznika do wszystkich plików specyficznych dla zapytania o media, nie będziesz w stanie zapobiec ich pobieraniu przez przeglądarkę. Będziesz musiał użyć wąchania przeglądarki po stronie serwera lub JavaScript, aby sprawdzić wymiary rzutni i wstrzyknąć odpowiednie arkusze stylów. Żaden z nich nie jest dobrym wyborem.
cimmanon

1
Jestem trochę zaskoczony, ale masz rację - pomyślałem, że dodanie atrybutu media do <link>tagu zapobiegnie ładowaniu niepasujących arkuszy stylów. Dlaczego przeglądarki to robią? Jest to oczywiście najważniejszy powód, aby nie dzielić arkuszy stylów.
Jost

Robią to, ponieważ ekran może się zmieniać, a jeśli jesteś na telefonie komórkowym i obracasz go z pionowego na poziomy, nagle szerokość ekranu jest inna. Lub na pulpicie możesz zmienić rozmiar okna przeglądarki lub przeciągnąć okno na inny ekran, jeśli masz konfigurację z wieloma monitorami. Gdyby przeglądarka nie pobrała wszystkich zasobów CSS z wyprzedzeniem, opóźnienie w ponownym renderowaniu strony byłoby opóźnione, gdyby wystąpiło którekolwiek z powyższych działań
MrCarrot

Lepiej je rozdzielić. Większość przeglądarek w dzisiejszych czasach to przeglądarki spdy (twoja strona to https i spdy dokładnie tak, jak powinno być), a przy spdy wiele połączeń jest multipleksowanych do tego samego połączenia, więc liczba plików nie ma teraz znaczenia. Przeglądarki również umieszczają niepoprawne pliki css z zapytaniami o media o niższym priorytecie do pobrania, a co ważniejsze nie blokują renderowania strony.
dalore

3

Powinieneś podzielić swoje pliki CSS na podstawie zapytań o media, ponieważ pliki CSS blokują wyświetlanie.

Gdy przeglądarka konstruuje DOM, musi najpierw poczekać i załadować wszystkie pliki CSS. Skrócisz czas ładowania strony, jeśli niektóre pliki CSS są ładowane tylko na podstawie określonych zapytań o media.

Dotyczy to również dodawania asynchronizacji do znacznika skryptu JavaScript; np <script src='myfile.js' async></script>.:

DOM nie musi czekać na załadowanie pliku JS. Dodaj asynchronizację tylko wtedy, gdy konstrukcja twojego DOM nie potrzebuje żadnego z tych skryptów JavaScript przy obciążeniu.


Słyszałem, że twierdzono, że jeśli naprawdę nie chcesz, aby skrypty asynchroniczne potencjalnie opóźniały renderowanie, uruchom je w zdarzeniu window.onload zamiast używać asynchronizacji.
Kevin Wheeler,

2

Byłbym skłonny to powiedzieć.

Do produkcji zawsze przechowuj je w jednym pliku; powodem jest to, że jest bardziej wydajna dla przeglądarki, i to powinno być twoim głównym zainteresowaniem (IMO) podczas przechodzenia od rozwoju do produkcji.

Rozwój to inny czajnik ryb. Mam tendencję do dzielenia zapytań o media, tak aby były według dowolnego elementu, np .:

.foo { // .. some css }
.foo:hover, .foo:focus { // hover css }
@media screen and (max-width: 400px) {
    .foo { // .. some differentcss }
}

Jak zwykle, jeśli zmieniam element, nie chcę rozglądać się po całym CSS (chociaż możesz użyć czegoś takiego jak grep ...).

Ale jedno powiedziałbym, że warto wziąć pod uwagę samą stronę, proces rozwoju i soforth. Jeśli naprawdę uważasz, że warto je rozdzielić na pliki o rozmiarze ekranu, spróbuj. Zrób kopię strony (jeśli to możliwe), baw się z nią - jeśli to ułatwi, skorzystaj z niej. Nie musisz przestrzegać jednego uniwersalnego paradygmatu tworzenia witryny.


1

Proste: użyj 1 arkusza stylów i po prostu dodaj do nich komentarze, aby łatwiej znaleźć i zmienić style CSS, np .:

//sheet 1 (mobile device 800 px)
code

//sheet 2 (mobile device 768 px)
code

//sheet 3 (mobile device 480 px)
code

//sheet 4 (desktop size 1024 px)
code

Jeśli chcesz, możesz użyć wielu arkuszy stylów i wywołać je dla każdego określonego rozmiaru.


-1

Wolałbym spojrzeć na Bootstrap . Jest to 1 plik CSS, który zawiera cały CSS. Działa na prawie 99% przeglądarek i bardzo szybko reaguje.

Kliknij prezentację na żywo, aby powiększyć ( Ctrl += powiększyć, Ctrl -= pomniejszyć, Ctrl 0= normalny) lub otworzyć ją na telefonie komórkowym, aby zobaczyć, jak się renderuje.


2
Napisał już 30 KB CSS, w jaki sposób przejście na bootstrap może być korzystne?
Steve Sanders,

Ujmując to w ten sposób, tak, zgadzam się, że 30kb css to misja do ponownego wykonania. Chciałbym po prostu skopiować i wkleić go do różnych arkuszy stylów, wszystko w zależności od struktury, w której można powielić i zmienić nazwy plików css i usunąć wszystkie niepotrzebne części.
Regardt Ogies Myburgh,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.