Her er en oppsummering av flere måter å bedre ytelsen på nettsteder som ligger på våre webservere.
Generelle tips
- Bruk små filer. Ikke alle har tipp-topp Internett-forbindelse. Selv når ting går fort for deg, så kan det gå tregt for andre.
- Ikke bruk WIDTH- og HEIGHT-attributtene for IMG SRC til å endre størrelsen på dine bilder. Lag istedenfor småbilder på forhånd, og bruk A HREF til å lenke til det større bildet hvis du vil at dine besøkende skal se det.
- Test visningshastighet med en netbook (liten, treg laptop).
- Test visningshastighet med en mobiltelefon uten høyhastighetsnett.
- Husk at Flash og PDF ofte er brukt til spredning av virus, spionprogramvare og annen skadelig programvare, og i tillegg kan være tyngre å laste for din besøkendes nettleser, spesielt for små og håndholdte dingser. Bruk HTML og CSS istedenfor.
- Minimaliser bruken av eksternt innhold (bilder, annonser, Flash, filmer, osv.). "Eksternt" betyr innhold du henter/laster fra andre steder på nettet for visning på din webside.
- Tillegg, utvidelser, moduler, stiltemaer, plugins o.l. (add-ons, extensions, modules, themes, plugins) kan gjøre websidene dine tregere. Noen programmer, f.eks. Joomla, blir tregere bare ved at disse er installert, selv om de ikke er aktivert.
Verktøy på egen datamaskin
Alle som jobber med ytelse på websider bør teste sine nettsteder med flere forskjellige nettlesere, og gjerne med mobiltelefon tilkoblet med mobildata (ikke WLAN). Følgende nettlesere bør testes på egen datamaskin:
- Firefox (Linux, Mac, Windows)
- Google Chrome (Linux, Mac, Windows)
- Internet Explorer (Windows)
- Opera (Linux, Mac, Windows)
- Safari (Mac, Windows)
Til testingen anbefaler vi at du bruker nettlesertillegg som lar deg se på ressursbruken. Google Chrome (View->Developer->Developer Tools), Opera (Tools->Advanced->Opera Dragonfly) og Safari (Develop->Show Web Inspector) kommer med slike tillegg innebygget, men du kan bli nødt til å aktivere disse spesifikt. Sjekk dokumentasjonen.
Til Firefox anbefaler vi at man bruker begge følgende tillegg:
PHP og CGI i lenker og includes
Når vi skriver om PHP i punktene nedenfor, så gjelder prinsippene også for CGI, siden virkemåten er tilsvarende.
På våre webservere kjører PHP som CGI under suphp. PHP-websider og -script kjører derfor som separate prosesser for hver forespørsel via web, med din Unix-brukers (FTP-brukernavns) rettigheter. Disse prosessene avsluttes når websiden er ferdig lastet, og verken koden eller resultatet lagres i webserveren.
Dette medfører akseptabel sikkerhet, men ofrer litt ytelse. Du bør derfor unngå noen typiske programmeringsteknikker for "akselerasjon" og "caching" gjennom PHP, som simpelthen ikke fungerer. I verste fall kan du støte på webserverens selvforsvarsmekanisme, som trår til når websidene prøver å laste for mange samtidige elementer, sider og script.
- Bilder bør alltid lastes statisk med
<IMG SRC="/mappe/med/bilde_4711.png">
og ikke via et PHP-/CGI-script, f.eks. <IMG SRC="/mappe/med/bilde_viser.php?bilde=4711.png">
Tilsvarende: lag småbilder på forhånd når du laster originalene opp til serveren, ikke generer de hver gang de skal vises fram.
- CSS og JavaScript bør av samme grunner også lastes fra statiske filer, ikke PHP.
- Komprimering av innhold bør gjøres før det lastes opp til serveren, ikke via PHP. Hvis du kjenner til hvordan du skrur på og bruker ob_gzhandler, så er det et unntak fra regelen.
- Ikke mellomlagre (cache) innhold i PHP-filer, lagre heller til statisk HTML.
Bra: <a href="/cache/1/1a/1a23bsadf.html">Cachet dokument</a>
Også bra: cache informasjonen i MySQL-databasen din.
Dårlig: <a href="/cache/1/1a/1a23bsadf.php">Cachet dokument</a>
- Ikke bruk include(), include_once(), require() eller require_once() med absolutte URLer. Bruk relative referanser istedenfor.
Bra kode: include("/includes/myinclude.php") Dårlig kode: include("http://www.example.com/includes/myinclude.php") Det ovenstående starter en ny PHP-prosess for hver include(), og vil gjøre at dine websider går vesentlig tregere.
- Forsøk å unngå bruk av cookies og sesjoner der du ikke må ha de. Det gjør at våre servere kan mellomlagre statisk informasjon fra en bruker til neste.
Databasebruk
- Koble deg til databasen maks en gang per sidevisning.
- Spesifiser de kolonnene du trenger data fra, f.eks.:
SELECT etternavn, fornavn, sted FROM folk;
Unngå den generelle SELECT * FROM folk;
hvis du ikke trenger alle kolonnene.
- Tabeller som oppdateres og spørres ofte vil kunne gå tregt med MyISAM-motoren, vurder å bytte til InnoDB:
ALTER TABLE folk ENGINE innodb;
- Tabeller hvor det har vært slettet ganske mye data, eller utført mye endringer i felter av typen varchar, varbinary, blob eller text, bør regelmessig optimaliseres. For tabellen "folk" kan det gjøres med denne SQL-kommandoen:
OPTIMIZE TABLE folk;
- Se også MySQL-dokumentasjonens kapittel om optimalisering. Husk at du ikke kan gjøre ting som krever systemtilgang eller
SUPER-privilegier.
WordPress
Ikke bruk TimThumb eller liknende løsninger for bilder, de bryter med første punkt i listen ovenfor ("PHP og CGI i lenker og includes"). WordPress-utviklere anbefaler å bruke innebygde funksjoner for thumbnails, som også har flere funksjonelle fordeler sammenliknet med TimThumb o.l.
For Wordpress med mye trafikk eller store websider bør du evt. vurdere utvidelsen WP Super Cache. Det er svært viktig at denne konfigureres til å bruke metode 1, mod_rewrite. Metode 2 og 3 forbedrer ikke ytelsen på webhotell hos oss.
Admin-sidene til Wordpress er ofte trege dersom du har flere tillegg installert, siden det er vanlig at de kontakter leverandøren for å se etter oppdateringer. Dette er en feature, ikke en bug, men vurder gjerne å fjerne tillegg som du ikke bruker.
Eksempler
De nedenstående eksemplene bruker skjermbilder fra Chrome 8. I Chrome 9 og nyere velger man panelet "Network" istedenfor "Resources", men ellers er bruk og tolkning lik. Du kan lese mer om dette på Google Chrome utvikler-websidene.
www.vg.no
Først ser vi på et eksempel fra www.vg.no via vår 1 Gbps-linje, nedlastingstiden vil være lengre på tregere linjer:
www.vg.no laster innhold fra flere kilder, blant annet andre servere hos VG, og f.eks. ekstern leverandør midasplayer.com. Dette ser stort sett ut til å gå raskt, men lasting av eksternt innhold og innhold fra andre servere kunne gjort at sidelasting gikk tregere. Hvis vi hadde sett lenger ned i listen av lastede elementers ressursbruk, så ville vi sett hva det er som utgjør det siste sekundet av tidsbruken.
Domeneshop SOS
Og her er tilsvarende eksempel for det punktet i våre spørsmål og svar som du ser på nå:
Som du ser, er faq hovedsakelig ressursbegrenset av selve CGI-scriptet, mens bildelasting går raskt. En eventuell forbedring må da ligge i optimalisering i koden i selve faq.
kundeservice
03333 (åpent)
