Dat zegt mij genoeg: ander webbureau inschakelen.Ook met de SSL zitten we al vanaf het begin aan te kloten en er is nog steeds geen SSL geïnstalleerd.
Eens, je moet het kind ook weer niet met het badwater weggooien.@Ward
Heb het idee dat het bureau waar ze nu bij zit vooral grafisch goed is. Ik zou er dus minstens een ook wat technisch onderlegd persoon bij halen. De webwinkel zelf ziet er trouwens wel mooi uit.
Met Shopify maak je zelf je eigen webwinkel dankzij meer dan honderd thema’s en de complete appstore. Shopify sluit ook goed aan op dropshippers. De software is technisch volledig SEO-geoptimaliseerd en biedt alle sociale media-integraties. Meer info op Shopify.com.
Uit: Best Practices for Speeding Up Your Web SiteNo 404s
HTTP requests are expensive so making an HTTP request and getting a useless response (i.e. 404 Not Found) is totally unnecessary and will slow down the user experience without any benefit.
Some sites have helpful 404s "Did you mean X?", which is great for the user experience but also wastes server resources (like database, etc). Particularly bad is when the link to an external JavaScript is wrong and the result is a 404. First, this download will block parallel downloads. Next the browser may try to parse the 404 response body as if it were JavaScript code, trying to find something usable in it.
Hai Ward, nou dit heeft wel geholpen dit is iets wat ze nog niet wisten, ze gaan dit nu verder onderzoeken .Hilda, de server antwoordt voor de homepage 5 keer met een "404 Not Found". Er worden bestanden opgevraagd die niet bestaan; daarvan kán een server sloom worden.
Bij OpenCart (en meer in het algemeen ook Apache) kan dat problematisch zijn omdat de 404-fout wordt afgehandeld als een webpagina die door de hoofdapplicatie index.php wordt gegenereerd. Vereenvoudigd gezegd: bij 1 verzoek om 1 webpagina worden eigenlijk 6 pagina's tegelijk gegenereerd: de echte pagina plus 5 404-pagina's.
Als je het webbureau die 404's laat oplossen, zal je site een stuk sneller worden.Uit: Best Practices for Speeding Up Your Web SiteNo 404s
HTTP requests are expensive so making an HTTP request and getting a useless response (i.e. 404 Not Found) is totally unnecessary and will slow down the user experience without any benefit.
Some sites have helpful 404s "Did you mean X?", which is great for the user experience but also wastes server resources (like database, etc). Particularly bad is when the link to an external JavaScript is wrong and the result is a 404. First, this download will block parallel downloads. Next the browser may try to parse the 404 response body as if it were JavaScript code, trying to find something usable in it.
Het is nog steeds de server (Zoals Ward al zei) http://tools.pingdom.com/fpt/#!/dAKILk/ ... vintage.nlHet probleem ligt echt bij je server, en anders toch echt in je code.
Een simpele ob_start() ergens in de code zou eventueel ook het probleem kunnen veroorzaken in combinatie met een functie die traag reageert. Dat laatste is ook van toepassing als gzip compressie aanstaat met die methode.Probleem zit duidelijk bij de server. Reden dat time to first byte zo hoog ligt is gzip compressie. Met gzip compressie wordt pas data overgedragen als het bestand helemaal gereed is. Oftewel als de server de pagina volledig opgebouwd heeft.
Een simpele ob_start() ergens in de code zou eventueel ook het probleem kunnen veroorzaken in combinatie met een functie die traag reageert. Dat laatste is ook van toepassing als gzip compressie aanstaat met die methode.Probleem zit duidelijk bij de server. Reden dat time to first byte zo hoog ligt is gzip compressie. Met gzip compressie wordt pas data overgedragen als het bestand helemaal gereed is. Oftewel als de server de pagina volledig opgebouwd heeft.
Overigens hoeft SQL niet direct een probleem te zijn, tenzij er een paar trage queries uitgevoerd worden bij het laden van pagina's. Dit is eventueel te zien in de slow query log in MySQL, aangezien OpenCart dat gebruikt.
Ook is het misschien een idee om te code na te checken op eventuele aanroepen naar bestanden op andere servers, dit kan in combinatie met object buffering en/of gzip ook leiden tot het traag laden van pagina's.
Eventueel zou de traagheid bijvoorbeeld ook veroorzaakt kunnen worden door code die gewoon inefficiënt werkt, lange lussen uitvoeren is bijvoorbeeld ook niet verstandig.
Voor het uitsluiten van de serverconfiguratie is het verstandig om de complete webwinkel te draaien op een andere vps of thuis op een desktop/laptop d.m.v. Xampp en dergelijke software. Statische bestanden zoals css bestandjes en afbeeldingen laden bijvoorbeeld wel snel. Maar dat betekend niet dat er eventueel geen fouten in de configuratie zitten. Ook is het een goed idee om bijvoorbeeld alle plugins uit te schakelen en een voor een te testen om te controleren of die het probleem veroorzaken.
Niet bij OpenCart. OpenCart gebruikt de outputbuffer (ob) alleen intern, bij het opbouwen van een MVC-view:Een simpele ob_start() ergens in de code zou eventueel ook het probleem kunnen veroorzaken in combinatie met een functie die traag reageert. Dat laatste is ook van toepassing als gzip compressie aanstaat met die methode.
Daar heeft OpenCart inderdaad wel structurele problemen. Te veel om op te noemen zelfs, maar wat wel helpt, is als je de tellingen uitzet die tussen ronde haakjes worden getoond bij categorieën, merken en eigenschappen. Die vragen namelijk om extra queries.Overigens hoeft SQL niet direct een probleem te zijn, tenzij er een paar trage queries uitgevoerd worden bij het laden van pagina's. Dit is eventueel te zien in de slow query log in MySQL, aangezien OpenCart dat gebruikt.
Dan zit er iets scheef in je SQL-query.Zelf had ik op mijn homepage een functie die me populairste artikelen moet weergeven. Dat duurt totaal ongeveer 10 seconden. Die cache ik dus ook en refresh ik elk uur.
Dan zit er iets scheef in je SQL-query.[/quote]Zelf had ik op mijn homepage een functie die me populairste artikelen moet weergeven. Dat duurt totaal ongeveer 10 seconden. Die cache ik dus ook en refresh ik elk uur.