WN - Optimering för snabba hemsidor

WN (https://www.wn.se/forum/index.php)

- Klientsidans teknologier, design och grafik (https://www.wn.se/forum/forumdisplay.php?f=12)

- - Optimering för snabba hemsidor (https://www.wn.se/forum/showthread.php?t=16391)

El bueno

2006-09-22 05:58

Tjena håller på att utveckla en hemsida och nu undrar jag om det finns någon typ 10 punktslista för att optimera sin sida så att den blir så snabb som möjligt?

Avskyr sega sidor och det vet jag att ni också gör ;)

Med vänliga hälsningar

Micke_

2006-09-22 08:21

Jag har ingen top-tio lista men jag kan dela med mig av några tips.

* Snabb grafik- eller så lite grafik som möjligt. Dett är ju ett kapitel för dig hur man komprimerar grafik effektivast. En tumregel är ju att man ska undvika toningar vilket är svårt att komprimera så att det ser bra ut.

* Så få HTTP requests som möjligt - man ska hålla ner antalet css-filer, javascript-filer, php-includes, grafik med mera.

* snabb webbserver - såklart

* optimerad databas(om man jobbar med det) - detta är ju också ett kapitel för sig hur man designar och optimerar en databas på bästa sätt.

denna lista går säkert att bygga på

DeSoto

2006-09-22 08:24

Tja, det finns väl några saker att tänka på.

* Använd inte bilder som lika gärna kunde ha varit ren text.
* Försök göra grafik med CSS så mycket så möjligt istället för bilder. Använd t.ex. border i CSS för att skapa kantlinjer istället för att ha bilder som kantlinjer.
* Gör dina layout-bilder så små som möjligt. Oftast räcker det med en bild till vänsterkanten, en en-pixel-smal bild som loopas i mitten och en bild till högerkanten.
* Använd cache så mycket det går.
* Generera .html-filer för sidor som sällan uppdateras. När de sidorna sen uppdateras, så skickar du en header om att de har uppdaterats.
* Separera utssende och struktur, dvs, använd XHTML och CSS på korrekt sätt.
* Lägg CSS och Javascript i egna filer. Undvik att använda inline CSS i mesta möjliga mån.
* Avinstallera Dreamweaver och Frontpage.
* Utnyttja SQL så mycket det går. Oftast kan beräkningar och stränghantering göras redan i SQL.
* Se till att du bemästrar ditt server-side-språk så bra som möjligt. Är du osäker, anlita någon som kan optimera din kod.
* Se till att din förstasida är ruggigt snabbladdad. Kommer någon in på din förstasida och blir intresserad, så känns det mer okej att en undersida är aningen långsammare än ifall förstasidan är långsam.

MRDJ	2006-09-22 09:49

mitt tips

databas:
* Om du kör en databas, lägg upp Index! detta är det absolut viktigaste!
det kan gå upp till 100 gånger snabbare med rätt index!

* ha så lite sql-frågor per sida som det går.. använd inner joins t.ex

design:
* Kör CSS! så mycket det bara går.

mersault

2006-09-22 09:51

Instämmer med föregående talare och lägger till
* Slå på gzip-komprimering av sidorna!
* Analysera sidan på http://www.websiteoptimization.com/s...yze/index.html (tro inte på allt de säger, men det kan vara en fingervisning till om du lyckats bra.)

Timofey

2006-09-22 10:39

Tack för era tips om Gzip! Slog på det och nu laddar sidorna mycket snabbare!
Kan någon förklara Hur Gzip compressionen fungerar? Komprimeras sidorna ungefär som vanliga zip-arkiver på servern och skickas till besökaren?

mersault

2006-09-22 11:36

alltinggratis>> Jeppm kort sagt! Bara de webbläsare som klarar av det (nuförtiden typ alla...) får komprimerat material, de andra får okomprimerat.
Det är inbyggt i HTTP 1.1- protokollet (Content-encoding). Servern skickar komprimerat data och webläsaren packar upp det.

Henrik Nygren

2006-09-22 18:34

Citat:

Originally posted by DeSoto@Sep 22 2006, 08:24
Tja, det finns väl några saker att tänka på.
(...)
* Avinstallera Dreamweaver och Frontpage.
* Utnyttja SQL så mycket det går. Oftast kan beräkningar och stränghantering göras redan i SQL.
(...)

Varför avinstallera Dreamweacer? Programmet blandar iaf inte in någon smutskod som frontpage säkerligen gör.

Tar SQL mindre serverresurs än php?

El bueno

2006-09-22 20:13

Vad innebär Gzip? Låter intressant och skulle vilja ha en liten närmre förklaring.....

thorsell

2006-09-22 21:22

Fungera gzip med php också? Alltså den färdiggenerarade html-sidan (tillverkad av php), kan den gzip:as?

Innocast

2006-09-22 22:02

Avskaffa Apache och skaffa thttpd eller liknande!

Innocast

2006-09-22 22:03

Citat:

Originally posted by thorsell@Sep 22 2006, 21:22
Fungera gzip med php också? Alltså den färdiggenerarade html-sidan (tillverkad av php), kan den gzip:as?

Kod:

if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) ob_start("ob_gzhandler");

längst upp i dokumentet... blir grymt bra textkomprimering och man sparar bandbredd och laddtid

thorsell

2006-09-22 22:56

Citat:

Ursprungligen postat av tech24

Citat:

Ursprungligen postat av thorsell

Fungera gzip med php också? Alltså den färdiggenerarade html-sidan (tillverkad av php), kan den gzip:as?

Kod:

if substr_count_SERVERHTTP_ACCEPT_ENCODING, gzip ob_startob_gzhandler;

längst upp i dokumentet... blir grymt bra textkomprimering och man sparar bandbredd och laddtid

Behövs någon avslutning på det? typ ob_end_flush(); i slutet av php-dokumentet?

iXam	2006-09-22 23:27

Tänk på att det tar extra processortid att komprimmera.
På en tom webserver där man utvecklar sidan kanske det verkar snabbare men när ni har 100 besökare i sekunden *kanske* det inte blir snabbare.
Här måste man alltså testa. En lätt förstasida med några 100 byte htmlkod kanske inte är lämplig att dynamiskt komprimera men en sökresultatsida på 100KB kanske absolut det.
Sen får man även väga CPU-kostnad vs. bandbreddskostnad.

Är ens arbetsverktyg apache,php och MySQL så är det google och experimentera sig fram som gäller. Finns otroligt många lager mellan serverns CPU och klientens CPU att optimera (hårdvara,OS,programvarukonfigurering,kompilerings alternativ osv.). Att blint säga "index är lösningen" kan vara lika fel som det ibland kan vara rätt.
Att sätta index på en column där det endast kan förekomma två olika värden kan vara ett fel. MySQL 5.1 kan optimerar detta problemet med partitionering.

Seattlegrunge

2006-09-23 03:28

Testade följande kodsnutt allra överst på några php-sidor jag pillar med nu:

Kod:

if substr_count_SERVERHTTP_ACCEPT_ENCODING, gzip ob_startob_gzhandler;

Det fungerar klockrent på min utvecklingsserver. Men när jag testade på skarpa servern så fick jag följande fel:

Kod:

Notice: Undefined index: HTTP_ACCEPT_ENCODING in W:\xxx\yyy\zzz\demo\functions.php on line 2



Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at W:\xxx\yyy\zzz\demo\functions.php:2) in W:\xxx\yyy\zzz\demo\functions.php on line 4



Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at W:\xxx\yyy\zzz\demo\functions.php:2) in W:\xxx\yyy\zzz\demo\functions.php on line 4

Varför fungerar det på ena servern, men inte andra.
Utvecklingsservern är IIS 6 och skarpa servern är IIS 5.
Är det nåt jag måste fixa i php.ini tro? Båda servrarna kör näst intill allra senaste versionen av php.

DeSoto

2006-09-23 10:24

Citat:

Ursprungligen postat av Henrik Nygren

Citat:

Ursprungligen postat av DeSoto

Tja, det finns väl några saker att tänka på.
(...)
* Avinstallera Dreamweaver och Frontpage.
* Utnyttja SQL så mycket det går. Oftast kan beräkningar och stränghantering göras redan i SQL.
(...)

Varför avinstallera Dreamweacer? Programmet blandar iaf inte in någon smutskod som frontpage säkerligen gör.
Tar SQL mindre serverresurs än php?

Dreamweaver producerar smutskod. Inlines styles och onödiga taggar. Visst, håller med om att det helt klart är bättre än FrontPage, men kan man undvika DW, så bör man göra det.

Det jag menade med att låta SQL göra jobbet var inte bara att göra simpla konkateneringar, utan att använda t.ex. COUNT(), SUM() etc. istället för att loopa igenom ett dataset och göra beräkningen med ett serverside-språk.

Henrik Nygren

2006-09-23 12:11

Citat:

Ursprungligen postat av DeSoto

Citat:

Originally posted by -Henrik Nygren@Sep 22 2006, 18:34

Citat:

Ursprungligen postat av DeSoto

Tja, det finns väl några saker att tänka på.
(...)
* Avinstallera Dreamweaver och Frontpage.
* Utnyttja SQL så mycket det går. Oftast kan beräkningar och stränghantering göras redan i SQL.
(...)

Varför avinstallera Dreamweacer? Programmet blandar iaf inte in någon smutskod som frontpage säkerligen gör.
Tar SQL mindre serverresurs än php?

Dreamweaver producerar smutskod. Inlines styles och onödiga taggar. Visst, håller med om att det helt klart är bättre än FrontPage, men kan man undvika DW, så bör man göra det.
Det jag menade med att låta SQL göra jobbet var inte bara att göra simpla konkateneringar, utan att använda t.ex. COUNT(), SUM() etc. istället för att loopa igenom ett dataset och göra beräkningen med ett serverside-språk.

Hmm, eftersom jag jobbar i Code Mode hela tiden i DW så borde väl ingen smutskod smita in?

Kaffe

2006-09-23 13:24

Citat:

Originally posted by DeSoto@Sep 23 2006, 10:24
Dreamweaver producerar smutskod. Inlines styles och onödiga taggar. Visst, håller med om att det helt klart är bättre än FrontPage, men kan man undvika DW, så bör man göra det.

Man bör undvika WYSIWYG, inte specifikt Dreamweaver eller Frontpage.

Jag kan hålla med att om man sedan enbart arbetar i kodläget i Dreamweaver så finns det ju billigare alternativ att tillgå. Men har man väl införskaffat (vi förutsätter att man varit legal och köpt programvara) så kan man lika gärna använda den, för den är en utmärkt kod-editor.

DeSoto

2006-09-23 16:56

Citat:

Ursprungligen postat av Henrik Nygren

Citat:

Originally posted by -DeSoto@Sep 23 2006, 10:24

Citat:

Originally posted by -Henrik Nygren@Sep 22 2006, 18:34

Citat:

Ursprungligen postat av DeSoto

Tja, det finns väl några saker att tänka på.
(...)
* Avinstallera Dreamweaver och Frontpage.
* Utnyttja SQL så mycket det går. Oftast kan beräkningar och stränghantering göras redan i SQL.
(...)

Varför avinstallera Dreamweacer? Programmet blandar iaf inte in någon smutskod som frontpage säkerligen gör.
Tar SQL mindre serverresurs än php?

Dreamweaver producerar smutskod. Inlines styles och onödiga taggar. Visst, håller med om att det helt klart är bättre än FrontPage, men kan man undvika DW, så bör man göra det.
Det jag menade med att låta SQL göra jobbet var inte bara att göra simpla konkateneringar, utan att använda t.ex. COUNT(), SUM() etc. istället för att loopa igenom ett dataset och göra beräkningen med ett serverside-språk.

Hmm, eftersom jag jobbar i Code Mode hela tiden i DW så borde väl ingen smutskod smita in?

Det förstås, det kan ju vara trevligt att ha syntax highlightning. Jag menade dock bara ifall man enbart jobbar i designläge. :)

grazzy

2006-09-23 17:07

Det känns som att html-bloat är ett rätt litet problem om man kör med mod_gzip som packar upp till 80% ...

Peter_Holm

2006-09-25 08:24

Citat:

Originally posted by DeSoto@Sep 22 2006, 08:24

* Avinstallera Dreamweaver och Frontpage.

Sålänge man kör delad skärm med full kontroll på koden så är DW ett bra sätt att bygga html på. Men min DW MX2004 är lite dålig på att korrekt visa komplexa css-layouter. DW 8 ska vara bättre på det men jag väntar till DW9 innan jag uppgraderar min licens. :D

phict

2006-10-02 22:17

Jag skriver kompakt html och css för hand samt noga med optimerade databsaer med bra indexering.

Alla tider är GMT +2. Klockan är nu 08:45.