Reducer serverens svartid – Google Pagespeed Insights – Læs og lær del 2

Google Pagespeed Insights slår rimelig hårdt ned på dårlige svartider, og dette har jeg fuld forståelse for. Men hvorfor, og hvad er det egentlig der gør at man har en langsom svartid?

Hvad er svartid (responce time)

Svartid er den tid der går fra du har spurgt efter et website, til du modtager det første tegn i dokumentet. Også kaldet Responce time eller TTFB (Time to first byte).

Det siger lidt sig selv, at jo hurtigere denne er,  jo hurtigere kommer browseren i gang med at fortolke det der er på hjemmesiden. Eller sagt på en anden måde. Jo hurtigere kommer browseren i gang med at hente yderligere data som fx billeder, css og javascriptfiler.

Hvad kan man gøre for at nedbringe svartiden?

At reducere serverens svartid eller responce time, kræver først og fremmest teknisk snilde.

Ja man kan selvfølgelig bare smide noget HTML caching på, eller en anden form for cache på, men vil man nogen vegne og vil man gerne at sidens svartid er hurtigere også selvom det er et AJAX kald,en dynamisk side eller måske checkud sider – og det vil man selvfølgelig – så skal man altså ned og grave lidt i serverside koden, kald til databasen, databaseoptimeringer, serveroptimeringer etc.

Dette er fordi, nogle af grundene til mange sider har en lang svartid er enten at:

• Serversidekoden er dårligt skrevet eller der er brugt langsomme alternativer.
• Databasen er fyldt med skrammel, roddet eller mangler anden optimering.
• Databasekald er langsomme.
• Serveren er langsom eller forkert sat op.
• Eller selvfølgelig en kombi af punkterne ovenfor

Nogen vil sikkert tænke, jammen der er jo også andre grunde til at svartiden er langsom. Og ja, det er der, men det kommer jeg ind på senere.

I Google PageSpeed Insights, er en god svartid på under 200ms, hvilket jeg er meget enig i, men det kan være utrolig svært at opnå ved optimeringer af ovenstående, og det kan være en ret bekostelig omgang. Men prøv at forestille dig hvis du kan få svartiden ret langt ned ved at optimere på ovenstående, så er du kommet ret langt i kampen og vil uden tvivl få en langt mere stabil hjemmeside som ikke bukker under for hvad som helst.

Hvor meget du kan skære i svartiden, kommer reelt an på hvor langsom den svartid er, og hvor fejlene ligger og hvad for nogle fejl der er tale om.

Hvordan nedbringer man svartiden?

Jo det er som skrevet lidt mere nørdet end mange andre tiltag. Det gode er at man kan opnå ret meget ved at nedbringe dette tid.

• Tjek og test forskellige versioner af fx PHP.
  – Det er bevist at skifter man fx fra PHP 5.3 -> 5.4 kan man opnå op imod dobbelt så hurtig rendering. Der er ikke lige så stort spring fra 5.4 -> 5.6, men køre du stadig 5.3 så er det bare om at få skiftet. husk også at få dit site klar til PHP7, for der opnår du yderligere forbedringer.
  – Det fjerner dog ikke eventuelle problemer i koden eller databasen, men kan reducere både svartid og forbrug af RAM og CPU
• Databasen og kald/skrivninger
  – Tjek kald til databasen, om de er langsomme eller hurtige, om de kan forbedres eller skal laves om. I denne forbindelse skal du også se på om databasen i sig selv er optimeret, altså om der fx er de rette indexes.
• Kodefejl og forbedringer
  – Tjek koden for fejl og steder hvor man kan forbedre. Her tænker jeg Temaet, plugins som man kan indbygge i temaet på en bedre måde, kodestumper der kan skrives anderledes og bedre etc.
• Se på Temaet
  – Er der noget folk gør tit, så er det at vælge at tage udgangspunkt i temaer, det gør jeg også selv. Men valget for de fleste er ret tit, måske også for dig, at tage udgangspunkt i et tema der kan det det skal kunne og meget mere til, for hvad nu hvis man kunne få brug for det. Det er den forkerte indgangsvinkel, i hvert fald når vi snakker hastighed. I stedet skal du tage udgangspunkt i et tema som faktisk ikke kan ret meget andet end at lave dig en hjemmeside med noget indhold, og så bygge ud derfra.
• Se på plugins og moduler
  – For alle Open Source Løsninger, er der udviklet et eller flere plugins/moduler. Mange installerer plugins som de kun lige skal bruge en eller to gange, for derefter bare at lade dem være som de er, nemlig installeret og aktive. Gør dig selv den tjeneste at gennemgå dine plugins i ny og næ, fjern dem du ikke bruger.
• Nyt webhotel
  – Kan du ikke nedbringe tiden nok, kan du også skifte til et bedre og hurtigere webhotel. Men start altid med at optimere selve koden, da selv det bedste webhotel kan gå ned hvis koden ikke er optimeret.
• Caching af HTML (HTML caching)
  – at cache sine sider, giver god mening, og det er da også den billigste måde at nedbringe responce time (svartiden). Men det der sker her er at sider bliver gjort statiske, så sider der er højt dynamiske eller bare kræver at være forskellig fra bruger til bruger, vil stadig være mærket af dårlige svartider. Det kan fx være i cart og checkout hvor hastighed er endnu mere vigtigt. Men har du en 100% statisk side så smæk caching på.

Værktøjer du bør se på og bruge i denne forbindelse:

 

WordPress

Find Querys og funktioner som køre langsomt
https://wordpress.org/plugins/query-monitor/

Find plugins som køre langsomt
https://wordpress.org/plugins/p3-profiler/

Test af PHP kode

http://xdebug.org/ sammen med fx http://sourceforge.net/projects/wincachegrind/ skaber et godt udgangspunkt for at se hvor koden køre langsomt. kør på intern server som fx WampServer som allerede har xDebug.

Generelt

Pingdom Tools
http://tools.pingdom.com/fpt/

Når du tester dit site, gør det med ?test=1 i enden af urlen, sådan at du omgås eventuelle cache plugins, eller cache på serveren. Skift gerne tallet ud hver gang du laver en test.

<– Tilbage til del 1 som omhandler Google Pagespeed insights på generelt plan