Hallo WWF'ers! Heb al een tijdje niet hier gepost, druk, operatie ondergaan, je kent het wel . Ik post even in dit forum en hoop dat het hier goed staat. Sinds het begin dat de webshop online is gegaan (september 2013) is de shop nooit snel geweest. Dit is mijn eerste shop en al doende leert men als ondernemer. Op dit moment is de shop eigenlijk zo belachelijk traag dat ik er een beetje weekmoedig van wordt.

Zelf heb ik totaal geen verstand van de technische kant achter de shop, de webshop is gemaakt door een webbureau. Tot nu toe werken ze heel goed met me mee, ze zijn niet duur en doen veel 'gratis' werk (even bannertje hier maken, verandering daar). Maar de traagheid is zo erg nu dat het vaak 15 tot 30 seconden of langer duurt dat pagina's soms laden. En dit kan gewoon niet goed zijn voor conversie. Ikzelf wordt er al kriebelig van. Volgens hun eigen zeggen hebben ze al verschillende pogingen gedaan uit te zoeken waar het probleem zit. Ze hebben zelfs al een 'externe' specialist ingehuurd die ook niks kon vinden blijkbaar. Ook met de SSL zitten we al vanaf het begin aan te kloten en er is nog steeds geen SSL geïnstalleerd.

Dus ik zou graag jullie mening willen weten, of jullie kennis over opencart. Deze traagheid, dit moet toch niet kunnen lijkt mij? Moet ik op mijn strepen gaan staan en eisen dat dit nu eindenlijk wordt opgelost (heb zonet al wel even een mail hierover gestuurd, wel op aandringen dat ik het opgelost zie worden, maar verder niet gedreigtd o.i.d, zo zit ik ook niet in elkaar). Concurrenten van mij laden binnen 2 á 4 seconden en zijn ook sites hevig met afbeeldingen, nog meer als op mijn shop. Ik heb zelf ook geen toegang tot de server op dit moment, alleen gewoon het admin gedeelte van de shop. Is het misschien tijd om over te stappen naar een andere partij? Aan de andere kant hebben ze me op andere aspecten wel heel goed geholpen. Ik zit zo in twijfel. Geld om een compleet nieuwe webshop te laten ontwikkelen heb ik niet op dit moment. Simpelweg omdat verkopen erg op en neer gaan (soms een week met record omzet, en zoals nu sinds donderdag amper bestellingen).

Hilda schreef:Ook met de SSL zitten we al vanaf het begin aan te kloten en er is nog steeds geen SSL geïnstalleerd.

Dat zegt mij genoeg: ander webbureau inschakelen.

OpenCart staat niet bekend om zijn lange laadtijd. Dus erg raar dat dit zo slecht gaat. Zelfs op een niet optimale hosting is met OpenCart vaak wel wat snelheid te boeken. Dus ik denk dat je gewoon op een veel te langzame server zit. Daarna is er overigens ook nog voldoende aan snelheid te winnen, maar dan moet de basis wel goed zijn.

Nu duurt het meer dan 4,5 seconden voordat het eerste antwoord van de server binnen is. Daarna moet het laden van de bestanden nog beginnen! Daar verlies je dus echt klanten en zoekmachine rankings mee.

Wat betaal je nu aan hosting? Is dat een paar euro per maand, dan zou ik echt wat beters adviseren. Prijs is niet alles, maar zeker als webwinkel moet je daar niet drastisch op besparen.

@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. Helaas is een Ferrari ook erg mooi, maar als hij niet vooruit komt, dan is het plezier er ook snel vanaf.

libertes schreef:@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.

Eens, je moet het kind ook weer niet met het badwater weggooien.

De initiële responstijd is vooral een drama. Die zou onder 200 ms moeten liggen, maar schommelt ergens boven 3,5 s. Net kwam ik een keer zelfs boven 7,5 s uit, dus dan kun je bijna tot tien tellen. Betere hosting zou dat voor een groot deel kunnen oplossen.

Mijn hosting is niet een paar euro per maand, wel wat meer xD. Ik zal even opzoeken, ik ben nog niet zo lang geleden naar een andere host verhuist omdat de oude server erg veel problemen had. Shop lag er erg vaak uit.

Maar een snellere host, wat dus 4,5 sec zou moeten schelen, dan is er nog steeds zo'n 10 seconde (bij mij tenminste) wat het nog steeds moet laden. En inderdaad het webbureau doet veel grafisch werk maar heeft voor mijn shop toch ook wel redelijk wat webshops gemaakt. Maar ja als leek is het soms toch moeilijk een keuze te maken. Heb wel verschillende offertes aangevraagd en gesprekken gevoerd. Misschien is het idee goedkoop = duurkoop hier wel half op van toepassing. Voor een magento shop met maar een paar functies had ik al minimaal het 3 dubbele moeten betalen.

Ik wil hun 'naam' ook absoluut niet zwart maken. En dat SSL gedoe had ook weer te maken met waar de SSL bij aangevraagd werd. Heb ik ook geen verstand van. Nu zou er laatst iets in de SSL veranderen waardoor het voor mij goedkoper zou worden, dus werd er mij geadviseerd om nog even een maandje te wachten. Dat was in september, intussen ligt december al op de loer. Maar ja op dit moment is de belangrijkste factor toch echt wel de snelheid van m'n shop, dat ze verder veel voor me doen is prachtig, maar ik heb toch liever dat die shop gewoon lekker soepel loopt. En ik heb er zelf helaas geen kaas van gegeten. En overstappen naar een andere partij zou ik ook moeilijk vinden, dan zou iemand al iets moeten aanbevelen.

Dit is een reactie op een mail van mij uit begin juli over de traagheid van de shop (ja ik zeur hier elke maand wel over). Dat geen tijd hebben was omdat hij 2 weken op vakantie ging.

--------------

Afgelopen dagen heb ik nog wat onderzoek gedaan naar de laadsnelheid van je website. Qua server is er nu in ieder geval niks aan de hand. Dit kun je oa testen door de laadsnelheid van de admin te controleren, dit gaat als een trein. Zoals gezegd heeft een webshop altijd een langere laadtijd omdat er veel bestanden (vooral opmaak en javascript) geladen moeten worden, in jouw geval 81.
Maar dat verklaart nog niet waarom jouw site niet wat sneller laadt.

In totaal moet er 1,6 mb geladen worden voor de homepage, dit valt voor de huidige internetsnelheden erg mee. Qua performance (hoe de website met server gerelateerde dingen om moet gaan) heb ik een aantal dingen gewijzigd, hierdoor scoor je nu een 95/100. Hier valt dus geen winst meer te behalen.

Verder heb ik nog een aantal dingen aangepast maar dit heeft nog niet tot opzienbarende resultaten geleidt.

Op het internet zijn er nog tal van modules verkrijgbaar die allemaal beweren dat de snelheid hierdoor verbetert. Helaas heb ik hier nu geen tijd genoeg voor om dit goed door te nemen welke voor jou nu de beste zal zijn. Na mijn vakantie zal ik hier dus weer verder mee
gaan.

Kortom er is wat winst geboekt maar de laadsnelheid is nu niet op het punt waar het wezen moet. Er zit een bepaalde wait time wanneer men de domeinnaam is ingetoetst en het daadwerkelijk tonen van de webshop. Na deze wait time laadt de webshop binnen een fractie van een seconden. Doel is dus om deze wait time te verkleinen.

Dat laatste is inderdaad precies het probleem!

Alleen ... het probleem signaleren is niet voldoende; het moet ook worden opgelost.

Je Time To First Byte (TTFB), zo heet dat ding, is veel te lang. Eenvoudig gezegd: je server doet er 3 tot 7 tellen over om te snappen dat een HTTP-verzoek aan jouw site is gericht. Meestal betekent dit dat je op een druk bezette server met honderden andere sites zit.

Dat ligt niet aan OpenCart. OpenCart ontvangt het HTTP-verzoek namelijk pas nádat de server heeft uitgezocht voor wie het verzoek is bestemd.

Waar het wel aan ligt, is toch je hosting. Zelfs als je, zoals in jouw geval, een server deelt met 150 andere sites, mag het afhandelen van één HTTP-verzoek niet zo lang duren.

Dat een bezoeker zo lang moet wachten is echt onacceptabel. Het is dat ik wist dat ik lang moest wachten anders had ik al lang weg geklikt. Daarna laad echter wel een super mooie website dus daarvoor mijn complimenten.

Mij valt ook op dat er het een en ander mis is. Enkele bestanden die door de browser worden geladen bestaan namelijk niet. Tevens worden heel veel elementen geladen die mogelijk kunnen samengevoegd en kunnen worden geoptimaliseerd. Een website van 1,4 MB is met snel internet niet meer zo'n heel groot probleem. Maar steeds meer bezoekers komen met een smartphone of tablet op websites waarbij de internetsnelheid en rekenkracht niet zo groot is.

Al lijkt mij het belangrijkste eerst te kijken waarom de website meer dan 5 seconde laad. Dit kan inderdaad wijzen op een trage webhost, maar de wait kan ook komen door een slecht werkend of slecht geoptimaliseerd PHP-script.
Om te beginnen zou je modules kunnen in en uitschakelen in OpenCart of deze vertragen.
Daarnaast kan je inderdaad een caching module overwegen, al heb ik op gebied van OpenCart te weinig ervaring om je er een direct te adviseren, mogelijk kan je huidige webhost of designer je hier mee helpen.

Ik denk ook dat het niet aan OpenCart zelf ligt. Ik heb mijn groothandel website erop draaien en die vind ik zelf wel aardig vlot doorlopen.
Wel heb ik een keer gehad dat een bepaald script zo ontzetten traag van start ging, dat het inderdaad heel lang duurde voor de hele website te zien was en een volgende pagina opgeroepen werd. Toen ik die eraf haalde ging het weer goed en vlot door.
De website is gehost voor een paar euro per maand, zelfs een paar euro per jaar. En daar heb ik gelukkig ook geen problemen mee.
Mijn technische kennis komt niet zover als bovenstaande reacties. Zover kan ik het niet voor je uitzoeken. Maar misschien helpt het om te weten dat deze 2 dingen het dus waarschijnlijk niet zijn.
Succes met zoeken en vooral oplossen!

Hallo Hilda,

Ik draai op het zelfde systeem en heb er nooit last mee.
Heb onder andere ook veel grote afbeeldingen en alles laad vrij rap.

Maar als ik op je link klik heb ik binnen 2,5 sec. je webshop dus zo langzaam is het bij mij niet.

Zoals ik al dacht, m'n webshop staat nu gehost op een VPS, deze kost mij €35,- per maand. Inmiddels zijn ze er zelf ook achter gekomen dat het aan de ene kant aan de wait time ligt. Het lijkt mij niet dat een VPS hier het probleem kan zijn, bij een shared pakket wel, maar hier niet. Dit wordt ook wel bevestigt doordat de back end, admin gedeelte wel gewoon snel laad.

Zelf denken ze dat er mogelijk ook javascript dingen elkaar in de weg zitten. Vrijdag zal er een javascript expert naar mijn webshop kijken. Ik zal een paar suggesties van jullie even in de mail zetten. Gelukkig nemen ze het goed op en zullen er extra werk van maken om alles z.s.m op te lossen.

Bouncepercentage valt gelukkig nog mee, eigenlijk is het bouncepercentage als ik ze moet geloven erg goed. Dit is 38%.

De wait time wordt veroorzaakt doordat de webserver traag reageert. Dit kan komen door overbelasting van de server of doordat een PHP script (OpenCart Module) verkeerd in elkaar zit.

Javascript werkt aan de zijde van de bezoeker op zijn/haar PC. Deze begint pas te laden nadat (alle) bestanden binnen zijn.
Je probleem ligt dus echt aan de webserver of een PHP-script daarop. De Javascript laten onderzoeken zal dus helaas niets opleveren wat met dit probleem heeft te maken.

Laat een deskundige dus naar de VPS kijken of de webserver goed is geconfigureerd en/of dat een bepaalde OpenCart module roet in het eten gooit.

Veel succes!


PS. Waarom huur je trouwens een VPS voor een 'simpele' website? Laat je deze door iemand beheren? Bij een VPS ben je namelijk in meeste gevallen zelf verantwoordelijk voor de werking en het veilig houden van het besturingssysteem en alle software. Het is dus verstandig hier iemand met veel kennis op te zetten.

@Joritz, als je even mijn berichtjes goed had gelezen 'huur' ik niks in, behalve dan het webbureau die voor mij alles doet op het gebied van de webshop. 'Ik' heb geen verstand van hosting, javascripts, php's of uberhaupt proberen het probleem te achterhalen.

De webshop is gehost op een VPS, dit is besloten door mijn webbureau en zij zullen dit dan ook wel goed onderhouden in samenwerking met het hostingbedrijf. Mijn vorige host was gewoon bagger en was veel offline. Mijn huidige host is zodra mijn eigen server offline gaat door een probleem, wordt ik (zoals ik het heb begrepen) meteen overgezet op een andere met een backup. Zo is mijn shop 99% online. Ik heb wel een beetje kaas gegeten van hosting, maar dat is het meest basic van basic kennis. Enigste andere keer dat ik ooit iets op een VPS heb gehost was een groot internationaal forum, maar ook dat werd gedaan door mensen met kennis (ik was de admin, en ik deed de community, net zoals ik nu de voorkant doe, de verkopen).

Zonet weer een reactie terug gehad, ze zijn gewoon nog steeds druk bezig met het achterhalen waar het probleem zit. Dus ze zitten niet stil, ze bekijken per onderdeel waar het probleem kan liggen. SSL is nu onderweg en hopelijk binnen een paar dagen geregeld.

Ik snap ook dat jullie willen helpen, ben op dit moment een beetje de middelvrouw die nergens verstand van heeft xD. De Cashing module hebben ze al gedaan en hierin zat niet het probleem.

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.

No 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.

Uit: Best Practices for Speeding Up Your Web Site

Ik heb je bericht doorgestuurd Ward, wat je nu zegt dat gaat bij mij de pet boven... Ik snap het principe wel.... maar daar blijft het bij. Hoop niet dat m'n webbureau moe word van al mijn emails de lezen.

Ward schreef: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.

No 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.

Uit: Best Practices for Speeding Up Your Web Site

Hai Ward, nou dit heeft wel geholpen dit is iets wat ze nog niet wisten, ze gaan dit nu verder onderzoeken .

*huggles Ward* het heeft geholpen, de shop is een stuk sneller dan wat het was. Nog steeds niet snel genoeg. Maar de laadtijd voor mijzelf zit nu rond de 6sec standaard voor elke pagina .

6 seconden is nog echt te langzaam voor een OpenCart webwinkel.

Welke modules en maatwerk zaken heb je allemaal? Laat je hoster de langzame queries wegschrijven, dan kun je kijken waar de oorzaak ligt.

Kijk verder ook naar maatwerk modules. Een webwinkel moet tegenwoordig echt binnen 2 seconden op je scherm staan...

Ik ben het eens met Libertes. 6 seconden blijft nog steeds aan de trage kant. In die tijd heb je al lang een andere website gevonden waar je mogelijk dezelfde producten hebt.

Ik raad je aan er even een deskundige op te zetten, al kan je zelf al snel uitsluitsel geven over de oorzaak door even modules uit te schakelen om te kijken of dit de bottleneck is.

Veel succes!

WElke deskundige?

En als je al mijn berichten heb gelezen; 'IK' kan niks kwa technische/back end kant op webshop gebied.

Ik zou je adviseren om eens te contacten met je huidige hosting. Vraag hun of ze jouw website naar een andere server kunnen verplaatsen om de prestaties te verbeteren. Goede snelheid ervaringen heb ik vooral gehad met Versio en Opencart...

Het probleem ligt echt bij je server, en anders toch echt in je code.

Mooie shop, mooie stijl die goed past bij je producten!

Wat betreft je SSL, op je productpagina wordt nog de melding:

"Er wordt alleen veilige inhoud weergegeven."

getoond.

Oftewel er wordt nog ergens content ingeladen m.b.v. "http" i.p.v. "https". Alle content moet met https worden geladen anders krijg je zo een melding.

Axeldekker schreef: Het probleem ligt echt bij je server, en anders toch echt in je code.

Het is nog steeds de server (Zoals Ward al zei) http://tools.pingdom.com/fpt/#!/dAKILk/ ... vintage.nl
2.9 seconden (voornamelijk) wachten op een response, daarna worden de 'bestanden' in minder dan een seconde geladen.

http://tools.pingdom.com/fpt/#!/bWDcmS/ ... vintage.nl

Net ff getest, ook gewoon op je shop geklikt maar vind het nog steeds veel te traag gaan.
Ik zit hier met een Ziggo 150mbit verbinding, elke website flitst zo op het scherm, behalve jou webwinkel.
Ik zou het persoonlijk echt onacceptabel vinden als je 35 euro per maand betaald en het probleem nog steeds hetzelfde is.
Dan zou ik mij toch echt afvragen of jou hostingspartij jou niet een oor aan naait.

https://www.lipperhey.com/en/lookslikevintage.nl/
duurt het laden ook meer als 5 seconden.

Hilda, Google heeft een hele handige tool ontwikkeld voor het achterhalen van de lage snelheid.

Voor de resultaten van je website kan je hier kijken

Het grootste probleem is nog altijd de reactie tijd van de server, die is nu 3,6 sec en zou onder de 0,2 sec moeten komen.

Tevens kan je niet proberen je afbeeldingen te optimaliseren zodat er minder gedownload hoeft te worden

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.

Dit maakt echter niet de website zo traag. Het maakt alleen, dat je website niet gestreamt wordt naar de gebruiker. Als je geen gzip compressie gebruikt, zal de server meteen beginnen met bytes uitspugen, zodra het gereed is.

Dit kan helpen, omdat je dan ook meteen aan hoe de pagina laadt kan zien welk deel er traag is. Daarbij worden dan ook meteen externe bestanden ingeladen, terwijl de server nog bezig is. Dat zal in dit geval dus een verbetering in de snelheid zijn. Het voordeel in brandbreedte van gzip compressie is zeer klein, omdat enkel tekst zoals de html van gzip compressie profiteert. JPG is van zichzelf gecomprimeerd. In jou geval maakt gzip compressie je website dus niet sneller, maar trager. Hier is sowieso winst te behalen.

Je hosting is gewoon ronduit traag. Dit is vrijwel altijd in de SQL ter herleiden. PHP uitvoeren kost vrijwel geen server capaciteit. Zodra er SQL komt, gaat de server belast worden. Nu ben ik niet bekend met opencart, dus of het daar nog ergens in dat pakket wringt weet ik niet. In veel gevallen kan er met SQL veel winst behaald worden door te kijken of je wel de juiste indexes in alle tabellen hebt.

Ik zou sowieso overwegen naar een snellere hosting te gaan. Daar zit namelijk met zekerheid wel het voornaamste probleem.

Tot slot vind ik 1,4MB inderdaad wel veel. Je kan bij JPG afbeeldingen vaak winst behalen door de 'kwaliteit' te verlagen. Bij een goed tekenprogramma kun je bij het exporteren naar JPG de kwaliteit instellen. Voor scherm afbeeldingen is vaak 75% kwaliteit genoeg. Dan kun je hoge resolutie afbeeldingen gebruiken, zonder dat de afbeeldingen meteen veel bandbreedte kosten. Je afbeeldingen zijn als ik het goed zie nu 90%. Als ik bijvoorbeeld pak:

https://lookslikevintage.nl/image/cache ... 80x380.jpg

Deze is ~250kb. In 75% zie ik persoonlijk niet eens verschil op mijn laptop, maar is de afbeelding wel opeens ~110kb.

NOP Webdesign schreef: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.

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.

jessewillem schreef:

NOP Webdesign schreef: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.

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.

Dat brengt me op nog een idee. Wat dacht je van van het volgende.

Begin code dit neer zetten:

define(START_TIME,microtime());


dan na elk deel neerzetten

echo (microtime() - START_TIME);

Dat draai je uiteraard dan lokaal of op een subdomein in die vorm. Dan kun je isoleren waar die lange laadtijd schuil gaat. Dan is het schuldige proces snel gevonden. Als je die dan iets op verzint om te cachen, zou het opgelost moeten zijn? Als het meerdere functies zijn die vrij lang duren, allemaal proberen de output te cachen? Dan met de gewenste interval via een cronjob de gecachede output verversen.

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.

jessewillem schreef: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.

Niet bij OpenCart. OpenCart gebruikt de outputbuffer (ob) alleen intern, bij het opbouwen van een MVC-view:

https://github.com/opencart/opencart/bl ... er.php#L29

jessewillem schreef: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.

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.

Staan de indexen niet goed, wat bij OpenCart helaas vaak het geval is, dan leidt de GROUP BY voor de aggregaatfunctie tot een full table scan. Dus tellingen uitzetten én eventueel extra indexen toevoegen.

Vanochtend vielen me nog twee dingen op:

• Een redirect van http:// naar https:// kost vaak meer dan 1 seconde. Dat is echt te lang: je serverconfiguratie deugt niet of de server zit in een slecht netwerk. Als ik me niet vergis, zitten er op dezelfde server zo'n 140 websites.

• Bij herhaalde requests verzendt de server steeds opnieuw alle afbeeldingen. Dat is nergens voor nodig: een browser kan die in de browsercache opslaan. Ook dit duidt op een slechte serverconfiguratie. (Geef maar aan de internetmensen door dat je hier een 304 Not Modified wilt zien, geen 200 OK.)

NOP Webdesign schreef: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.

NOP Webdesign schreef: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]

Tekort door de bocht, is een tabel met meer dan 1 miljoen records die doorgelopen wordt. Dan vervolgens per product moet er bekeken worden of het nog wel in het assortiment voorkomt. Dan zit er ook nog in, dat sommige producten als ze verkocht worden in de order tabel 1 staat, maar het een artikel is die per 10 gaat bijvoorbeeld. Dus dan heb ik er 10 van verkocht. Zo wil ik het wel in mijn top 5 berekend zien.

De verkoop eenheid en of het artikel nog beschikbaar is, moeten uit de artikelen tabel komen. Die is over de 200MB.

Dus niets mis met de SQL query, vraag gewoon veel info uit grote tabellen.