Daz

Statistika

Pridružen/a:
24 avg 2011, 06:10
Zadnjič aktiven:
Prispevki:
Teme:
4 | Vse teme
147
5
1
#6

@dh5114 mogoče bi se dalo kaj narediti s html5 web workerji (če ni cdn-ja)... sem pa že malo pozabil če bi to kaj vplivalo na vrsti red nalaganja preko require.js, ki ga Magento uporablja.


všeč(0) ni všeč(0) spam(0)
#4

Predvidevam na strani artikla? Težava je v tem, da se slike naložijo naknadno preko Ajax klica šele po tem, ko se renderira stran in ostali elementi (add to cart, cene, konfig. opcije...), zato pride do zamude pri prikazu slik. Pri tem menjava teme na Lumo ne bo pomagala, ker gre za core sistem in način renderiranja strani kar je kot si omenil splošna težava.



Je bilo kar nekaj pritožb na to temo, začasna možna rešitev pa je na voljo tukaj (nisem testiral).


všeč(1) ni všeč(0) spam(0)
#2

Pred časom smo aktivno delali na Magentu 2, kjer je bilo kar nekaj izzivov pri optimizaciji hitrosti :) Ne vem sicer koliko artiklov imate, kakšen workflow je zadaj, konfiguracija sistema ip... a vseeno spodaj nekaj izkušenj, ki bi vam morda lahko prišle prav:



1. Vklop Flat categories in Flat products

Ta opcija v bazi združi vse potrebne atribute v eno vrstico, kar občutno zmanjša poizvedbe za določen produkt.

Stores --> Catalog --> Storefront --> Use Flat catalog product/category



2. Združitev CSS in JS datotek

S tem se bo zmanjšalo število requestov za oba tipa datotek. CSS merge načeloma deluje brez težav, pri JS pa testirajte vse opcije in če vse funkcionalnosti na front-end delujejo normalno po tem, ko se vklopijo (bundle, merge, minify). Obstajale so težave z uporabo require.js.

Stores --> Configuration --> Advanced --> Developer -> CSS/Javascript settings



3. Vklop keširanja

Priporočljivo je vklopiti vse vrste keširanja, ki so na voljo v administraciji. Ob tem je priporočljivo čim manj refrešanja posameznega keša v kolikor ni nujno potrebno.

System - Cache management



4. Optimizacija teme

Če imate kupljeno temo oz. temo, ki ni v osnovnem paketu Magenta preverite ali je njena struktura pravilna, da ni podvajanj v templating strukturi (posebej xml layout) in kakšnih drugih anomalij, ki bi upočasnile stran (dodatne skripte v temi, ki bi lahko uporabljale Magento 2 framework ali UI, pa jih trenutno ne ali niso optimalno spisane ip...).



5. Optimizacija slik

V kolikor imate veliko vnosov produktov dnevno in s tem slik je dobro, da so optimizirane preden se naložijo v administracijo, ker optimizacija slik s strani platforme dodatno obremeni resorse strežnika. Izognite se uporabi PNG ali GIF formata v kolikor gre za produktno sliko.



6. Cache control in gzip

Na strani strežnika je dobro nastaviti cache control + gzip za vse tipe datotek, ki se servirajo na front-endu.



7. Administracija

Če se v času povečanega obiska na strani istočasno zelo intezivno uporablja administracija (vnos artiklov, konfiguracija ip...), se stran lahko zelo upočasni. V kolikor imate veliko dnevnih vnosov artiklov (ročno ali avtomatizirano) in večji dnevni obisk (10k+) je dobro, da se uporaba administracije omeji med časom povečanega obiska.



8. Deploy workflow

V kolikor delate modifikacije teme ali modulov priporočam, da delate deploy in nadgradnje izven časa, ko je obisk strani povečan. Najboljši čas je ponavadi v večernih urah :)



9. 3rd party moduli

Če imate inštalirane 3rd party module preverite, če pravilno delujejo in ne upočasnjujejo strani. Pri veliko modulih je CSS klican posamezno in ni narejen v skladu z Magento templatingom (less), kar doda dodatne requeste. Enako velja za js, če se ne uporablja require v kolikor je potrebno.



10. Nadgradnje sistema

Ta je seveda očitna - če je zadnja verzija stabilna, je vedno dobro nadgraditi - performance, security & feature wise :)



11. Uporaba Varnisha ali Redisa

Če imate možnost uporabite Varnish ali Redis, kar lahko občutno pohitri serviranje statičnih strani. Oba je ponavadi najbolje uporabiti na ločenem strežniku, ki bo namenjen samo za serviranje končne vsebine. Več v M2 dokumentaciji

Stores --> System --> Full Page cache



12. VPS ali dedicated server

Magento 2 na shared hostingu ni uporaben, zato je priporočljiv zmogljiv VPS ali dedicated, ki bo zmogel procesiranje/load. Optimalna konfiguracija (ram, proces., storage) je seveda odvisna od strani, velikosti baze, št. obiskovalcev ip...



13. CDN

Če je možno, je priporočljivo vzpostaviti CDN za serviranje statičnih datotek (js, css, ikone ip...). Tudi tukaj se lahko uporabi Varnish/Redis, bodisi na primary ali dodatnem strežniku.



14. PHP7

Magento 2 na php7 deluje bolje in hitreje. Poleg tega (kot je sonysony omenil) preveri php memory limit in mysql cache limit.



15. Dodatno

Pri heavy traffic trgovinah se lahko loči administracija, postavi load balancerje ip... A to je že bistveno večji podvig :)






Hitri test



Če želite na hitro testirati, kje je ozko grlo glede hitrosti lahko naredite naslednje:




  • kopirajte trgovino na testno poddomeno

  • izklopite vse 3rd party module (v kolikor obstajajo) in nastavite privzeto (blank) temo

  • vklopite vse keše

  • vključite flat

  • na serverju omogčite gzip in cache control

  • uporabite php7 (če je možno)

  • v kolikor lahko, omogočite varnish



nato pa merite rezultate tako da primerjate live stran s testno med tem ko:




  • vklopite vašo temo

  • vklopite vsak 3rd party modul posebej

  • vklopite ostale funkcionalnosti (flat, js/css merge in minify, gzip, cache...)



Tako boste dobili povratne podatke glede potrebnih korakov za optimizacijo.






Upam, da bo zgoraj napisano kaj pomagalo.

Priporočam, da vse našteto delate izključno na testni strani in temeljito testirate preden gre v živo, ker pri M2 gre lahko hitro kaj narobe :)


všeč(21) ni všeč(0) spam(0)
#8

Nebi smelo, linki so tam le da prekrijejo input in mu dodajo moznost razlicnih povezav ali kaj drugega.


všeč(0) ni všeč(0) spam(0)
#6

Lahko npr. tudi dinamično dodaš linke, ki služijo kot "tagi" ali pa vodijo na željen(e) url naslove - primer take rešitve.


všeč(0) ni všeč(0) spam(0)
#75

Harvey Norman išče dva nova sodelavca - link do oglasa


všeč(0) ni všeč(1) spam(1)
#3

Sam ponavadi najprej preverim najbolj pogoste ločljivosti obiskovalcev in na podlagi tega določim breakpointe:



1. Desktop

- min 1024px ali min 1280px



2. Tablice

- max 960px (občasno)

- max 800px

- max 768px



3. Mobilci

- min 480px in max 640px

- min 320px in max 480px



če se pa že prej vse lepo zloži pa:




  • max 480px

  • max 320px



Včasih je treba narediti več breakpointov + switche (landscape, portrait), včasih pa le nekaj - odvisno od zasnove dizajna strani in postavitve elementov ter ločljivosti obiskovalcev. Primer uporabe breakpointov.


všeč(1) ni všeč(0) spam(0)
#186

Hvala dinozzaver - sem preveril še 1x in pravijo, da plačaš 28% na worldwide sales:




In absence of a valid Form W-8, the IRS requires us to assume you are a US Person who has not completed a form, meaning all your sales will be subject to Backup Withholding tax of 28% (see the section on US Persons above).




What Happens if I Don’t Complete a W-8 Form?


všeč(0) ni všeč(0) spam(0)
#22

Websitemaker:

Hvala, Daz .. kolikor se gledal, bom nabavil RSFirewall ... imaš ti kaj konkretnih izkušenj s tem?




Največ z Admin Tools in je kar ok zadeva za hitro konfiguracijo nekih nujnih nastavitev.

Ampak kot je Matjaž omenil - taki plugini ne bojo veliko v pomoč pri že okuženi strani. Prvo sanacija strani in nepotrebnih modulov/pluginov (ti so velikokrat vzrok težav + kakšni "free" templejti), potem pa naprej z dodatno zaščito.


všeč(1) ni všeč(0) spam(0)