Linee guida per il processo di ottimizzazione HTML / CSS / JS

Naviga le tue risposte
2

Attualmente abbiamo un server di sviluppo su cui scriviamo il codice HTML / CSS / JS. Non ottimizziamo il nostro codice utilizzando compressori / minificatori. Quindi il nostro processo di distribuzione dallo sviluppo alla produzione è semplicemente quello di copiare i file sul server di sviluppo sul server di produzione.

Ma ora stiamo progettando di utilizzare compressori / minifiers. Siamo confusi riguardo al processo che dovremmo seguire. Attualmente utilizziamo un singolo file JS chiamato common.js e un singolo file CSS chiamato common.css. Inoltre ora stiamo progettando di usare più file CSS in Dev come reset.css, common.css, ecc. E quando li distribuiremo in produzione li combineremo in un singolo file CSS.

Il processo più semplice che riesco a pensare è:

  1. Crea una copia esatta dei file di sviluppo sul server di sviluppo. Usa la copia negli ulteriori passaggi.
  2. Combina tutti i file CSS in un singolo file CSS come common.css. Lo stesso con i file JS. Elimina gli altri file, ad esempio reset.css.
  3. Comprimi / riduci common.css e common.js a common.min.css e common.min.js. Elimina common.css e common.js.
  4. In tutti i file HTML rimuovi tutti i tag link e i tag script ad eccezione di common.css e common.js
  5. In tutti i file HTML, modifica lo script src e link href da common.js a common.min.js e common.css a common.min.css.
  6. Copia tutti i file sul server di produzione.
  7. Elimina la copia

Questo sembra noioso per noi. Quale può essere un processo migliore? C'è uno strumento che può fare automaticamente l'ottimizzazione (sopra i passaggi). Sembra che non sarebbe molto difficile scrivere uno script che esegua tutti i passaggi precedenti. Ma mi piacerebbe utilizzare uno strumento esistente piuttosto che svilupparne uno da solo. Vorrei mettere gli sforzi solo se tale strumento non esiste.

Anche quando il test viene generalmente eseguito? Penso che dovrebbe essere eseguito sui file ottimizzati (nel caso in cui i compressori abbiano qualche bug). Ma il processo diventerebbe sempre più noioso, poiché il processo sopra riportato dovrebbe essere ripetuto dopo ogni ciclo Test-Bugfix.

    
posta Cracker 10.07.2011 - 12:24
fonte

4 risposte

2

Ho lavorato a un progetto molto vicino alla tua situazione. I requisiti erano i seguenti:

  1. Sul lato dello sviluppo, ogni pagina può avere uno o più file JavaScript e uno o più file CSS. Tutti questi file sono locali.
  2. Nella produzione, devono esistere uno e un solo file JavaScript e uno e un solo file CSS. Questi due file sono ospitati su un server remoto, ottimizzati per i file statici e configurati per la memorizzazione nella cache lato client e server.
  3. Ogni pagina ha un collegamento a JQuery ospitato su Google CDN in entrambi gli ambienti di sviluppo e produzione.
  4. Il processo di distribuzione deve essere automatizzato.
  5. Il processo di distribuzione non deve modificare file diversi da JavaScript e CSS per la compressione.
  6. Il sito Web è scritto in ASP.NET.
  7. Ogni pagina del sito web utilizza lo stesso CSS e lo stesso JavaScript.
  8. Sul lato dello sviluppo, i file CSS e JavaScript sono sempre in una directory predefinita specifica.

Ecco cosa è stato fatto dal mio collega che ha lavorato a questa parte del progetto.

  1. Tutti i file tranne JQuery vengono ridotti e combinati in due file: g.css e g.js , g per global . Questo viene fatto semplicemente camminando attraverso la directory specifica e cercando quei file. Dopo averli ridimensionati, i due file vengono inviati al server del contenuto statico, se sono stati modificati dall'ultima implementazione.
  2. Il processo viene eseguito ad ogni build, dal momento che non siamo riusciti a trovare come eseguirlo solo a livello di distribuzione. Dopotutto, non importa, poiché ci vogliono alcuni millisecondi per esaminare tutti i file e controllare se sono stati modificati dall'ultima build.
  3. Il sito Web viene distribuito così com'è, ad eccezione dei file JavaScript e CSS originali. Non ne abbiamo bisogno nella produzione.
  4. La masterpage (in ASP.NET) contiene un metodo specifico che regola le chiamate ai file JavaScript e CSS a seconda del contesto.

Questo metodo è come questo: 

public string MakeCssCalls(IList<string> cssFiles)
{
    // ...
}

Nell'ambiente di sviluppo, ha restituito i collegamenti ai file CSS all'interno dell'argomento cssFiles . In produzione, ha ignorato questo argomento e ha appena restituito "<link rel="stylesheet" href="http://static.example.com/g.css" type="text/css" />" . Ha fatto la differenza tra produzione e sviluppo confrontando il nome della macchina con la lista dei nomi in Web.config file: alcune macchine sono state configurate come macchine di sviluppo; tutte le macchine al di fuori di questo elenco erano presunte server di produzione.

Per quanto riguarda le prestazioni, sarebbe più intelligente avere un file Web.config diverso per la produzione, a indicare che siamo effettivamente in produzione (e, ad esempio, precedere il collegamento esatto al server statico con quei file; nel nostro caso era hardcoded e questo fa schifo). Non potremmo farlo in questo modo perché uno dei requisiti di questo progetto era di avere un singolo file Web.config per tutti gli ambienti, ma se puoi, fallo.

Also when is the testing generally performed? I think it should be performed on the optimized files (just in case the compressors have some bug).

Abbiamo testato il sito Web su versioni non minificate di file. Non abbiamo mai avuto alcun bug proveniente da Google Closure (né dal nostro minificatore CSS schifoso fatto in casa).

    
risposta data 10.07.2011 - 14:47
fonte
0

Se utilizzi Apache, un'ottima soluzione (nella mia esperienza) è mod_pagespeed . È un plug-in Apache che analizza automaticamente la tua pagina e minimizza, inline e comprime i file e le immagini CSS / JS. Garantisce inoltre che tu abbia intestazioni di Cache-Control appropriate e persino supporti i download in parallelo (se imposti più hostname per puntare al tuo server).

Fondamentalmente, fa gran parte del lavoro "difficile" per te automaticamente.

Ovviamente, il lato negativo è che mette un po 'di carico extra sulla CPU sul tuo server (dal momento che deve analizzare / riscrivere tutto quell'HTML), ma nella mia esperienza la maggior parte dei server web non sono legati alla CPU e quindi questo è accettabile.

    
risposta data 10.07.2011 - 12:50
fonte
-1

Strumenti come YUI Compressor e JSB2 / JSB3 possono essere usati con form per far funzionare il tuo processo in un unico passaggio senza molte impostazioni.

    
risposta data 10.07.2011 - 22:50
fonte
-3

Funziona solo con la versione compressa in dev ...

Mi sono imbattuto anche in questo problema, attualmente lavoro solo nello sviluppo con le versioni minificate. In realtà non è così difficile, puoi sempre estrarre la versione "non minificata" dal controllo del codice sorgente se devi apportare modifiche importanti.

I CSS in stato minisito sono ancora molto modificabili. inoltre tendo a "sminuire" solo il blocco di css su cui sto lavorando. poi, una volta che sono felice, lo ridimensiono di nuovo.

Questo evita passaggi aggiuntivi / a seconda degli script ecc.

    
risposta data 10.07.2011 - 13:42
fonte

Leggi altre domande sui tag

Supporto linguistico per la delega (sintattica) in Java Pagine diverse per dispositivi mobili?