Udtrykke det

Medtag JavaScripts i bunden af ​​HTML dokument

Hvis du ikke har document.write (eller nogen dynamisk generering af sideindhold ved hjælp af javascripts) for at indsætte en del af sidens indhold i dine scripts, flytte scriptet omfatter redegørelse til bunden af ​​siden, inden udgangen af ​​body-tagget.
Den HTTP/1.1 specifikationer tyder på, at browsere downloade ikke mere end to komponenter i parallel pr værtsnavn. Hvis du tjener dine billeder fra flere værtsnavne, kan du få mere end to downloads at forekomme i parallel. Mens et script der downloader, men vil browseren ikke starte andre downloads, selv på forskellige værtsnavne.
Der er også måder at dynamisk Opret script noder og indlæse eksterne scripts, efter siden er indlæst ved hjælp af AJAX.

Eksternalisere du JavaScripts

Brug af eksterne JavaScript-filer vil resultere i hurtigere indlæsning af sider, fordi de JavaScript-filer er cached af browseren. Inline JavaScripts "i HTML-dokumenter bliver hentet hver gang HTML dokument der anmodes om. Dette kan faktisk reducere antallet af HTTP-forespørgsler der foretages, men det efterfølgende øger størrelsen på HTML-dokumentet. Ekstern JavaScripts er cached af browseren, størrelsen af ​​HTML-dokumentet er reduceret uden at øge antallet af HTTP-anmodninger.
Bemærk venligst, at hvis brugerne på dit websted har flere sidevisninger per besøg, og mange af dine sider genbruge de samme scripts og stylesheets, er der et større potentiale gavn af cachede eksterne filer.

Pak dine JavaScript-filer

I tilfælde af JavaScripts, i modsætning til CSS kan filerne knasede bruge nogle standard algoritmer, der vil give en reduceret filstørrelse end blot at fjerne mellemrum eller faner. Et eksempel på javascript pakker kan findes her http://dean.edwards.name/packer/

Slip af genparten Scripts

Det er meget usædvanligt, at hele scripts kan duplikeres, men en gennemgang af de ti bedste amerikanske hjemmesider viser, at to af dem indeholder et duplikeret script. Duplicate scripts men naturligvis reducerer ydeevnen ved at skabe unødvendige HTTP-anmodninger og spildt JavaScript udførelse.
Også i mange tilfælde, selvom scripts navnene er forskellige, er der en sandsynlighed for identiske scripts inden for samme side som følge af holdet størrelse og antal af scripts.

Minimer adgang DOM elementer hvor det er muligt

Adgang til DOM elementer med JavaScript er langsom, så for at få en mere lydhør side, skal du:
• Cache henvisninger til adgang til elementer
• Opdater knuder "offline" og derefter tilføje dem til træet
• Undgå fastsættelse layout med JavaScript

Separat opførsel fra indhold og præsentation

Ligesom vi separat præsentation (CSS / XSLT) fra Indhold (XHTML / XML), bør vi også adskille Behavior (Javascript). Dette kaldes diskret Javascript. Ligesom vi linke til eksterne CSS-filer, skal vi linke til eksterne JavaScript-filer.

I stedet for hård kodning adfærd i indhold (f.eks onmouseover, onclick, etc.), bør adfærd kan dynamisk tilføjes elementer, klasser, og unikke elementer (IDS) ved hjælp af DOM. Det grundlæggende dokument, indhold, må kun indeholde gyldig XHTML / XML og ikke javascript.
Javascript bør forøge indholdet ved tilsætning adfærd. Indholdet bør forblive nyttigt og brugbart uden javascript (eller uden fuld understøttelse af JavaScript).

Jeg har gemt denne artikel aldre tilbage, så Undskyld! I dont huske kilden ... men det syntes nyttigt for os, der skal være klar over publikum, for hvem vi udvikler stedet for ... så her jeg er

Page vægt kan bruges til at bestemme download-tiden for en given side på en række internetforbindelsesindstillinger hastigheder. Som eksempel viser følgende tabel de download-tider for tre forskellige sider i en række populære opkoblingshastigheder.

Fordele ved at reducere side vægt?

De positive virkninger af at reducere side vægt til gavn for både webstedsejere og forbrugere. Potentielle fordele kan nævnes:

1. Sider indlæses hurtigere. Den mest åbenlyse konsekvenser af at reducere side vægt er, at din hjemmesides sider vil loade hurtigere for besøgende, uanset forbindelsens hastighed.
2. Lavere sideindlæsningstid skabe mere komfortable besøgende. Besøgende er mindre tilbøjelige til at blive frustreret og gå andre steder, hvis dine sider indlæses hurtigt. På den anden side er langsom-loading sider en af ​​de sikreste måder at miste besøgende og potentielle kunder.
3. Hurtigere load-tider vil bidrage til øget konvertering. Flere besøgende vil blive på dit websted længere. Flere af dem vil ende med at gøre indkøb, tilmelding til dit nyhedsbrev, eller en bog-mærkning dit websted.
4. Dit brand opfattelse vil blive styrket. Tilbagevendende kunder og første gang besøgende både vil være mere tilbøjelige til at beskrive dit websted (og virksomheder) som "professionel", hvis dine sider indlæses hurtigt.
5. Sider med ren, solid kode vil ofte blive indekseret mere effektivt af naturlige søgemaskiner.
6. Sider optimeret til vægt kan faktisk spare båndbredde afgifter på stærkt trafikerede steder. 100.000 sider hver vejer 150 Kb vil kræve dobbelt så meget båndbredde fra din internetudbyder end 100.000 sider hver vægt 75 Kb. For internetudbydere at opkræve for brugte båndbredde eller Overskud, kan denne reduktion medføre betydelige besparelser på båndbredde afgifter.

Overvej følgende data, der blev offentliggjort i en rapport

Sæt Stylesheets på toppen

Hvis du ønsker en side til at indlæse gradvis, at der er, vi ønsker browseren til at vise det indhold, det er så hurtigt som muligt, sætte CSS øverst på siden inde i dokumentet HEAD. Dette gør sider synes at være lastning hurtigere, da dette letter progressiv destruktion af siden. Dette er især vigtigt for sider med masser af indhold og for brugere på langsomme internetforbindelser.

Det er et dokumenteret faktum, at for at forbedre den overordnede brugeroplevelse, er det vigtigt at give fremskridtsindikatorer og visuelle feedbacks. For at undgå at skulle tegne elementer på siden, i tilfælde, hvis deres stilarter forandring, nogle browsere, herunder IE, blokerer udgave af siden, indtil CSS er fuldt lastet. På grund af dette, bliver brugeren at se en tom hvid side.

W3 HTML Specifikationer 'også, at CSS skal jeg medtage i HEAD del af HTML-side. at the bottom of the page, so it's best not to use it. Bemærk også, at I IE @import opfører sig på samme som at bruge <link> nederst på siden, så det er bedst ikke at bruge det.

Undgå at bruge Browser Specifikke træk

Filtre: Brug af filter øger hukommelsen forbrug og anvendes pr element, ikke pr billede, så problemet er mangedoblet. Også Filtre er IE Proprietary, vil derfor ikke virke efter hensigten i andre browsere. Hvis du vil have gennemsigtige eller gradient baggrunde, skal du bruge 1Pixel med billeder.
Udtryk: CSS udtryk er en god egenskab at have i CSS, men stadig er IE bestemt funktion. Det er også vigtigt at bemærke, at disse udtryk er evalueret, når siden gengives, og størrelse, rullet og selv når brugeren bevæger musen hen over siden. Det er overflødigt at sige det kan påvirke ydeevnen af ​​din side. Derfor har man i enkle ord, Undgå at bruge CSS udtryk, medmindre du føler sine fordele "vejer mere end sine ulemper"

Eksternalisere du CSS

Brug af ekstern CSS vil resultere i hurtigere indlæsning af sider, fordi JavaScript-og CSS-filer er cached af browseren. Inline CSS i HTML-dokumenter bliver hentet hver gang HTML dokument der anmodes om. Dette kan faktisk reducere antallet af HTTP-forespørgsler der foretages, men det efterfølgende øger størrelsen på HTML-dokumentet. Ekstern CSS er cached af browseren, størrelsen af ​​HTML-dokumentet er reduceret uden at øge antallet af HTTP-anmodninger.

Bemærk venligst, at hvis brugerne på dit websted har flere sidevisninger per besøg, og mange af dine sider genbruge de samme scripts og stylesheets, er der et større potentiale gavn af cachede eksterne filer.

Pak din CSS fil

Pakning eller crunching din CSS er den praksis at fjerne unødvendige tegn fra kode for at reducere dens størrelse og dermed forbedre load tider.

CSS kan jeg kværnet ved at fjerne alle de kommentarer og eventuelle uønskede tegn som hvide rum, flere linjer osv.

For aldre, har jeg tænkt at konsolidere alle de bedste praksis, har jeg læst alle nu og da. Endelig! Jeg fik ned for at sætte det til pen. Jeg indså, at det bliver kæmpeopgave at skabe denne mammut dokument, så jeg besluttede at dedikere en hel kategori til det, så jeg kunne holde tilføje ting om bedste praksis, som og når jeg støder på dem ...

Nå! indholdet her vil være en sammensmeltning af mine personlige UI udvikling Best Practices med dem, skrevet af standard udviklere som Yahoo, Google etc.

Se dette rum og holde browing den bedste praksis kategori

Enkel speaking (for dem, der aldrig har hørt om doctype før i dag)! DOCTYPE er erklæringen i et HTML-dokument, der kommer før <HTML> tag, der ser noget som dette (indsat 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 problem var at

• give web-udviklere, der kendte deres standarder at vælge hvilken tilstand til at bruge.
• fortsætte med at vise gamle sider i henhold til de gamle (særheder) regler.

Og DOCTYPE blev født.

Så baseret på, om din side er designet til standarder eller ej, kan du vælge den relevante doctype.

Gamle sider skrevet før disse standarder blev indført ikke har en doctype. Derfor, når der ikke er nogen DOCTYPE i din HTML så browseren er i Quirks tilstand.
Men hvis DOCTYPE er defineret som en af de følgende, derefter browseren siges at være strengt tilstand.

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