Uttrykke IT

Inkluder JavaScript er nederst i HTML-dokumentet

Hvis du ikke har document.write (eller noen dynamisk generering av siden innholdet med javascripts) for å sette en del av sidens innhold i skript, flytte skriptet inkludere uttalelse til bunnen av siden, før slutten av BODY taggen.
Den HTTP/1.1 spesifikasjonen antyder at nettlesere laste mer enn to komponenter i parallell per vertsnavn. Hvis du betjene dine bilder fra flere vertsnavn, kan du få mer enn to nedlastinger skje parallelt. Mens et skript nedlasting, men vil nettleseren ikke starte noen andre nedlastinger, selv på forskjellige vertsnavn.
Det finnes også måter å dynamisk opprette Script noder og laste eksterne skript etter at siden er lastet med AJAX.

Externalise du JavaScript s

Bruke eksterne JavaScript-filer vil resultere i raskere lasting av sider fordi JavaScript-filer blir lagret av nettleseren. Inline JavaScript 's' i HTML-dokumenter blir lastet ned hver gang HTML-dokument blir forespurt. Dette kan faktisk redusere antallet HTTP-forespørsler gjort, men det senere øker størrelsen på HTML-dokumentet. Ekstern JavaScript er bufres av nettleseren, størrelsen på HTML-dokumentet er redusert uten å øke antallet HTTP-forespørsler.
Vær oppmerksom på at dersom brukerne på nettstedet ditt har flere sidevisninger per sesjon og mange av sidene bruke de samme skript og stilark, er det en større potensiell nytte bufrede eksterne filer.

Pakk JavaScript-filer

Ved JavaScripts, i motsetning til CSS, kan filene knaste bruke noen standard algoritmer som vil gi en redusert filstørrelse enn bare å fjerne mellomrom eller tabulatorer. Et eksempel på javascript emballeringsbedrift finner du her http://dean.edwards.name/packer/

Bli kvitt eventuelle like Scripts

Det er svært uvanlig at hele skript kan bli duplisert, men en gjennomgang av de ti beste amerikanske nettsteder viser at to av dem inneholder en duplisert script. Dupliser scripts men tydeligvis reduserer ytelsen ved å skape unødvendige HTTP-forespørsler og bortkastet JavaScript utførelse.
Også i mange tilfeller, men de skriptene navnene er forskjellige, er det en sannsynlighet for dupliserte skript innenfor den samme siden på grunn av teamet størrelse og antall av skript.

Minimer tilgang DOM elementer der det er mulig

Tilgang DOM elementer med JavaScript er treg så for å få en mer responsiv side, bør du:
• Cache referanser til tilgang elementer
• Oppdatere noder "offline", og deretter legge dem til treet
• Unngå å feste layout med JavaScript

Separat atferd fra innhold og presentasjon

Akkurat som vi egen presentasjon (CSS / XSLT) fra Innhold (XHTML / XML), bør vi også skille Behavior (Javascript). Dette kalles påtrengende Javascript. Akkurat som vi koble til eksterne CSS-filer, bør vi koble til eksterne JavaScript-filer.

I stedet for hardt koding oppførsel i innhold (f.eks onmouseover, onclick, etc.), bør oppførsel dynamisk lagt til elementer, klasser og unike elementer (IDS) ved hjelp av DOM. Den grunnleggende dokument, innholdet, bør inneholde kun gyldig XHTML / XML og ingen javascript.
Javascript må utfylle innholdet ved å legge oppførsel. Innholdet bør forbli nyttig og brukbart uten javascript (eller uten full støtte for JavaScript).

Jeg har lagret denne artikkelen aldre tilbake, så Sorry! Jeg husker ikke kilden ... men det virket nyttig, for oss som må være klar om publikum for hvem vi utvikle området for ... så her jeg er

Side vekt kan brukes til å bestemme nedlastingstid for en gitt side på en rekke Internett tilkoblingshastigheter. Som eksempel viser følgende tabell nedlasting ganger for tre ulike sider ved en rekke populære tilkoblingshastigheter.

Fordeler med å redusere side vekt?

Den positive effekten av å redusere siden vekten fordeler både eiere og forbrukere. Potensielle fordeler inkluderer:

1. Sidene lastes raskere. Den mest åpenbare virkningen av å redusere siden vekten er at nettstedets sider vil lastes inn raskere for besøkende, uavhengig av deres tilkoblingshastighet.
2. Lavere side lasting skape mer komfortable besøkende. Besøkende er mindre sannsynlig å bli frustrert og gå andre steder hvis sidene lastes raskt. På den annen side, slow-loading sider er en av de sikreste måtene å miste besøkende og potensielle kunder.
3. Raskere last-tider vil bidra til økt konvertering. Flere besøkende skal bo på nettstedet ditt lenger. Flere av dem vil ende opp med å gjøre innkjøp, registrere seg for nyhetsbrevet, eller bok-merking ditt nettsted.
4. Din merkevare oppfatning vil bli styrket. Returnere kunder og førstegangsfødende tilreisende vil være mer tilbøyelig til å beskrive ditt nettsted (og bedrift) som "profesjonell" hvis sidene lastes raskt.
5. Sider med ren, solid kode vil ofte bli indeksert mer effektivt med naturlige søkemotorer.
6. Sider som er optimalisert for vekt kan faktisk spare båndbredde kostnader på høy trafikk nettsteder. 100.000 sider som hver veier 150 Kb vil kreve dobbelt så mye båndbredde fra din ISP enn 100.000 sider hver Vekt 75 Kb. For Internett-leverandører som tar betalt for båndbredden som brukes eller for overages, kan denne reduksjonen skape betydelige besparelser på båndbredde kostnader.

Vurder følgende data, publisert i en rapport

Sett Stilark på Top

Hvis du ønsker en side å laste progressivt, det vil si vi vil at leseren skal vise hva innhold den har så snart som mulig, sette CSS øverst på siden inne i dokumentet HEAD. Dette gjør sidene synes å være lasting raskere, da dette letter progressive gjengivelse av siden. Dette er spesielt viktig for sider med mye innhold og for brukere på tregere Internett-tilkoblinger.

Det er et dokumentert faktum at for å forbedre generelle brukeropplevelsen, er det viktig å gi framdrift indikatorer og visuelle tilbakemeldinger. For å slippe å tegne deler av siden, i tilfelle hvis deres stiler endring, noen nettlesere, inkludert Internet Explorer, blokker gjengivelse av siden til CSS er fullastet. På grunn av dette, brukeren er får å se en blank hvit side.

De W3 HTML Spesifikasjoner 'sier også at CSS skal meg inkludere i HEAD-delen av HTML-siden. at the bottom of the page, so it's best not to use it. Merk også at, I IE @import oppfører den samme som ved hjelp <link> nederst på siden, så det er best å ikke bruke det.

Unngå å bruke nettleser Spesifikke funksjoner

Filter: Bruk av filter øker minneforbruket og brukes per element, ikke per bilde, så problemet er multiplisert. Også Filtre er IE Proprietary, vil derfor ikke fungere som tiltenkt i andre nettlesere. Hvis du ønsker gjennomsiktige eller gradient bakgrunn, bruk 1Pixel med bilder.
Uttrykk: CSS uttrykk er en fin funksjon å ha i CSS, men likevel er IE spesifikk funksjon. Dessuten er det viktig å merke seg at disse uttrykkene er evaluert når siden gjengis og endres, rullet og selv når brukeren beveger musen over siden. Unødvendig å si dette kan påvirke ytelsen til siden din. Derav i enkle ord, unngå å bruke CSS uttrykk, med mindre du føler deg sine argumenter 'veier mer enn sine cons'

Externalise du CSS

Bruke ekstern CSS vil resultere i raskere lasting av sider fordi JavaScript og CSS-filer er hurtigbufret av nettleseren. Inline CSS i HTML-dokumenter blir lastet ned hver gang HTML-dokument blir forespurt. Dette kan faktisk redusere antallet HTTP-forespørsler gjort, men det senere øker størrelsen på HTML-dokumentet. Ekstern CSS bufres av nettleseren, størrelsen på HTML-dokumentet er redusert uten å øke antallet HTTP-forespørsler.

Vær oppmerksom på at dersom brukerne på nettstedet ditt har flere sidevisninger per sesjon og mange av sidene bruke de samme skript og stilark, er det en større potensiell nytte bufrede eksterne filer.

Pakk Din CSS fil

Pakking eller knaser din CSS er praksisen med å fjerne unødvendige tegn fra kode for å redusere størrelsen og dermed forbedre lastetider.

CSS kan jeg knaste ved å fjerne alle kommentarer og eventuelle uønskede tegn som mellomrom, linjeskift etc.

For aldre, har jeg tenkt å konsolidere alle gode rutiner, har jeg lest alle nå og da. Endelig! Jeg fikk ned å sette den i pennen. Jeg innså at det kommer til å være mammut oppgave å skape dette mammut dokumentet, så jeg bestemte meg for å dedikere en hel kategori til det, så jeg kunne fortsette å legge ting om beste praksis som og når jeg møter dem ...

Vel! innholdet her vil være en sammenslåing av mine personlige UI utviklingen Best Practices med de som er skrevet av standard utviklerne som Yahoo, Google etc.

Se denne plassen og holde browing det Best Practices Kategori

Enkelt sett (for dem som aldri har hørt om doctype før i dag)! DOCTYPE er erklæringen i et HTML-dokument som kommer før det <HTML> koden, ser at noe som dette (limt inn fra kilden til denne meget side)

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Derfor løsning på dette problemet var å

• tillate webutviklere som kjente sine standarder å velge hvilken modus som skal brukes.
• fortsette med gamle sider i henhold til de gamle (quirks) regler.

Og DOCTYPE ble født.

Så, basert på om du side er utformet til standarder eller ikke, velger du riktig doctype.

Gamle sider skrevet før disse standardene ble innført ikke har en DOCTYPE. Derfor når det ikke er DOCTYPE i HTML din da nettleseren er i quirks-modus.
Men hvis DOCTYPE er definert som ett av følgende, da nettleseren sies å være i streng modus.

<DOCTYPE html PUBLIC "- / / W3C / / DTD HTML 4.01 Transitional / / EN" "http://www.w3.org/TR/html4/loose.dtd">