Bloggen her er skiftet fra Gigahost til Unoeuro

Jeg har skiftet server fra gigahost til unoeuro på bloggen her i dag.

Grunden? Unoeuro er gratis et år, pga deres 12års fødselsdag, så jeg tænkte at jeg ligeså godt kunne.

Jeg bruger Tools.pingdom til at måle hastigheden, til sverige. Og siden er sat op med WP Fastest cache samt Cloudflare.

Er Unoeuro hurtigere eller langsommere ?

Se selv, jeg har testet 3 sider før og efter. Det skal også siges at der nogen gange er meget stor forskel på forskellige servere inden for en host, det kan være jeg har være heldig eller uheldig.

Forsiden:

På gigahost:

bagnegaard gigahost

På unoeuro:
bagnegaard unoeuro

Forskellen er meget lille, og de besøgende mærker det i hvert fald ikke. Jeg ved ikke hvorfor Requests og page size er gået op og ned, det er sikkert fordi Unoeuro og gigahost understøtter forskellige cache ting, som er blevet aktiveret fordi jeg i forvejen havde plugins der kunne klare funktionerne.

Alle projekter siden:

På gigahost:

bagnegaard projecter gigahost

På Unoeuro:

bagnegaard projekter unoeuro

Igen er forskellen meget meget lille. Og loading tids forskellen er så lille at du ikke kan regne med at det er rigtigt, det kan ligeså godt være midlertidigt at Pingdom’s server var en smule langsommere.

Hurtig kode indlægget:

En af mine langsomeste sider er også den længste, sjovt nok 🙂

På gigahost:

bagnegaard kode gigahost

På unoeuro:

bagnegaard kode unoeuro

Forskellen er igen meget lille.

Konklusion:

Lad vær med at skifte fra et shared hosting sted til et andet, i håbet om at din side bliver meget hurtigere. Det hele handler om hurtig kode eller god cache.

Forskellen på disse 2 er meget lille, du skal hellere vælge host efter hvem der er gratis et år, eller hvem der har bedst support 🙂 Ellers så vælg en vildt hurtig host.

I følge unoeuro er min test forkert

De mener den kun tester min HTML kode og cloudflare, det er også rigtigt, jeg mener at testen er lavet så den viser hvad kunden ser, og at det ikke betyder meget for mig om den ene eller anden host er hurtigere, det har mere at gøre med hvordan brugeren oplever hastigheden.

Så jeg har lavet en test mere.

TTFB test

Denne gang har jeg lagt Gigahost siden på test.bagnegaard.dk og unoeuro siden på bagnegaard.dk.

TTFB betyder time to fist byte, denne hastighed er hvor langt tid serveren er om at sende den første del af siden, en byte, som er meget lidt. Testen viser, hvor meget tid der går med at slå serveren op, hvor meget tid serveren bruger på at sende dig det rigtige sted hen, hvor meget tid serveren bruger på at lave den side du skal have, også til sidst en lille del download.

Jeg bruger en service til det jeg ikke kender, den hedder bytecheck.com. Serveren de bruger er nok en Digital Ocean server som står i USA, det er i hvert fald hvad jeg har slået op.

Først Gigahost:

ttfb unoeuro

Så Unoeuro:

ttfb gigahost

Resultaterne skifter imellem 0,40-0,25 for begge, altså er der praktisk talt ingen forskel.

For at få servicen bytecheck.com til at virke hos unoeuro skal du sætte dette ind i din .htaccess fil, hvis du ikke har en .htaccess fil så opret en, alle FTP programmer kan oprette filer også skal den bare navn gives: .htaccess (husk det første .):

<IfModule security_module>
SecFilterEngine Off
</IfModule>

Hurtig kode! Forklaret ikke teknisk.

Hurtig kode er lækkert, fordi det giver en hurtigere hjemmeside for dine besøgende, og derfor også mindre stress til din server. Du kan læse lidt om en hurtig host her.

Men hvad er hurtig kode?

De fleste sider er i PHP, og PHP har en masse styrker, og svagheder, en af svaghederne er at det er langsomt. Hver bruger på en PHP server får sin egen side, altså når en bruger besøger en PHP side bliver siden lavet til den bruger.
Dette kræver en masse processor og ram af din server, 2 ting som de fleste servere ikke har.
Wordpress, Prestashop, Magento, Drupal, Facebook og stort set alle andre sider bruger PHP.

Men der er en masse måder at løse dette på. Dvs, der er en måde at løse dette på, det er Cache.
Cache på en PHP server er hvor man får serveren til at gemme en enkelt brugers side, og giver den til de næste brugere, det betyder at hver bruger ikke får deres egen side, men en genbestilt en af slagsen, så sætter man en indstilling, hvor længe denne version af side skal være aktiv, også genlaves siden når tiden er gået og der er en bruger som beder om siden igen.
Altså spare man en masse server tid, fordi server kun laver siden hver 24 timer, i stedet for hver gang den får et besøg.

Men cache kan tit ikke betale sig. Langt de fleste sider har ikke nok besøg til at cache kan betale sig. Fordi den første bruger på din side, skal både lave en side og samtidig lave den version alle andre brugere skal have, derfor er det første besøg på en cache-aktiv side, som ikke har taget cache endnu for det mindste halvt så hurtigt.

Se et eksempel fra Mackabler.dk her: 1,44 sek imod 0,51 sek. Det tager altså serveren 0,9sek længere, hvis cachen ikke er taget endnu.

Cache aktivt, Og der er lavet cache Cache aktivt, Men der er ikke lavet cache
Mac cache mack uden cacbe

Der er rigtigt mange sider som har cache på, men hvor stort set alle brugere ender med at bruge en masse tid på at lave en cache som ingen andre bruger.

Husk at alle dine sider har deres egen cache, altså indlæg fra 2008 som får et besøg hver måned bliver kun cache’et med den bruger.

Hurtige regler:
– Cache er noget man bruger når man har over 100 besøg/dag 🙂
– Cache der holder 24 timers er ikke for meget.

Så er der selve cacheen.

WordPress sider med mange plugins er tit langsomme, her er cache næsten et must, vær særligt opmærksom på indstillingerne hvis du har en webshop, Jeg er kommet til at caché kurven, så kun den føste bruger kunne købe noget 🙂

Jeg bruger WP Super Cache som er let at sætte op, men hvis du vil have mere styr på det, så er W3 Total Cache super fedt, det kræver en teknisk indsigt 🙂
Min makker taler rigtigt godt om WP Fastest Cache.

Prestashop kommer med en masse cache. Slå så meget som muligt til.

Jeg ved ikke en skid om andre CMS’er.

Browser cache

Browser cache er den cache som du beder dine brugeres internet browsere om at tager, her kan du fx bede dem om at tage backup af dine billeder i 5 dage, det betyder at dine brugere kan komme tilbage op til 5 dage efter og slippe for at downloade dine billeder igen.
Dette er rigtigt godt, da dine brugere tit kommer tilbage, og sider på den måde vil være ultra hurtig for dem.
Hvis din server har apache kan du skrive dette ind i htaccess filen, men ærligtalt, det er bygget ind i Cloudflare, som du burde bruger allerede.
Google PageSpeed Insights og Pingdom tool giver dig også noget bedre karakter hvis du bruger dette.

5 dage er et fint tal, ellers indtil Google PageSpeed Insights ikke brokker sig mere.
Nogen kalder dette for TTL.

Minify?

cccMinify dækker over minify og combine og går ud på at tage alle dine CSS (stylesheet filer) og JS (javascript filer) og sætte dem samme til to filer, samt fjerne unødigt kode.
Lige nu har du sikkert 5 eller flere af hver. 

Dette er der heldigvis systemer til. Heldigvis! For et par år siden sad jeg timer og gjorde det for folk 🙂 

Der er nogen forskellige måder at gøre det på:

Prestashop? Det er meget enkelt, slå det til. Det virker altid! Sikre dig lige at siden ser ordentlig ud bagefter(css) og at funktionerne virker(js).

WordPress er det mere besværligt, hvis det skal være helt rigtigt så skal du have fat i en koder, men du kan hurtigt gøre det meste, WP Minify Fix klare opgaven 80%, der er altid et eller andet WordPress plugin som ikke kommer med, minify er også bygget ind i Cloudflare, sammen gør de det tit 100% …
Igen, Cloudflare er et must.

 

Billeder skal vises i rigtigt størrelse

Hvis dit logo bliver vist i 100x100px, skal det også gemmes i 100x100px. Det her behøver jeg nok ikke sige. Men der er rigtigt mange som ikke gør det.

Et par veninder havde en webshop, på Shopify, og de have uploadet nye billeder til alle deres produkter, ca. 100 af dem, men deres side blev lidt langsom fortalte de, det viste sig at deres “alle produkter kategori” fyldte over 150MB imod normalen som er ca. 1MB, da deres designer havde valgt at bruge fuld størrelse billeder til de små billeder i oversigten.
Jeg har fornyligt stødt på en anden webshop, som gør det samme, alle billeder er mindste 50% for store.

Billeder skal vises i rigtigt størrelse. Dette kan du selv gøre.

Billede Sprite

all_sprite2@2xHvad er CSS Image Sprites? Dette er lidt mere kompliceret, og er nok for dem af jer som er lidt mere tekniske. Det handler om at sætte alle faste billeder på din side sammen, til et enkelt billede, også bruger man css til at vise den del af billedet som skal være de forskellige steder.

Man bruger css sprites fordi det er hurtigere, men grunden til at det er hurtigere er at dine brugere’s browsere er begrænsede, fx kan en normal browser kun hente max 8 filer samtidig, og hver gang en browser starter med at downloade en del af en side eller et billede er der en masse spild tid til at forbinde de 2 computere, derfor kan det bedst betale sig at have så få filer som muligt.
Til højre kan du se et sprite fra Mackabler.dk, med logo, 2 billeder fra bunden og alle kreditkortene 🙂

Det første startup som laver en “Auto Sprite” service bliver milliardær, please kom igang 🙂  

Komprimere din side

Populært er det at aktivere Gzip på din side, det her kan du også selv klare.
Det handler om at du skal få din server til at sende en komprimeret version af din side, hvis en browser beder om det. Dette bruger man som regel en eller andet Zip format til.

Det er meget forskelligt hvordan du aktivere det, mange shared hosts (unoeuro, gigahost, one osv.) har en linje kode du skal skrive i din Htaccess fil, men hvis du har din egen server skal du selv indstallere det.

Bruger du wordpress kan du downloade et plugin som kan klare dette, fx: Check and Enable GZIP compression

Du kan tjekke om det virker her: gzipwtf

CDN

Eller content delivery network, CDN er noget jeg aldrig har haft brug for, sider der har behov for dette, skal være meget store.
I store træk er CDN at du ligger din side på forskellige servere, på den måde kan dine besøg hente fra flere servere samtidigt, og derfor få hurtigere forbindelser og få i hvert fald dobbelt så mange forbindelser fra 8 til 16 ved 2 servere, men CDN kan også brugere flere end 2 servere.

CDN kan sættes op manuelt eller automatisk, det er bygget ind i Cloudflare, men den gratis version af Cloudflare er meget langsom, du skal betale 20$/md for deres service før du får en brugbar CDN fra dem.

Du kan også bruge CDN hvis din side skal bruges over hele verden, her sætter man servere op forskellige steder, så brugeren får den server som er tættest på, eller hurtigst.

Hvis du overvejer CDN og betaler under 100kr/md for din server nu, så drop det og få dig en hurtigere server i stedet for. Ellers så forsøg med en af de mange automatiske systemer, som koster penge, her i blandt:
Priserne er taget ud fra en side med små filer, og omkring 4GB båndbredte /md.

Cloudflare maxcdn.com verizondigitalmedia amazon cloudfront rackspace Cloud Files
$20/md ($5 for side nummer 2) $9/md (+$15 for flere pladseringer) +$1000 1. år er gratis, op til 50GB og 2M Request

Efter: $4/md

under $1/md
Du betaler per gb.

Cloudflare er det sikre valg, da alle de andre kræver at du står for opsætningen.

Denne liste er ikke kompelt

Der er mange andre måder at få hurtig kode, disse metoder er gode hvis du har et CMS, som du ikke altid er herre over 🙂 Men skriv gerne til mig hvis jeg mangler nogen fede muligheder.
Wizzi-2015-dec

Sådan forholder du dig i et DDOS angreb

Du kan læse om hvad et DDOS angreb er her: Wiki DDOS

744px-Stachledraht_DDos_Attack.svgLige hurtigt er et DDOS angreb at din server bliver besøgt flere gange end den kan håndtere, det betyder at en eller flere dele i netværk/server/kabler bliver lukket ned så din side ikke virker.
Måden man forsvare sig imod et DDOS er at man filtre de besøgende og filtre dem fra som ikke er rigtige, men dette kræver stadig at netværk/server/kablerne er store nok til at håndtere trafikken, også er vi tilbage til det første problem. Derfor er det stort set umuligt at forsvare sig imod et DDOS, med mindre det er meget småt.

Man kan ikke rigtigt forsvare sig imod et DDOS, med mindre man har planlagt rigtigt og bruger mange tusinder kr på hosting.

Vi blev i sidste weekend udsat for et DDOS, det var stort, så stort at hele hostens server lukkede ned og alle sider som var på samme server var lukket samtidig.
Man kan ikke rigtigt måle DDOS størrelser fordi man kun kan måle op til maks for ens servere, også holder den op med at måle, vores første angreb var på 150 000 forbindelser i sekundet og det andet var på flere milioner. Anden gang lå vi på en server med bedre beskyttelse.

Her er en liste over hvad man skal gøre hvis man bliver udsat for et DDOS:

  1. Forhold dig roligt
  2. LAD VÆR MED AT BETALE!
  3. LAD VÆR MED AT SVARE DEM!
  4. Lad vær med at fortælle din host at du er under angreb.
  5. Brug Cloudflare

1. Det koster penge at være ned, og det er noget man må tage med, men der er desværre ikke andre muligheder.

2. Hvis du betaler, kommer du til at betale for evigt, det er stort set gratis for hackerne at lave et DDOS og hvis du har bevist du har råd, så har du også råd om en uge eller en måned.

3. Jeg svarede, og jeg tror det havde været mindre sjovt for dem, hvis jeg havde holdt min mund.

4. Det her er vigtigt, fordi det var den fejl jeg lavede, hvis du fortæller du er under angreb så bliver du højest sandsynligt smidt ud, også står du og skal skifte server samtidig med at du skal klare alt det andet.
Webhosten skal nok finde ud af det selv.

5. Cloudflare hjalp ikke os, men det hjælper imod 80% af alle angreb. Opsætningen er super enkel, bare sørg for at du ikke udgiver dine ip adresser der inde og at alt køre igennem Cloudflare. Du kan se en Opsætningsguide til Cloudflare her, du får også Gratis SSL med Cloudflare.

Her er min historie med DDOS.

  • Lørdag morgen gik siden ned, kort for inden havde vi modtaget emails fra en russer som fortalte os at vi var under DDOS angreb, Cloudflare ville ikke hjælpe og vi skulle betale 15 BTC (25.000kr) for at det stoppede.
  • Jeg svarede: at vi ingen penge havde.
  • Jeg aktiveret cloudflare
  • Jeg fik en mail om at Cloudflare ikke ville hjælpe, det var også rigtigt.
  • jeg skrev til vores webhost, han havde ingen idé, han fortalte mig at han først kunne hjælpe mandag, da den PC han skulle bruge var på arbejdet.
  • DDOS’et hold et pause på 15min lørdag, her omdirigeret de trafikken så den ramte hosten direkte, så alle hostens websider gik ned.
  • Så tog webhosten sig samme og arbejdede på en løsning hele natten.
  • Webhosten foreslog vi kom over på en ny server søndag, men først mandag, denne server skulle være DDOS sikret, igennem en af danmarks største hosts.
  • Søndag aften stoppede DDOS’et, noget videre.
  • Mandag kom vi over på den nye host, de blev lagt ned imens vi uploadede siden til den nye server. Dette fik hosten til at tro at vores email var hacket, og det var grunden til at den nye ip blev lagt ned før vi var online. Jeg tvivler, da emailen indenholder FTP, mysql oplysninger, paypal login, epay login, sikkert også netbank login osv, og dette kan være meget mere lukrativt end DDOS-ransom note.
  • Vi var sammenlagt nede i 10min på den nye server, vi flyttede tilbage til vores trofaste, men lidt langsomme, Gigahost løsning som vi bruger i dag. Den koster under en 10 del men er også 1/2 så hurtig.
  • Og vi har ikke været nede siden.
  • Vi er ikke velkommen hos den host vi ellers stadig betaler for.

 

Vi fik et tilbud efter 24 timers nede tid. DDOS manden gav mig 50% rabat, og et tilbud om at sikre vores server imod DDOS for kun $50/md 🙂 Han begrundede rabatten med at kan godt kunne lide mig, og at jeg havde svaret 🙂

Nu har vi været oppe på den lille host i en uge, alt er godt, og vi har ikke oplevet nogen nedgang. Det hele har kostet os under 20 000kr men en masse besvær.
Og gode råd om hosts ? Jo større jo bedre 😉 Selv om vores host viste alt om prestashop, så viste de nøjagtigt intet om DDOS.
Vi havde skiftet host uanset hvad, fordi forløbet simpelhen var latterligt uprofessionelt, men det havde været rart at ligge på den hurtige server indtil vi fandt en ny.