Hurtigere hjemmeside

Fredholm93:

1. Min side laver en redirect fra HTTP til HTTPS, da jeg forcer HTTPS, men ifølge Pingdom har den gennemsnitligt 0,3 sek wait time før den overhovedet loader dette, er dette et hosting problem? Hvis jeg ping'er den med https foran min hjemmeside, så fremgår denne wait time ikke.

Hvis du laver en test på gtmetrix, tools.pingdom eller lign services på https, så vil du selvfølgelig ikke se denne redirect, fordi du angiver din slut URL.

Viderstilling bør ikke tage 0.3 sekunder, så det kommer an på hvordan du laver denne viderstilling - hvis du lader WordPress lave den eller hvis du laver den manuelt via .htaccess på din side - det vil gøre en stor forskel, fordi det ene bliver håndteret direkte af webserveren, hvor det andet skal håndteres af WordPress.

I din .htaccess kan du lave noget lign:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]

Dette vil sørge for at hvis siden ikke er https, vil den lave en viderstilling, så vil det gå betydeligt hurtigere - du skal samtidig sørge for at siden faktisk linker til https og ikke nogen http links de forskellige steder.

Fredholm93:

2. Siden loader '?wc-ajax=get_refreshed_fragments' som angiveligt skulle have en forbindelse med woocommerce kurven og den har hele 0,5 sek wait time. Jeg har læst mig til at man blot kan fjerne kurven, men det ønsker jeg umiddelbart ikke, da den jo er et vigtigt redskab i forbindelse med købsoplevelsen på siden. Det kan vel ikke være rigtigt, at noget så stort som woocommerce ikke er bedre optimeret mht. dette?

WooCommerce er stort, det er korrekt - men det er fordi det er "billigt" for folk at tage i brug, men WooCommerce er på ingen måde bygget optimalt, fordi WooCommerce (desværre) tager brug af måden WordPress er bygget på, så de gemmer produkter, ordre og lign i én stor bunke af data, nærmere i wp_posts samt wp_postmeta, hvor du vil finde det meste data for dine produkter, ordre og lign - dette virker fint i starten, men jo mere din shop vokser, jo flere ordre og/eller produkter du får - jo større bliver denne tabel, og jo langsommere bliver din side, helt automatisk.

Personligt undre det mig, hvorfor at WooCommerce ikke arbejder på at gemme data i et mere optimalt format hvad angår webshops, ligesom Prestashop, Magento og lign. gør.

Så teknisk set jo. Det kan godt bare være WooCommerce der er problemet, men det kan også specifikt have med din sides konfiguration/opbygning at gøre, der gør at det tager lang tid.

Men wc-ajax er generelt et tungt kald, udfra hvad det gør.

Fredholm93:

3. Så er det google fonts, som også loader hver gang, der gør at siden loader langsommere. Er der en måde at downloade google fonts lokalt, så den ikke skal ind og hente disse fonts via google hver gang, eller en anden mere optimal løsning?

Det kommer an på fonten, nogle fonts har licenser, men hvis vi tager de 3 du har (montserrat, raleway og kalam), så kan du finde dem her: https://fonts.google.com/?selection.family=Kalam|Montserrat|Raleway - hvis du klikker på "3 families selected" i bunden af siden, vil du finde en download knap.

Fredholm93:

HEj Lucas,

Først og fremmest, tak for din besked.

I forhold til problemstilling nummer 1, skriver du at jeg kan tilføre ovenstående kode.
I min .htaccess står der pt. følgende som det første, skal jeg blot slette fra IFmodule til og med ^roadsurfing.dk, og tilføje den kode du skriver istedet?

# BEGIN WpFastestCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} ^roadsurfing.dk
# Start WPFC Exclude

Iøvrigt, så er der flere rewrite commands i min .htaccess, men det er måske meget normalt?

Du skal beholde alt du har nuværende i din .htaccess fil og indsætte det ekstra. Og ja, det er meget normalt at have flere rewrite commands - eller, det er ihvertfald ikke et problem.

Fredholm93:

Iforhold til problemstilling 2:
Træls, at have bygget hele sitet op om woocommerce i så fald. En midlertidig løsning for mig er måske at fjerne kurven fra forsiden. Det ville jo give en hurtigere forside, og så kan kurven kun findes i shoppen.

Du kan også starte en større undersøgelse hvad tiden bruges på. Men generelt set er WooCommerce langsommere.

Fredholm93:

Problemstilling 3:

Her har jeg i første omgang forsøgt mig med Kalam, og har i den forbindelse downloaded font Kalam fra følgende side https://google-webfonts-helper.herokuapp.com/fonts/kalam?subsets=devanagari,latin,latin-ext, da han også oplyste om CSS koder, som jeg så har tilført i CSS rubrikken i mit theme.

Desværre får jeg error ved en pingdom test på disse fonts fra Kalam, se vedhæftet billede: 

Følgende CSS er det jeg har skrevet ind i mit theme. Alle filerne er ligeledes uploadet under wp-content > themes > 'mit theme' > Fonts

Ingen idé om hvordan dit tema virker - normalt set ville jeg gøre det manuelt.

Phillip:

Web fonts - hostet hos Fx Google - har den fordel, at de ofte er cachen lokalt hos brugeren. Så det vil næppe betyde en forbedring, hvis du gemmer dem lokalt.

Ja og nej, det kommer an på mange ting - hvis man allerede har en forbindelse åben til sin webserver, kan det ekstra DNS lookup, ekstra SSL handshake og ekstra TCP handshake sagtens tage længere tid end at sende disse ting gennem sin eksisterende pipeline.

Phillip:

Bruger du et webhotel? Noget af det bedste du kan gøre er at bruge en bedre host, som er optimeret til WordPress. Fx en VPS med flere ressourcer.

"Optimeret til WordPress", sådan set fra konfiguration af software (PHP, Apache/Nginx, MySQL/MariaDB), så er der ikke nogen "optimeret" konfiguration til WordPress - WordPress er så generisk at der ikke er en "one size fits all" løsning, og derfor en "optimeret til WordPress"-host, har måske WP specifikke funktionaliteter så som staging eller lign - men det er sjældent de har nogen fordel i form af hastighed. Sitegrounds "WordPress hosting" eller WPEngine performer ikke bedre end en relativt godt optimeret standard hosting udbyder.

Samtidig er en VPS ingen garanti for bedre performance af et par grunde:

- de VPSer som folk køber idag, har en enorm over-provisioning faktor (oftest på 3-1 eller 4-1), hvis du skal have dedikeret ressourcer som sikre dig at ting forbliver hurtigt, så koster det oftest kassen for disse maskiner.

Digital Ocean f.eks, sælger 4 1-core maskiner på en enkelt core, så deres over-provisioning er 4 til 1 - så du har ingen garantier i sådanne tilfælde.

- Alene software konfiguration har meget at sige for hvordan sider performer, så et 10 kroners webhotel kan sagtens performe og skalere bedre end en VPS der koster mere, udelukkende fordi de kan finde ud af at optimere software.

Phillip:

Ift WordPress’ måde at gemme data på i MySQL-tabeller, så kan MySQL klare hundredtusindvis og ofte millioner af rækker uden, at det går udover performance - hvis du oplever performance-problemer på den front, så er det formentlig mere et problem hos din host end hos WordPress.

Det vil påvirke performance når man ikke har en form for primary key man kan tage brug af, eller at mange transient data i WordPress kræves der bruger LIKE queries som ikke kan caches på nogen både, og vil resultere i table scans.

Jo flere rows du får, jo langsommere bliver WP, fordi det netop er bygget op på den måde som det er - du kan lave performance monitoring på det, og du vil se det påvirker hastigheden jo mere du tilføjer.

Samtidig med det, det er nemt at overskride 5+ millioner rows i en WP tabel med forholdsvis mange produkter eller ordre.

Det vil ej heller være hostens' skyld at WordPress' database design er dybt elendigt hvis du bruger det til en shop så problemet er ikke deres Alle problemer kan løses uden at smide hardware efter det, kræver den rigtige konfiguration - både i form af serveren, men dælme også hvad angår applikationen - du kan ikke løse alt med server-configs, og jo, du kan smide memcached eller redis efter det - men ændre stadig ikke på at du har et underliggende problem i at bruge et system som webshop, der ikke er bygget til at være en webshop.

Det er ikke uden grund at rigtige e-commerce systemer har et meget anderledes design end hvad WordPress har - de er bygget netop til at kunne skalere :')

Phillip:

I øvrigt ift web fonts: De fylder ofte en del. Så jeg undgår dem helst eller bruger højst én.

Og så er alle fonts render-blocking.