Cum să aflați ce stiluri CSS nu sunt folosite. Instrumente de curățare CSS. Revizuirea structurii proiectului

Beneficiile unui CSS curat și organizat sunt evidente. Un site web cu CSS impecabil se va încărca mai repede și va fi mai vizibil în rezultatele căutării. Pentru dezvoltatorii web cod curat CSS servește ca o dovadă clară a profesionalismului pentru viitorii clienți.

Însă, curățarea resturilor de marcare CSS prin nenumărate iterații și modificări de proiectare poate fi un proces minuțios, care necesită timp, realizat manual. Din fericire, există unele minunate și instrumente utile, care vă va ajuta să automatizați unele dintre cele mai relevante Aspecte CSS. Pe această pagină există link-uri către instrumente de curățare CSS pe care le-am verificat personal Markup CSS pe toate instrumentele de mai jos, vă sfătuiesc să faceți același lucru.

Instrumente de curățare CSS

ProCS sau pentru a vă îmbunătăți CSS

ProCSSor este un instrument simplu, fără ornamente, pentru îmbunătățirea instantanee a CSS-ului. Disponibil prin OS X, iOS sau orice browser, instrumentul preia fișierul CSS, fragmentul lipit sau adresa URL și corectează imediat și afișează codul viitor pentru CSS.

CSS Lint

Instrument Verificări CSS cu explicarea modificărilor

CSS Lint oferă recomandări, spre deosebire de alte instrumente de curățare CSS. Majoritatea dintre ele nici măcar nu vorbesc despre modificările CSS, dar CSS Lint oferă o scurtă explicație pentru fiecare dintre modificările recomandate. El are întreaga linie caracteristici care se concentrează pe erori, compatibilitate, performanță, deduplicare și accesibilitate, care pot fi activate sau dezactivate.

Markup murdar

Instrumentul Dirty Markup combină mai multe diverse tehnologii

Dirty Markup are o abordare unică a optimizării codului; funcționează atunci când câmpul este umplut cu cod și combină mai multe tehnologii diferite: HTML Tidy, JavaScript, Ace Editor și face curățarea completă a codului. Funcționează la fel ca CSS, la fel ca JavaScript sau HTML standard.

CleanCSS

Instrumentul CleanCSS realizează optimizarea CSS

CleanCSS funcționează cu o adresă URL sau o bucată de cod inserată și oferă o varietate de execuții de optimizare CSS. Puteți alege între cinci diverse setari compresii care oferă compromisuri între lizibilitate și dimensiunea fișierului.

Cod de înfrumusețare

Cod de înfrumusețare css simplu instrument de curățare

Code Beautifier este un instrument simplu de curățare CSS, fără caracteristici inutile. Procesează codul după adresă URL sau inserarea codului și le curățește temeinic pe baza unei varietăți practice de opțiuni. Dacă trebuie să curățați rapid CSS-ul fără a vă pierde într-o mare de opțiuni de curățare a codului, acesta ar putea fi instrumentul dvs. ideal de curățare CSS.

Spritemapper

Spritemapper generează sprite-uri, combină mai multe imagini într-o foaie de stil CSS

Niciunul dintre celelalte instrumente nu a menționat imagini optimizate, ceea ce este la fel de util ca și optimizarea codului în sine. Spritemapper generează sprite-uri, combină mai multe imagini într-o foaie de stil CSS c pozitionare corecta. Rezultatul este un site mai rapid, mai puține solicitări HTTP și un stil CSS mai eficient.

Strat de acoperire

Topcoat nu este un instrument tradițional de curățare CSS

Topcoat nu este un instrument tradițional de curățare CSS; acesta este în esență un set pentru Dezvoltare CSS, o abordare pură de curatare CSS. Dacă aveți CSS bine scris, probabil că nu va trebui niciodată să curățați codul CSS.

Instrumentul CSSTidy rulează pe platforme Windows, Mac sau Linux.

CSSTidy este similar cu multe instrumente de curățare CSS, dar acesta oferă câteva atribute unice. CSSTidy poate fi invocat folosind linia de comandă sau PHP și rulează pe platforme Windows, Mac sau Linux. Instrumentul de curățare CSSTidy se poate integra perfect în fluxul dvs. de lucru existent și vă poate salva CSS curat deconectat. Instrument de validare a codului CSS W3C Valdiator

W3C Valdiator nu oferă instrumente de curățare, compresie sau optimizare a codului, dar trebuie luat în considerare în cazurile în care codul CSS este cu adevărat spart. Instrumentele de mai sus au propriile lor instrumente, acesta fiind realizat de Consorțiul W3C care creează standarde.

Bună ziua, dragi cititori ai blogului. Aceasta este o mică notă din seria „ca suvenir”. A apărut ideea de a elimina linii suplimentare din fișierul de stiluri. De-a lungul celor șapte ani de existență a blogului, multe lucruri s-au schimbat, dar rândurile din fișierul STYLE.CSS au rămas (pentru orice eventualitate, sau pur și simplu am uitat să le elimin). Acum mi s-a părut că a început să cântărească prea mult și de aceea a apărut ideea de a o curăța.

A face acest lucru manual este destul de dificil și nu este necesar. Există modalități acest proces automatiza. Unele dintre ele nu au funcționat pentru mine, altele trebuiau plătite și am considerat că este inutil. În final, am folosit o metodă semi-automată, despre care voi scrie în următoarele paragrafe. Privind în viitor, voi spune că am reușit să reducem dimensiunea fișierului CSS la aproape jumătate, ceea ce chiar m-a surprins puțin.

Opțiuni pentru găsirea stilurilor CSS care nu sunt necesare pentru site-ul web

Înlocuirea fișierului de stiluri (conținutul său - șters pe cel vechi, introdus pe cel nou și apoi salvat modificările prin fișierul fișier) cu unul nou (tăiat) modificări vizibile nu a cauzat probleme pe site (cel puțin nu încă, cel puțin nu identificate). În general, sunt foarte mulțumit și recomand să îl încerc. Rapid, simplu și convenabil (și, de asemenea, gratuit).

Multă baftă! Inainte de pe curând pe paginile site-ului blogului

Puteți viziona mai multe videoclipuri accesând

");">

S-ar putea să fiți interesat

Cum să maximizați viteza de încărcare a site-ului și să optimizați încărcarea serverului
CSS - ce este, cum sunt conectate foile de stil în cascadă la codul HTML folosind Style și Link
Optimizarea și compresia CSS în Viteza paginii- cum se dezactivează fișiere externe stiluri și combinați-le într-unul singur pentru a accelera încărcarea Cum se configurează rotația culoare de fundal rânduri de tabele, liste și altele elemente HTML pe site-ul web folosind pseudoclasa a nth-child
Pentru ce este CSS, cum să conectați foile de stil în cascadă la document HTMLși sintaxa de bază a acestui limbaj
Stilul listei (tip, imagine, poziție) - reguli CSS pentru setari aspect liste în cod HTML
Cum să obțineți un site rapid - optimizarea (comprimarea) imaginilor și scripturilor, precum și reducerea numărului Solicitări HTTP

4 din 5

Mulți dezvoltatori se confruntă cu faptul că, după ceva timp de lucru la un proiect, în fișiere CSS apar stiluri despre care este imposibil de spus cu certitudine dacă sunt folosite sau nu. Acest lucru se întâmplă adesea atunci când lucrezi în echipă și mai mult de o persoană lucrează la stiluri. Sau, de exemplu, au fost mai mulți dezvoltatori înaintea ta și ai decis să schimbi ceva sau designerul a plănuit o mică reproiectare. În general, există multe opțiuni, dar rezultatul este același - selectoare „moarte” sunt date browserului.

Totul ar fi bine dacă ar fi doar unul sau două dintre ele, dar dacă fișierul dvs. are cinci sau șase mii de linii, atunci nu există nicio îndoială - nu sunt folosiți toți selectoarele, ceea ce înseamnă că prin eliminarea celor inutile puteți face fișiere mai ușoară și accelerează încărcarea paginii. Astăzi ne vom uita la diverse programe, pluginuri și servicii pentru curățarea fișierelor CSS de stiluri inutile.

Extensii Firefox

Ia în considerare stilurile incluse în pagină prin , @import și. Poate analiza atât o singură pagină, cât și întregul site. La sfârșit veți obține o listă de selectori care nu sunt utilizați pe site.

Aceasta este o extensie pentru FireBug care vă permite să găsiți selectoare neutilizate, cum ar fi pe pagină separată, și pe tot site-ul. În consecință, veți primi o listă cu toți selectorii dvs., printre care cei marcați cu roșu vor fi neutilizați.

Servicii web

Instrument online pentru a verifica ce selectoare acest fișier nu este folosit pe pagini specifice site-ul. Dezavantajul este că nu puteți evalua întregul site (sau mai degrabă, este posibil, dar consumă mult timp și este incomod).

Editori desktop

O listă de editori de cod care știu cumva să găsească stiluri CSS neutilizate.

TopStyle (win)

Acesta poate găsi și selectori care sunt utilizați pe pagini, dar pentru care nu există o descriere în fișierele CSS.

IntelliJ IDEA (Win, Mac, Linux)

Un editor multiplatformă conceput în principal pentru lucrul cu Java.

Concluzie

După părerea mea, cel mai de succes instrument dintre acestea este Dust Me. Analiza întregului site durează mai puțin de un minut, după care trebuie doar să găsiți și să eliminați selectoarele specificate.

Apropo, dacă cineva dintre voi folosește un editor sau un serviciu care nu se află pe această listă, atunci scrieți în comentarii, îl voi adăuga. Vă mulțumesc tuturor pentru atenție ;-)

Tocmai v-ați alăturat unui proiect existent pentru a înlocui un dezvoltator care pleacă. Sau poate că tocmai au preluat vechiul lor proiect după câțiva ani. Simți groază și dezgust când te uiți la cod. Există un singur lucru pe care îl poți face: curățați toată mizeria. Ați mai întâlnit ceva asemănător? Aproape sigur, mai devreme sau mai târziu toată lumea experimentează asta.

Știți că curățarea codului CSS este o sarcină mare. Sunt multe de făcut timp limitat- mai ales când clienții/șefii/colegii sfătuiesc insistent să nu atingeți ceea ce funcționează. Nici nu știi de unde să începi.

Litting este totul pentru noi

În această secțiune voi presupune că utilizați Sass. Și nu numai pentru că este o presupunere rezonabilă în condițiile actuale, dar și pentru că utilizarea greșită a Sass cauzează adesea contaminarea bazei de cod. Deși acest articol va fi util pentru cei care nu folosesc preprocesoare, așa că ar trebui să îl citiți până la capăt.

Primul lucru pe care sunt obișnuit să-l fac atunci când trebuie să înțeleg o bază de cod este listing. Linting este procesul de executare a unui program care caută erori potențiale și practici proaste. Cred că făcând codul curat facem primul pas către cod bun. Etimologia cuvântului linting poate fi găsită în acest thread pe StackOverflow.

Sass are un linter scris în ruby ​​numit SCSS-lint. Puteți să o configurați singur sau să descărcați configurația recomandată de Sass-Guidelines pentru a începe imediat. De asemenea, Node.js are sass-lint, nu sunt 100% compatibile și pot funcționa diferit.

Încercați să rulați SCSS-Lint în directorul de fișiere Sass pentru a verifica dacă există erori. Sunt șanse foarte mari ca o mulțime de erori să cadă asupra ta. De obicei, după aceasta, doriți să opriți experimentarea cu curățarea codului. Fii răbdător. Acum poți încerca să faci configurația mai puțin strictă în ceea ce privește regulile care nu sunt foarte importante pentru tine (cum ar fi formatul de culoare) sau să iei taurul de coarne și să folosești toată puterea de scame.

Corectarea erorilor găsite

Este timpul să reparăm ceea ce trebuie reparat. Acest lucru se poate face în două moduri. Primul este să verificați toate fișierele unul câte unul și să corectați toate erorile și deficiențele, cum ar fi denumirea nereușită a variabilelor, imbricarea excesivă a selectoarelor și codul prost formatat. Al doilea (preferatul meu) este să folosești căutare și înlocuire. Nu știu despre tine, dar îmi plac expresiile regulate și îmi place mereu să le folosesc în munca mea.

Să presupunem că doriți să adăugați un zero lipsă în toate numerele cu virgulă mobilă (adică de la 0 la 1), aceste tipuri de erori sunt surprinse folosind regula LeadingZero în SCSS-lint. Pentru a face acest lucru, trebuie să utilizați pentru căutare expresie uzuala\s+\.(\d+) (toate numerele după un spațiu cu un punct), iar pentru înlocuire \ 0.$1 (spațiu, zero, punct și numărul găsit). Și dacă sunteți îngrijorat de regula BorderZero linter, atunci puteți înlocui toate regulile border: none cu border: 0 în editorul dvs. utilizând căutare/înlocuire. La fel de ușor ca o plăcintă!

Am creat recent depozitul scss-lint-regex pe GitHub pentru a colecta toate expresiile regulate pentru lining într-un singur loc. Cu siguranță, aruncați o privire la el dacă aveți probleme cu scame într-un proiect mare. Și aveți grijă la găsirea/înlocuirea, uneori poate avea efecte secundare neașteptate. După fiecare modificare, rulați un git diff pentru a identifica ce s-a schimbat, acest lucru vă va asigura că nu adăugați erori la codul dvs.

Odată ce ați terminat cu editarea de căutare/înlocuire, nu veți mai putea scăpa editare manuală, în acele locuri care trebuie rafinate (indentări incorecte, lipsă sau exces linii goale, spații lipsă etc.). Acest lucru necesită mult timp, dar vă va ajuta foarte mult în următorul pas, așa că este important să faceți acest lucru înainte de a trece mai departe.

Nota traducătorului

Unele dintre aceste lucruri pot fi făcute folosind plugin-urile SassBeautify editori de text, de exemplu sublim sau atom .

Revizuirea structurii proiectului

Ceea ce mă deranjează foarte mult atunci când mă alătur unui proiect existent este lipsa unei arhitecturi adecvate a proiectului. Poate că a existat un fel de proiect chiar la începutul lucrării, dar în timp lucrurile scapă de sub control și planul inițial se pierde. Dar este încă incredibil de important.

Alegerea metodologiei proiectului nu este atât de importantă, principalul lucru este că o aveți și să nu vă provoace disconfort. Ar putea fi SMACSS, 7-1 sau ITCSS - alegerea vă aparține. Încercați să vă restructurați codul conform metodologiei alese. Tind să folosesc modelul 7-1 pe care l-am dezvoltat în Sass Guidelines, așa că vă voi oferi câteva sfaturi pentru a vă ajuta dacă alegeți această rută.

Apoi să mergem la directorul de rezumate. Toate variabilele, mixurile, funcțiile și substituenții ar trebui să meargă aici. Sunteți liber să le aranjați după cum doriți, până când veți înțelege toate variabilele și mixurile din baza de cod. De asemenea, identific variabile opționale (și mixine) în această etapă, deoarece întâlnesc adesea variabile care sunt folosite o dată sau de două ori.

Odată ce v-ați dat seama de acest lucru, va trebui să decideți care dintre cele două pasii urmatori fa-o mai devreme. Puteți încerca să vă asigurați că tot conținutul directorului de bază este cu adevărat stiluri de bază și nu stiluri componente. Sau verificați dacă directorul de aspect conține tot ce se referă la aspectul paginii și că acest cod este documentat corect.

În cele din urmă, pentru a finaliza lucrurile, trebuie să construiți directorul de componente, care este de obicei o sarcină uriașă. Sfatuiesc sa faceti componente cat mai mult posibil dimensiune mai micăși concentrați-vă pe utilizarea lor repetată. Nu contează dacă creșteți numărul acestora - atâta timp cât sunt fără context și ușor de citit, înțeles și actualizat.

Ca exemplu de componentă corectă și mică, pot da următoarele:

Citat ( padding: 10px; ) .quote__attribution ( dimensiunea fontului: 80%; ) .quote > :first-child ( margin-top: 0; ) .quote > :last-child ( margin-bottom: 0; )

Încercați să gândiți în module. Mai puțin. Mai uşor. Mai independent.

Eliminarea inutilă

Cred că cel mai mult o mare diferentaîntre rău şi CSS bun aceasta este cantitatea de cod. CSS este foarte ușor de dezvoltat. Unii oameni pot face aproape orice aspect prin încercare și eroare. Abilitatea de a face orice folosind CSS minim necesită muncă, iar menținerea unei abordări minimaliste este o adevărată provocare.

Au trecut deja 3 ani, dar acest tweet al lui Nicholas Gallagher rămâne întrebarea mea preferată CSS:

Deprecierea este adevărata ciuma a CSS. Când scriem stiluri, de multe ori mergem înainte și înapoi, încercând reguli noi - de obicei ajungem să lăsăm câteva declarații complet inutile. De exemplu, overflow: hidden , care nu mai este necesar, sau font-size , care nu modifică dimensiunea fontului. Lăsându-le, creștem datoria tehnică. Nu este nimic bun în asta.

Când scriu CSS, sunt obișnuit să deschid instrumentele pentru dezvoltatori în browser și să dezactivez fiecare declarație CSS una câte una înainte de a trimite codul finit pentru a testa ceea ce afectează acestea. Dacă nu afectează nimic, atunci primul lucru pe care mă întreb este: „De ce sunt ei aici?” Dacă se dovedesc a fi inutile, le șterg. Cu o tehnică simplă ca aceasta, mă pot asigura că numai cod util și nici un nedorit este trimis în depozit.

Ștergerea codului Bazele CSS este aceeași tehnică. Identificați componenta pe care doriți să o curățați, deschideți instrumentele de dezvoltare și încercați să găsiți declarații inutile. Uneori, pentru a elimina codul CSS, trebuie să mutăm aceste stiluri în sus în arbore pentru a profita de funcțiile în cascadă. Să ne uităm la asta cu următorul exemplu simplu:

Părinte ( /* ...lucruri aici... */ ) .copil-A (culoare: roșu; ) .copil-B (culoare: roșu; )

Optimizarea evidentă este să mutați culoarea: declarația roșie în selectorul părinte și apoi lăsați cascada să facă restul pentru noi. Cu siguranță, exemple reale sunt de obicei mai complexe, dar acest exemplu arată, de asemenea, că nu trebuie să uitați posibilitățile „C” din abreviere CSS.

CSS este inteligent și ar trebui să fii la fel de inteligent

De asemenea, este foarte obișnuit să nu înțelegeți semnificațiile moștenire, culoare inițială și culoare curentă. Să presupunem că doriți ca linkurile să aibă aceeași culoare cu textul principal (sunt deja destul de subliniate). Iată cum să nu o faci:

A (culoare: negru; /* Nu */ )

Motivul pentru care această soluție eșuează este evident: dacă schimbați culoarea corpului, culoarea linkului nu va fi sincronizată cu ea. Dacă vă gândiți să utilizați o variabilă, aceasta va complica lucrurile inutil. Și în sfârșit, dacă linkul este plasat în interiorul unui element cu propriul stil(de exemplu, într-un citat), nu se va potrivi cu culoarea sa.

CSS are o modalitate încorporată de a rezolva această problemă, valoarea de moștenire:

A (culoare: moștenire; /* Da! */ )

În mod similar, atunci când reveniți la valoarea implicită a unei proprietăți, ar fi o idee proastă să o setați valoare fixa. În CSS există o valoare inițială pentru astfel de cazuri. De obicei, nu este diferit de setarea unor valori fixe, dar există cazuri când joacă cu adevărat un rol, de exemplu, atunci când se determină direcția textului în proprietatea text-align. La resetarea text-align , valoarea stângă poate deteriora textul în limbile RTL (de la dreapta la stânga), rezultatul va fi inițial (și mai bine este start, dar această valoare nu este acceptată în IE9)/.

Ultima pe listă, dar nu cea mai puțin importantă valoare este currentcolor , mulți dezvoltatori nu știu despre ea. Dacă sunteți unul dintre ei, nu vă faceți griji, întrebați-vă: „Dacă nu ați setat culoarea chenarului elementelor, atunci de ce se potrivește automat cu culoarea fontului elementului?” Da, acest lucru se întâmplă deoarece în mod implicit proprietatea border-color este setată la currentcolor (specificație). De acord, totul este evident din nume.

În opinia mea, dacă doriți să utilizați culoarea fontului unui element, ar trebui să utilizați currentcolor în loc de o valoare fixă ​​sau variabilă Sass.

Element (culoare: deeppink; chenar: 1px solid; /* Culoarea este implicită cu `currentcolor` */ ) .element svg ( umplere: currentcolor; /* Culoarea de umplere va fi aceeași cu textul */ )

Asta este tot capabilități de bază CSS. Ei fac CSS așa cum este. Și aceste oportunități sunt folosite surprinzător de rar. Prin urmare, dacă decideți să îmbunătățiți codul componentei, nu trebuie să le neglijați.

Git-ul tău ar trebui să fie bine

Refactorizarea unei baze de cod CSS este multă muncă. Va trebui să actualizați zeci de fișiere. Și este probabil să spargi ceva în acest proces. Să fim sinceri - toată lumea face greșeli și ar fi incredibil de tare dacă ai reuși să duci la bun sfârșit o astfel de muncă fără vreo mică greșeală.

Prin urmare, vă recomand cu tărie să lucrați cu sârguință cu sistemul dvs. de control al versiunilor (este logic să presupunem că Git joacă acest rol). Aceasta înseamnă că toate commit-urile fac un singur lucru - oferiți un pas înapoi față de codul cu eroarea fără a suferi conflicte.

Știu că mulți oameni consideră Git complex și greu de înțeles, iar modalitățile de a-l învăța cu ușurință depășesc scopul acestui articol. Crede-mă: istoria ta Git ar trebui să fie ca o poezie dacă nu vrei ca creierul tău să se scurgă.

Concluzie

Deci, voi formula pe scurt punctele principale ale articolului pentru cei cărora le este prea lene să citească întregul text:

Curățarea unui proiect CSS/Sass este dificilă, deoarece este dificil să se evalueze imediat impactul complet al unei modificări sau al ștergerii. șiruri CSS. Toate acestea se datorează în principal testabilității slabe a CSS. Prin urmare, trebuie să fii atent.

Începeți cu listing și codul dvs. va deveni mai frumos. Fă asta pentru că îți va face viața mai ușoară în viitor. e la fel mod bun prezentare generală a stării codului dvs. fără prea multe riscuri (repararea murdăriei sintactice nu ar trebui să cauzeze probleme).

Apoi structurați-vă proiectul în funcție de metodologia aleasă. Indiferent pe care o alegeți, este important să o urmați. Dacă proiectul tău nu are prea multe componente, atunci structurarea va fi un bun inceput. Găsiți părți reutilizabile ale interfeței și transferați-le stilurile în fişiere separate. Simțiți-vă liber să scrieți documentație, acest lucru va ușura procesul și veți simți că mergeți mai departe.

După ce v-ați curățat proiectul și ați sortat toate componentele, este timpul să îmbunătățiți CSS-ul. Mai întâi verificați ce puteți elimina, pentru că întotdeauna scriem prea mult cod. Apoi încearcă să-l optimizezi astfel încât să fie mai puțin repetitiv. Nu exagera! Treaba ta este de a reduce complexitatea, nu de a o crește. Nu uitați să comentați orice nu este evident la prima vedere.

Și, în sfârșit, angajamentele tale ar trebui să fie regulate și logice. Combină modificările în mici comisioane, fiecare făcând una lucru simplu- acest lucru vă va face mai ușor să anulați modificările dacă faceți ceva greșit.

Nu în ultimul rând, nu uita să sărbătorești când totul se termină. Noroc!

De la autor: Este destul de dificil să vorbim despre stiluri monolitice, deoarece, de obicei, fișiere CSS adesea se umfla. Eliminarea stilurilor CSS neutilizate ar trebui să pună lucrurile sub control. Înainte de a începe să căutăm stiluri nefolosite, merită remarcat faptul că există multe alte strategii pentru a scrie stiluri care pot fi întreținute. Stilurile noastre pot fi împărțite în părți logice (aspect de pagină, butoane, grile, widget-uri etc.) și folosesc un sistem de denumire clar (de exemplu, BEM). De obicei, dezvoltatorii fac acest lucru chiar înainte de a căuta reguli neutilizate. Cred că acest lucru este corect, deoarece stilurile au un impact pe termen lung.

Un alt motiv pentru care regulile nu sunt tăiate foarte des este că este pur și simplu incomod să găsiți și să eliminați stiluri nefolosite în ceva mai mare decât un proiect web mic. Dacă conținutul nu este static, de unde știți ce reguli sunt utilizate și unde?

Instrumentul pentru dezvoltatori Chrome

Se dovedește că în instrumente Dezvoltator Chrome există deja o funcție încorporată. L-am testat pe un site despre care știam că are o mulțime de stiluri care puteau fi eliminate. Sentimentele erau amestecate. Bariera de intrare este foarte mică, mai ales pentru dezvoltatorii care au lucrat deja cu Chrome Developer Panel. Nu trebuie sa instalezi nimic, e frumos.

Ce trebuie să faceți pentru a verifica stilurile de pe site:

Deschide site-ul care te interesează

Deschideți panoul pentru dezvoltatori

Accesați fila Audituri

Selectați opțiunea de performanță a paginii web și rulați

Unele rezultate vor spune „Eliminați regulile CSS neutilizate”. Dacă nu, atunci nu aveți stiluri nefolosite. Felicitări! Rezultatele sunt împărțite în funcție de stil. Defalcarea nu este doar pe fișiere, ci pe blocuri de stil. Într-adevăr caracteristică utilă, deoarece avem nevoie doar de acele stiluri pe care le-am scris. Cel puțin în sensul acestui articol.

Este bine?

Nu am găsit grozav calea usoara exportați rezultatul din Chrome. Puteți copia direct dintr-un bloc, dar mai întâi trebuie să îl extindeți. Acest lucru face ca analizarea rezultatelor să fie puțin dificilă. Rularea testului în browser ne îndepărtează și mai mult de a lucra cu codul, ceea ce poate duce la uitarea de a testa site-ul.

Concluzie: Utilă pentru început, dar nu o soluție pe termen lung.

UnCSS

Puteți utiliza instrumentele din linia de comandă pentru a găsi stiluri neutilizate. UnCSS este un exemplu interesant. Trage pagina prin phantomJS și prinde stilurile inserate prin JS. Mi-am dorit foarte mult să încerc acest instrument pentru că mi-a rezolvat problema, deoarece Chrome Developer Toolbar nu se referă deloc la editarea codului. Cu UnCSS rezultatul poate fi salvat direct într-un fișier, perfect.

Instalare

Nu am putut rula npm install uncss pe Ubuntu. Nimic grav, se pare că am uitat câteva dependențe. Comenzi de instalare biblioteci lipsă pe care am alergat:

sudo apt-get update sudo apt-get install build-essential chrpath libssl-dev libxft-dev sudo apt-get install libfreetype6 libfreetype6-dev sudo apt-get install libfontconfig1 libfontconfig1-dev

sudo apt - obțineți actualizare sudo apt - get install build - esențial chrpath libssl - dev libxft - dev sudo apt - obțineți instalarea libfreetype6 libfreetype6 - dev sudo apt - obțineți instalarea libfontconfig1 libfontconfig1 - dev

UnCSS poate fi integrat în procesul de construire, dar vom omite asta pentru moment. Cred că inserarea lui în procesul de construire nu este cea mai bună bună idee. Addy Osmani are ceva pe acest subiect bun articol. În mod ideal, am dori să eliminăm stilurile neutilizate direct din cod, mai degrabă decât să le filtram pur și simplu pentru produsul final.

Pot fi, cea mai bună cale de ieșire- face pe amândouă. Mai întâi, rulați-l ca pas de preconstrucție pentru a optimiza codul. În al doilea rând, rulați un pas de construcție pentru a optimiza stilurile pe care nu le controlați.

Folosind linia de comandă

uncss http://your-site.foo/ > unused-styles.css

uncss http: //your-site.foo/ > unused-styles.css

Rezultatul este împărțit în stiluri de site-uri-site.com și browser Chrome, dar sunt stocate într-un singur fișier. Site-ul meu are un font minunat și toate pictogramele care nu sunt folosite pagina principala, a ajuns în ieșirea UnCSS. Nu contează pentru mine acum. Ele pot fi ascunse rulând din nou comanda și specificând ignoreSheets.

Rețineți că ignoreSheets poate accepta un șir (URL-ul complet al stilului care trebuie ignorat) sau o expresie regulată. O expresie regulată este mai ușoară deoarece există mai puține caractere și acoperă posibilele modificări ale căii fișierului.

IgnoreSheets /.*font-awesome.min.css/

Acesta este mesajul de eroare care apare când pagina expiră. Timeout-ul poate fi mărit folosind -t N, unde N este numărul de milisecunde (nu setați –t 360 și apoi vă întrebați de ce codul nu a așteptat 5 minute).

Concluzie: UnCSS este mai convenabil deoarece este mai aproape de locul unde editez stiluri. Fișierul de ieșire este util în eliminarea stilurilor inutile. Îi văd utilizarea din cauza opțiunii –includeSheets, care ignoră automat tot ceea ce se încadrează sub expresia regulată. Convenabil pentru, de exemplu, site-urile WordPress, unde diverse plugin-uri își pot ajusta stilurile, dar dezvoltatorul are nevoie doar de stilurile teme style.css etc.

Ce instrument ar trebui să folosesc?

La început am ales UnCSS și convenabil Linie de comanda. Cu toate acestea, în timp ce scriam acest articol, le-am încercat pe alte câteva site-uri și am obținut rezultate mai puțin promițătoare. În special, am mai multe site-uri create acum câțiva ani care folosesc un cadru în care sunt implicate comentarii permanente /*!*…*/. Nu funcționează bine cu PostCSS și, prin urmare, nu funcționează bine cu UnCSS. Nu am aprofundat încă problema, dar poate mai mult o noua versiune PostCSS iartă astfel de comentarii. Cu toate acestea, chiar acum aceasta a devenit o altă barieră și nu pot folosi pe deplin UnCSS în munca mea.