Snelheid Webshop

[steefje]

In november heb ik een nieuwe webshop gelanceerd voor ons bedrijf. www.boska.com

Het betreft hier een webshop gebouwd in Magento Community door een bureau. Nu weet ik dat Magento een relatief zwaar pakket is en minder snel is dan andere oplossingen. Ik weet ook dat voor erg zware sites met veel bezoekers je beter de Enterprise edition kan nemen, maar met 3000 bezoekers per maand lijkt me dat niet nodig

De snelheid van de webshop valt mij echter enorm tegen en daarover ben ik ook in discussie met onze ontwikkelaar. Ik snap dat snelheid een nogal subjectief begrip is, maar de traagheid stoort me echt enorm. Soms moet je echt meer dan tien seconden wachten totdat een webpagina geopend is. Een serieuze conversie killer dus.

Met het programma Tools Pingdom kan je de snelheid testen en de resultaten zijn enorm wisselend. Van prima (1.7 seconden) tot dramatisch waarbij de test niet eens afgerond kan worden.
http://www.boska-manuals....08-20%20om%2009.44.21.png

Ik kom er met onze webbouwer niet uit. Ik heb vooral het idee dat het komt doordat we wachten op de server.
Hebben jullie bepaalde tips waarmee ik concreet naar onze webbouwer kan. Ik wil dit graag oplossen namelijk

[ Voor 2% gewijzigd door MueR op 27-08-2013 11:05 ]

[Mektheb]

Moet eerlijk zeggen ik het echt reuze mee vindt vallen.

Heb zojuist even gekeken met verschillende browsers, maar hier werkt het echt prima.
Zodra ik van een artikel naar bijvoorbeeld bestellen ga is de pagina er zeer snel.

Ook de zoekfunctie werkt naar mijn mening naar behoren.

[Paul - K]

Hier erg verschillend. Van ongeveer 1 seconden uitlopend naar 4 seconden, wel enigzins aan de lange kant. Je hebt dus wel zeker een punt

[steefje]

Dat is ook het probleem. Het is zo verschillend van snel naar langzaam tot een No Go. Ik stel de vraag ook niet om te zeuren richting mijn bouwer, maar ik krijg zo veel commentaar van klanten tot aan personeel dat ik echt op zoek ben naar een concrete oplossing

[Bosmonster]

Het verschilt inderdaad heel erg en het is ook niet op specifieke pagina's terug te herleiden. Een enkele pagina was hier soms in 1 seconde binnen, en een volgende keer was het voor dezelfde 20 seconden.

Het lijkt alsof je op een beetje volle shared hosting zit.

[Tens]

Hier ook een grote variatie, tot wel 10 sec idd.

[Verwijderd]

Bij Magento is de server waar het op draait heel belangrijk.
Geen idee waar het nu op draait maar voor een beetje serieuze webshop zou het minimaal op een voor Magento gemaakte VPS moeten staan.

[cossy nl]

Je kunt kijken naar een oplossing die met caching werkt, zoals nginx, althans dat gebruik ik in combinatie met magento. bevalt erg goed

Edit: Al draaien wij niet shared.

[ Voor 12% gewijzigd door cossy nl op 27-08-2013 11:05 ]

[Bosmonster]

cossy nl schreef op dinsdag 27 augustus 2013 @ 11:04:
Je kunt kijken naar een oplossing die met caching werkt, zoals nginx, althans dat gebruik ik in combinatie met magento. bevalt erg goed

Mjah, caching is goed natuurlijk, maar als je server/hosting gewoon te traag en onbetrouwbaar is is dat natuurlijk wel een beetje een lapmiddel.

Naast caching kan er aan de frontend (en het design..) ook nog wel flink geoptimaliseerd worden, maar da's een ander verhaal

[ Voor 14% gewijzigd door Bosmonster op 27-08-2013 11:09 ]

[St@m]

Ik vind het reuze meevallen, wel zou ik zeggen dat producten al dan niet op voorraad zijn, in plaats van in

Maar goed ik heb even een paar klikken gedaan op de site, en dat ging vrij vlot.

[ Voor 25% gewijzigd door St@m op 27-08-2013 11:07 ]

[Kecin]

Meeste pagina's zijn wel redelijk vlot hier. Wat voor hardware heb je? Een shared hosting, een VPS of een dedicated server?

Een cache word natuurlijk naar een bepaalde tijd verwijderd waarna die bij het eerste bezoek weer zal worden opgebouwd. Wellicht dat je niet genoeg bezoekers hebt voor de huidige caching instellingen (en dus wellicht caching omhoog moet gooien, dus de pagina's langer statisch te laten zijn).

Magento staat erom bekend redelijk lomp om te gaan met resources, zoals hierboven genoemd is een Magento geoptimaliseerde VPS te hebben geen overbodige luxe. Daarnaast is het verstandig om alle javascript en css niet inline te gebruiken.

[MueR]

Magento is een traag wanstaltig *censored* product. Het is een beetje king of the dung hill. Om dat kreng een beetje fatsoenlijk te laten werken moet je al een opcode cache draaien (al zit die native in php5.5 mits je hem mee compiled), een memory-based filesystem gebruiken voor de temporary files, en een flink hoge query cache in je DB zetten. Het feit dat ze trots zijn op een performance increase in hun code die wel 2 requests per seconde meer kan afhandelen is tekenend.

[ Voor 9% gewijzigd door MueR op 27-08-2013 11:12 ]

[thaan]

Ik heb de site even gedraaid in WebPagetest.org en dit zijn de resultaten.


Ik zou zeggen begin eens met al die 404'tjes op te lossen.
(zie bijv. http://www.boska.com/fancybox/fancy_shadow_n.png en alle bijbehorende fancy_shadow_.png bestandjes).
Dat zal al flink schelen.
Apart dat dat 'bureau' zoiets over het hoofd ziet.

[ Voor 48% gewijzigd door thaan op 27-08-2013 11:12 ]

[TheNephilim]

Wellicht is het Plus pakket van MijnDomein een oplossing, hier zit APC bij.

Ik weet verder niet wat je draait voor hosting, maar je moet eigenlijk geen goedkope shared hosting gebruiken voor Magento. Zoals de reacties hierboven ook al aangeven, is een VPS geoptimaliseerd vaak een goed idee voor Magento.

Heb de website even bekeken en vind hem overigens niet traag. Echt snel is hij niet, maar ook niet storend traag. Dat kan natuurlijk komen doordat jullie (wellicht) de website bekijken terwijl je ingelogd bent.

[Afvalzak]

Eerste keer laden duurde bij mij zeer lang, daarna was het vlotjes.
Zal daarna dus in de cache worden gegooid lijkt mij, of je aantal connecties zitten vol?
Kijk even of er geen vreemde nginx errors/warnings staan, max connections reached etc.

[steefje]

We zitten idd op een shared hosting of die vol zit kan ik niet zeggen. Ik zal in ieder geval jullie tips met mijn webbouwer bespreken.

1. Draait de server op een voor Magento gemaakte VPS
2. Alle javascript en css niet inline te gebruiken.


@Bosmonster: zie jij winstpunten qua design. Vergt het huidige design te veel? Of is het puur smaak. Dat kan ook
St@m; dank voor je tip. Nooit opgevallen:)

@thaan http://www.boska.com/fancybox/fancy_shadow_n.png zijn afbeeldingen en niet bedoeld als toegankelijke pagina. Ik zou niet weten waar en hoe ik dit oplos

[Miyamoto]

Bosmonster schreef op dinsdag 27 augustus 2013 @ 11:03:
Het verschilt inderdaad heel erg en het is ook niet op specifieke pagina's terug te herleiden. Een enkele pagina was hier soms in 1 seconde binnen, en een volgende keer was het voor dezelfde 20 seconden.

Dezelfde ervaring hier.
Als bezoeker zou ik 'm dichtgooien en een andere website zoeken.

Behalve dat het pakket erg zwaar is, zoals vermeld, is je server ook erg traag.
Probeer anders eens een andere host (proefperiode oid)?

Verder:
- Veel afbeeldingen worden in HTML geschaald - dus je haalt veel Bytes binnen die je niet gebruikt.
- 23 blocking javascript requests
- Totale transfersize homepage 1.3 MB!
- (weinig van doen met snelheid, maar) je gebruikt jQuery 1.3.2 (Febr. 2009), Prototype 1.6.0.3 (Sep 2008)
- Typisch voorbeeld: http://www.boska.com/js/mw_js/jquery_noconflict.js Lijkt alsof er wat plugins bij elkaar geraapt zijn ipv een serieuze webshop gebouwd.

[Verwijderd]

Dan zorg dat je van die shared hosting af komt en op een goede Magento VPS in het grote geheel zijn dat niet de kosten.

[TheNephilim]

Miyamoto schreef op dinsdag 27 augustus 2013 @ 11:51:
[...]


Dezelfde ervaring hier.
Als bezoeker zou ik 'm dichtgooien en een andere website zoeken.

Behalve dat het pakket erg zwaar is, zoals vermeld, is je server ook erg traag.
Probeer anders eens een andere host (proefperiode oid)?

Verder:
- Veel afbeeldingen worden in HTML geschaald - dus je haalt veel Bytes binnen die je niet gebruikt.
- 23 blocking javascript requests
- Totale transfersize homepage 1.3 MB!
- (weinig van doen met snelheid, maar) je gebruikt jQuery 1.3.2 (Febr. 2009), Prototype 1.6.0.3 (Sep 2008)
- Typisch voorbeeld: http://www.boska.com/js/mw_js/jquery_noconflict.js Lijkt alsof er wat plugins bij elkaar geraapt zijn ipv een serieuze webshop gebouwd.

Tjah, dat is tegenwoordig sowieso vaak een probleem voor veel webshop 'bouwers'. Een boel plugins erin knikkeren om alle gewenste functionaliteit te krijgen en klaar. Daar word een website helemaal niet veel sneller van en caching is dan ook niet meer zo efficiënt.

Zelf maken wij hier webshops op maat in Wordpress en dat bevalt prima! Geen handenvol plugins nodig, sterker nog; maar 4 plugins in totaal. De klant heeft een duidelijke webshop en geen pagina's vol met instellingen en knopjes waarvan de helft niet gebruikt word.

Trouwens, aankloppen bij de hoster gaat je nu ook niet helpen. Ze verwachten dat je eerst je requests en transfersize naar beneden brengt voor ze gaan kijken waarom de website zo traag kan zijn aan hun kant.

Een homepage bevat vaak veel afbeeldingen en dergelijke, maar probeer gewoon onder die 1 MB te blijven. Ga afbeeldingen niet schalen na het inladen van de full size versie. Dat is killing voor de snelheid van je website!

Verwijderd schreef op dinsdag 27 augustus 2013 @ 11:53:
Dan zorg dat je van die shared hosting af komt en op een goede Magento VPS in het grote geheel zijn dat niet de kosten.

Zoals rooot aangeeft, er zijn nog een heleboel punten die verbeterd moeten en kunnen worden. Pas als de website dan nog traag is, heeft het zin om eens naar een andere hosting te kijken. Anders is het gewoon weggegooid geld...

[ Voor 11% gewijzigd door TheNephilim op 27-08-2013 12:02 ]

[Verwijderd]

Nee het is geen weggegooit geld. Feit is gewoon hoe goed je Magento ook tweaked, optimaliseerd , cached etc. op shared hosting is het gewoon bagger, blijft het bagger en zal het nooit wezenlijk sneller worden.

Zorg eerst dat je op een goede hosting komt en dan heeft het maken van de verbeteringen ook zin en word het ook merkbaar.

[MueR]

Miyamoto schreef op dinsdag 27 augustus 2013 @ 11:51:
- 23 blocking javascript requests
- (weinig van doen met snelheid, maar) je gebruikt jQuery 1.3.2 (Febr. 2009), Prototype 1.6.0.3 (Sep 2008)
- Typisch voorbeeld: http://www.boska.com/js/mw_js/jquery_noconflict.js Lijkt alsof er wat plugins bij elkaar geraapt zijn ipv een serieuze webshop gebouwd.

Dit vind ik overigens het meest storend en helaas is het iets wat je veel te vaak ziet. Prototype, Scriptaculous (vooruit, dat mag bij proto geteld worden), en dan ineens een antieke jquery? Het komt ook nog regelmatig voor dat er vervolgens 30 verschillende plugin files zijn, die allemaal weer losse CSS moeten laden.. Combineer die meuk lekker voor productie.

Maargoed, tegenwoordig zijn er veel te veel mensen die zich front-ender noemen en geen regel javascript kunnen programmeren; enkel jquery. Die mensen moeten uit het vak gezet worden. Mootools, Prototype, jQuery en the likes zijn enorm nuttig en besparen je een hoop tijd, maar je moet het ook niet te bont maken.

[André]

Gebruik in plaats van Pingdom beter een tool die naar de echte laadtijden kijkt. Pingdom doet alleen een request naar de server om te zien hoe snel de kale HTML geserveerd wordt. Dat zegt zo goed als niets over de tijden die gebruikers ervaren.

De echte tijd zit vaak in de rendering van de HTML, het laden van allerlei CSS en SCRIPT bestanden, alsmede tig afbeeldingen. De stelregel is dat 80% van de snelheid vaak aan de voorkant zit en 20% aan de achterkant. In de praktijk blijkt dit ook vaak waar te zijn. Gebruikt de tips hierboven die over de voorkant gaan dus.

Maak zo weinig mogelijk HTTP connecties (scripts samenvoegen, css samenvoegen, eventueel css sprites gebruiken) en verdeel ze over meerdere hostnamen. Een gemiddelde browser haalt maar 6 zaken tegelijk binnen vanaf 1 domein. Stel vervolgens de caching goed in, daarmee bedoel ik niet de caching van magento-pagina's maar de caching headers van statische elementen.

Controleer daarna bijvoorbeeld met een tool als Google Analytics de echte laadtijden die mensen zien. De tijden die je daar ziet komen rechtstreeks uit de laadtijd meting die nieuwere browser tegenwoordig ingebakken hebben. En als je weinig bezoekers hebt verhoog je het aantal metingen van 1% van alle bezoekers naar 100%: http://andrescholten.net/...alculation-sample-to-100/

[Verwijderd]

Ik snap niet waarom mensen hier zeggen dat je van de shared hosting af moet en dan naar VPS moet. Dat je van de shared hosting af moet is zeker zo! Maar een VPS is net zo goed shared hosting, de V in VPS staat namelijk voor virtual. Het is dus geen eigen server, maar een virtueel eigen server, de onderliggende infrastructuur wordt net zo goed als bij shared hosting gedeeld.

Verder is Magento inderdaad een stuk rommel waarbij performance ver te zoeken is. Een eigen server (dus echt eigen) is hiervoor aan te raden.

[NMe]

Verwijderd schreef op dinsdag 27 augustus 2013 @ 13:07:
Ik snap niet waarom mensen hier zeggen dat je van de shared hosting af moet en dan naar VPS moet. Dat je van de shared hosting af moet is zeker zo! Maar een VPS is net zo goed shared hosting, de V in VPS staat namelijk voor virtual. Het is dus geen eigen server, maar een virtueel eigen server, de onderliggende infrastructuur wordt net zo goed als bij shared hosting gedeeld.

In een VPS krijg je in elk geval een vast aandeel van het geheugen, de CPU, etc. Dat is nogal wat anders dan "normale" shared hosting. Bovendien heb je veel meer controle over de software op een VPS, waardoor je dus inderdaad allerlei optimalisaties kan uitvoeren.

Natuurlijk is dedicated hosting beter, maar voor de topicstarter is dat allemaal waarschijnlijk veel te duur en overdreven, hij heeft het over een site met 3000 bezoekers per maand.

[ Voor 10% gewijzigd door NMe op 27-08-2013 13:21 ]

[Barryvdh]

Natuurlijk kan je inderdaad veel doen aan je resources samenvoegen en javascript onder aan de pagina ipv boven (zie ook http://developers.google....%3A%2F%2Fwww.boska.com%2F), maar je responsetijd van 3,5 sec (bij mij) is wel erg lang.
Je kan overigens heel makkelijk gewoon op F12 in Chrome, en dan bij Netwerk zien welke resources geladen worden en hoelang dat duurt. Voordeel is dat je scripts ed. wel gecached worden.

Heb je de Magento cache ook aanstaan? Daarnaast gewoon VPS aanschaffen met minimaal APC (of Opcache of soortgelijk).

Magento is gewoon traag, het laadt duizenden php bestanden, xml configuraties, databasequeries etc etc. Op shared hosting kan je dat alleen nooit cachen omdat je je geheugen deelt met iedereen. En als anderen het een keer druk hebben, wordt jouw website ook trager.

[mhvis]

Ik heb zelf toevallig net een webshop opgezet met Magento Community Edition, deze draait op het MijnDomein Plus-pakket (zoals ergens hierboven vermeld): *niet relevant*
Ik heb hier nog geen dingen zoals caching ingesteld (op de ingebouwde caching na).

[ Voor 7% gewijzigd door MueR op 27-08-2013 16:01 ]

[steefje]

Dank voor alle tips. Helaas heb ik veel van de zaken die jullie noemen niet in de hand. Ik heb geen invloed op de manier waarop zij programmeren.

Enige waar ik echt wat aan kan doen zijn de afbeeldingen. Het gros komt niet boven de 50 kb uit. De afbeeldingen die dat wel zijn, ga ik aanpassen.

[Falcon]

Ik zou het even zakelijk gaan benaderen. Heb je in je contract met de ontwikkelaar iets staan over performance aangaande de code?

Bij mij is de website bagger traag.

[ Voor 13% gewijzigd door Falcon op 27-08-2013 16:53 ]

[NMe]

steefje schreef op dinsdag 27 augustus 2013 @ 16:19:
Dank voor alle tips. Helaas heb ik veel van de zaken die jullie noemen niet in de hand. Ik heb geen invloed op de manier waarop zij programmeren.

Dat heb je wel, want het is in ons vakgebied redelijk bekend dat mensen al na 2 seconden naar een wit scherm staren beginnen af te haken. Zie ook deze infographic bijvoorbeeld. Je kan het dus op slecht werk gooien en eisen dat ze het fixen binnen jullie SLA.

Dat gezegd hebbende: als die server buiten hun macht is en jij die aan hun opgelegd hebt dan is het eerste wat je moet doen een eigen VPS regelen.

[Crim]

Magento hoeft niet trager te zijn dan andere pakketten (misschien de backoffice alleen). Wie regelt de hosting trouwens? Is dit ook de ontwikkelaar?

Goede configuratie van je server is in ieder geval super belangrijk bij Magento. Je moet voor snelheid APC, Memcached of iets anders gebruiken en bepaalde wijzigingen maken in de Magento, PHP, Apache en MySQL config.

Ik heb zelf een dedicated server speciaal ingericht voor Magento, als je wat hulp of tips nodig hebt mag je me altijd een berichtje sturen.

[ Voor 29% gewijzigd door Crim op 27-08-2013 17:07 ]

[MueR]

Crim schreef op dinsdag 27 augustus 2013 @ 17:04:
Goede configuratie van je server is in ieder geval super belangrijk bij Magento. Je moet voor snelheid APC, Memcached of iets anders gebruiken en bepaalde wijzigingen maken in de Magento, PHP, Apache en MySQL config.

Which makes my point: Als een stuk software dergelijke exotische configuraties nodig heeft, is het behoorlijk brak geschreven. Daar komt nog bij dat de gemiddelde klant over het algemeen nogal bleek wegtrekt van de hostingkosten op een dedicated server, en dus toch opteert voor een shared hosting account, of underpowered (virtuele) machine. Op een shared hosting gaat de hoster natuurlijk niet de hele boel verbouwen omdat iemand zo nodig Magento moet bouwen

[kwaakvaak_v2]

Niet elke VPS leverancier heeft zijn config standaard overbooked op 25%. Enkel die van 8 euro per maand. En zo 'exotisch' is APC nu ook weer niet. Sterker nog, als je een beetje serieus met je productie omgeving omgaat is het gewoon een must have.

Wat bij magento meer helpt overigens is een goed ingestelde front proxy als varnish ervoor. 9/10 van de 10 requests zijn anoniem of status loos en kunnen prima minuutje of langer vast gehouden in geheugen van varnish zodat je backend helemaal niet wordt aangeproken en meer ruimte heeft voor de requests die wel zwaar zijn. Maar goed, als je APC/Memcached als exotisch noemt, dan vraag ik mij af welke schaal je varnish in indeelt

[Verwijderd]

Magento is traag dat is waar.
Maar met een goede hosting en slimme webdesigers kom je al een heel eind.

1) Installeer niet teveel extensions, alleen wat je echt nodig heb.
2) Een goede hosting die ook caching ondersteund voor Magento
3) Installeer Varnish heel erg belangrijk voor een site met veel bezoekers!
4) Ga met professionele website bouwers aan de slag, als je met Magento gaat werken

Onderstaande website is totaal irrelevant voor deze discussie.

[ Voor 28% gewijzigd door NMe op 19-01-2014 13:13 ]

[NMe]

Een bedrijf dat een designer iets laat doen aan software-optimalisatie heeft iets niet helemaal begrepen.

[ Voor 4% gewijzigd door NMe op 19-01-2014 13:40 ]

[dylanvana]

@MueR, Kan je ook iets anders doen dan zeuren?

@topicstarter, een eigen VPS is niet nodig voor een (kleine) Magento webshop. Er zijn ook webhosters die zogeheten "Magento webhosting" aanbieden. Als je een VPS zou afnemen moet je ook iemand gaan betalen (waarschijnlijk de hoster) om de server te onderhouden, oftewel een Managed VPS. Als ik jou was zou ik kijken naar webhosters die zich specifiek richten op Magento.

[ Voor 23% gewijzigd door dylanvana op 19-01-2014 14:04 ]

[NMe]

dylanvana schreef op zondag 19 januari 2014 @ 14:01:
@MueR, Kan je ook iets anders doen dan zeuren?

Nee, dat is lekker fijn onderbouwd...

[dylanvana]

NMe schreef op zondag 19 januari 2014 @ 14:13:
[...]

Nee, dat is lekker fijn onderbouwd...

Wat snap je niet?

[efan]

niet performance gerelateerd, maar kan die kolom met producten niet iets verder naar rechts in plaats van dat die overlapped over de linker grijze menu kolom? Stoort me een beetje qua uiterlijk...

[NMe]

dylanvana schreef op zondag 19 januari 2014 @ 14:16:
[...]

Wat snap je niet?

Dat je zit af te geven op iemand die maanden geleden een onderbouwd verhaal heeft gehouden en dat vervolgens zonder eigen onderbouwing afdoet als zeuren. Ik had ook kunnen reageren met "Kun jij ook iets anders dan zeuren?" en dan was dat precies hetzelfde overgekomen.

Hoe dan ook hoort dit niet in dit topic thuis dus laten we dit deel van de discussie hier maar afkappen...

[dylanvana]

NMe schreef op zondag 19 januari 2014 @ 14:33:
[...]

Dat je zit af te geven op iemand die maanden geleden een onderbouwd verhaal heeft gehouden en dat vervolgens zonder eigen onderbouwing afdoet als zeuren. Ik had ook kunnen reageren met "Kun jij ook iets anders dan zeuren?" en dan was dat precies hetzelfde overgekomen.

Hoe dan ook hoort dit niet in dit topic thuis dus laten we dit deel van de discussie hier maar afkappen...

Toch leuk dat je niet inhoudelijk kan reageren en daarom gaat graven in mijn post historie. Ik vind overigens iets aankaarten niet hetzelfde als zeuren. Zo kan ik ook zat vergelijkingen maken. Jij hebt vast wel eens gescholden en ook tegen iemand gezegd dat schelden fout is.

Ik wil hier overigens ook geen discussie van maken. MueR zat gewoon te zeiken op Magento en daar schiet de topic starter niets mee op aangezien hij met een probleem zit. Dat Magento een zwaar (wellicht lomp) pakket is inmiddels wel duidelijk gemaakt.

Trouwens, waarom kan een designer geen software optimaliseren? Waarschijnlijk werkt de designer vaker met een pakket als Magento en daarvoor heb je echt geen programmeerkennis nodig om wat caching settings en plugins te installeren.

[NMe]

dylanvana schreef op zondag 19 januari 2014 @ 14:54:
[...]

Toch leuk dat je niet inhoudelijk kan reageren en daarom gaat graven in mijn post historie.

Dat is precies wat jij deed.

Ik wil hier overigens ook geen discussie van maken. MueR zat gewoon te zeiken op Magento en daar schiet de topic starter niets mee op aangezien hij met een probleem zit. Dat Magento een zwaar (wellicht lomp) pakket is inmiddels wel duidelijk gemaakt.

Dat is duidelijk gemaakt door MueR, want dat was de eerste persoon in dit topic die het zei, inclusief manieren om het te optimaliseren. En MueR kán dat onderbouwd zeggen omdat hij meerdere shops heeft gebouwd in Magento.

Trouwens, waarom kan een designer geen software optimaliseren? Waarschijnlijk werkt de designer vaker met een pakket als Magento en daarvoor heb je echt geen programmeerkennis nodig om wat caching settings en plugins te installeren.

Waarom kun jij geen auto repareren? Waarom kun jij niet openhartoperaties doen? Waarom kun jij je eigen kleren niet maken? Jack of all trades is master of none.

[dylanvana]

NMe schreef op zondag 19 januari 2014 @ 15:08:
Waarom kun jij geen auto repareren? Waarom kun jij niet openhartoperaties doen? Waarom kun jij je eigen kleren niet maken? Jack of all trades is master of none.

Je vergelijkt twee totaal verschillende competentie gebieden met elkaar. Ik ga hier ook verder niet meer op reageren.

//ontopic

Kijk eens naar Magento shard webhosting. Goedkoper dan een Managed VPS om een webwinkel met 100 bezoekers/pageviews per dag online te houden

[Cartman!]

dylanvana schreef op zondag 19 januari 2014 @ 15:29:
[...]
Je vergelijkt twee totaal verschillende competentie gebieden met elkaar. Ik ga hier ook verder niet meer op reageren.

Waarom is het totaal verschillend? Designen en developen zijn net zo verschillend als het werk van een bakker en een slager.

MueR en NMe geven juist heel zinnig commentaar op de vraag die de TS stelt, dat jij dat als zeuren ziet is denk ik meer een gemis aan jouw kant helaas. Magento en een zooitje bij elkaar geraapte plugins met allemaal eigen frameworks en extra bestanden is gewoon drama voor je performance, heel veel simpeler dan dat kan het niet uitgelegd worden denk ik. Daarnaast is opcode cache (zoals bij APC kan) tegenwoordig gewoon standaard imo.

[dylanvana]

Cartman! schreef op zondag 19 januari 2014 @ 15:44:
[...]

Waarom is het totaal verschillend? Designen en developen zijn net zo verschillend als het werk van een bakker en een slager.

Een bakker en een slager komen nog aardig bij elkaar in de buurt. Namelijk het maken van een gezamenlijk product en werken met dezelfde "gereedschappen" (in hoeverre je dat kan vergelijken) Een auto monteur en een bakker daarentegen niet.

Daarnaast is het installeren van een Magento webshop met wat plugins en configuratie aanpassingen prima te doen door een "designer".

Maar goed, ik vind het wel genoeg geweest zo.

[Cartman!]

Als je het werk van een bakker en een slager bij elkaar in de buurt vind komen is het einde discussie denk ik...

[xleeuwx]

Cartman! schreef op zondag 19 januari 2014 @ 15:44:
[...]

Waarom is het totaal verschillend? Designen en developen zijn net zo verschillend als het werk van een bakker en een slager.

MueR en NMe geven juist heel zinnig commentaar op de vraag die de TS stelt, dat jij dat als zeuren ziet is denk ik meer een gemis aan jouw kant helaas. Magento en een zooitje bij elkaar geraapte plugins met allemaal eigen frameworks en extra bestanden is gewoon drama voor je performance, heel veel simpeler dan dat kan het niet uitgelegd worden denk ik. Daarnaast is opcode cache (zoals bij APC kan) tegenwoordig gewoon standaard imo.

Waar het in eerste instantie om ging was om dit:

Een bedrijf dat een designer iets laat doen aan software-optimalisatie heeft iets niet helemaal begrepen.

En dat kan een designer nou juist gedeeltelijk wel. Als je een icontje van 15x15px gebruikt en vervolgens een plaatje van 2000x2000px gebruikt kan je hierop flink besparen.

[NMe]

Ontwerpen omzetten naar iets dat de developer kan gebruiken wordt doorgaans door de developer gedaan, niet door de designer. Sowieso heeft dat niks te maken met de context waar we het over hadden, want hier ging het over Magento-instellingen en serverinstellingen om Magento lekker te laten draaien.