 Vinguts al track 2, em dic Núria Nadal i aquesta dada seré la presentadora de les ponències d'aquest track. Ara tenim una xerrada que entendrem què està passant en el moment que visualitzem una pàgina web i sobretot parlarem de velocitat i aprendrem com corregir alguns problemes per aconseguir que la nostra pàgina web sigui molt més ràpida. Amb la ponència, enteni millor la velocitat del teu web amb un WordPress que ens la donarà en Joan Vega. En Joan Vega va néixer a Barcelona. És la ciutat on va créixer. Va compartir l'adolescència amb la informàtica personal, tot i que va estudiar altres matèries, però sempre ha acabat treballant amb coses vinculades amb el món de desenvolupament. I des de fa set anys treballa 8opi, un allotjament gestionat a exclusió per WordPress i és el soci fundador. Joan, molt important, deixem les preguntes pel final de la xerrada i així tindrem que el Joan es pugui concentrar únicament en la ponència. Moltes gràcies, Joan. Gràcies, Núria. Benvinguts, benvingudes. Per afegir una miqueta de contexta, què faig aquí parlant de WordPress Velocitat? He de dir que apallar el 2008 és quan jo d'alguna manera veig passar WordPress per primera vegada. Aleshores jo feia desenvolupament a mida de gestors acontinguts, gestors acontinguts de pagament i potser per contexta de crisi començaven a venir als truples, humbles i WordPress. El WordPress, cada cop vaig veure passar més. Fins que el 2015 decideixo dir, va, volcomo, de ple a treballar en WordPress i per altres motius decideixo farem un allotjament purament dedicat a WordPress. Per què dic tot això? Doncs perquè una de les tasques que vam fer i que seguim fent el dia a dia és more webs que pel hosting i hi ha un denominador comú i és que tothom vol que la web carregui més ràpid. I s'entén. Perquè en una banda volem que els usuaris n'arreguin ràpid pels nostres catàlegs de comerç electrònic perquè està clar, si veuen tot el catàleg tenim més probabilitat de vendre, no? Google tome el clar això. M'interessa que tot vagi més ràpid. A més a més l'interessa que les màquines vagin i passegin per totes les seves webs de forma més ràpid perquè és economitzar. I jo diria que afegiria, després d'haver fet la xerrada del Navoi aquest matí, diria i és important, perquè parlava de sostenibilitat, és important que cada cop més una web que carrega ràpid en el fons serà una web que gestionarà millors recursos i consumirà menys. Per tant, no ha començat a pensar en posar aquest terme de Ei, no només faré tot això a funcions sinó que a més de més consumirà menys. Un èxit al objectiu de la xerrada és que la velocitat és un camí de llarg recorregut. Però si enteneu una mica les diferents fases per on passar la velocitat podreu veure allà en cada una d'elles què és el que de mirar i si us puc ajudar a veure aquella primera acció en prendre. A mi m'agrada dividir tot el que és el procés de carregar una pàgina quan posem el nom de la pàgina al nostre navegador amb dues grans etapes. La primera té a veure amb tot el que ha passat fora del nostre ordinador, és a dir, servidors DNS, xarxa, proveidors... I un cop carregarem la pàgina al nostre ordinador hi ha tot un món que realment és complexa i passa moltes coses també. I hem de treballar-hi molt, que és tota la part de pintar la pàgina. Comencem per aquí i com podem veure el que passa aquí quan estem servint a la pàgina. Hi ha una eina que ens funciona molt bé i ens permetre veure les mètriques de tot, que és la de velo pertuls. I aquí ja començo a veure si no em passo amb la xerrada. Tots coneixeu o algú ajudem-me. Hi ha aquells que d'alguna manera heu obert la de velo pertuls per gestionar. Uau, quina pressió. Vale. Doncs molts ja sabeu com entrar les de velo pertuls. Hi ha un comandat d'Ínyias, podreu accedir també a través de tots els navegadors. Les de velo pertuls, tot i que són molt intimidants de la veureu, s'assemblen a través de tots els navegadors, especialment tots aquells que es basen en el mateix motor de pintat. I, quan desobrim, ens divideixen la pantalla en dos. És molt intimidatori. És tot un món d'opcions i pantalles. Però per començar en el món de la velocitat i veure què passa, ens hem de fixar en una pastana, que és la que vossa en network. I aquí baix, on tenim tots els recursos, que realment s'està carregant el nostre paper de web per començar a pintar, ens fixarem en el primer d'altres recursos, que és la pàgina TML. De moment, per començar, en tenim prou per veure això. Sobretot per veure què passa del nostre ordineu de cap a fora. Un cop pitgem sobre el primer recurs, obrim la segona pantalla... Bé, sobre la segona pantalla. Hi ha una pastana, anòvament, que és la del timing, que ens mostra totes les etapes de les que es parlava, per les quals passa el procés de viatjar una pàgina web fins al nostre navegador. Timing. I les etapes són aquestes d'aquí. Com a mínim, les més prominents. Hi ha una primera tasca, que és descobrir el servidor. Què vol dir això? Que és el diners lo cap, la primera barreta verda. La primera cosa que ha de fer un navegador, quan li poses un nom, un enllaç amb un nom, és descobrir quina és l'adreça física, on és aquest servidor que em servirà la pàgina. Per fer aquest primer viatge ha d'agafar les DNS, que no són més que aquells llocs on apuntem l'equivalència entre el meu nom i una dsip, que és per a un viatge, com sabem viatjar fins a la informació, serien més similar a les pàgines drogues, perquè és que sigui d'aquella època. Un cop ja descobrim, perquè les DNS es informen de on està el servidor, el que hem de fer és ja sé on anar, el nostre navegador, obre una connexió, que la porta, perquè m'obre la porta, però avui en dia ja no només volem una connexió normal i corrent, sinó que la volem segura. Tots viatgem amb malacte TPS, això implica i és bastant ferrosos per al servidor. Implica intercanviar una clau pública, una clau privada entre servidor i el nostre navegador. Per sort, els servidors més o menys moderns treballen la barra taronja, i l'Illa les treballen en paral·lel. És bo que teniu servidors que treballen amb els darrers protocols perquè fan aquesta tasca en paral·lel i és important. Les primeres connexions després les guarden amb caixa, però en primer punt és un punt de consumir important. I després ve aquesta barra verda més provínent que serveix, el servidor construeix la pàgina. Aquesta és la més... normalment on hi ha més feina. És una mèdica que té el nom de Time to First Byte, la sentireu parlar en molts llocs, i és una mèdica que ens permet mesurar molt bé el lloc que és el concepte de quan vas al meu servidor perquè implica tot el temps de construcció de la pàgina al servidor. És allò que el WordPress agafarà, el PAK, té per un costat la base de les per l'altra, els plugins i començarà a tots els cicles per construir aquesta pàgina HTML, que és la que ens entregarà. El Time to First Byte fa, a part de construir, fa l'enviament d'aquest primer byte que arribà al nostre navegador. Per això és com una bona mèdica per comparar, perquè és tot el temps de construir més el primer byte. I en darrere hi ha la descarrega de la resta d'aquest HTML que estem baixant, a content download. Un primer cas. Aquest primer cas, si ens miressin les mèdiques de la primera pàgina, hi ha una cosa que no està del tot bé. És a dir, el DNS, el que és el com que és una tasca eficient, ràpida i l'hauríem de fer de forma ràpida. No sempre és així. D'acord, això ho hem de mesurar amb cura perquè el DNS és una cosa que és guardar-se d'informació pel camí. Potser haureu patit lo de refrescos de la caixa de les DNS. Però, si feu un test amb net, amb xarxa, jo puc primer cop que avui no heu vist la pàgina, vaig a provar-la, sé que ningú utilitza la pàgina, ningú en la caixa de DNS em respondrà, farà tot el recorregut per anar a buscar la vida a descobrir. Podríem mesurar la forma més o menys realística que és el DNS. I jo penso que és una neta que és important, perquè penseu que la majoria dels usuals primarem que vinguin a la vostra web ho faran per primer cop. Sobretot si feu una campanya, si feu una campanya a Google i a Manuncis, si la primera descoberta no és ràpida, doncs malament. I les DNS són importants. Un consell, fer servir DNS en protocols en icast. Què vol dir això? El protocol aquest és el que com similarà el que són les cdns. És d'aquí... El moment que jo me'n vaig amb meu providor de registre de domini i li col·loco aquella equivalència entre el meu domini i l'IP, aquests servidors d'NS n'hi ha que fan desar un a aquest servidor i reaplicar-ho a través del cloud. Què passa? Que quan jo faci la petició ho faran al punt més ràpid. De fet, agafarà la resposta del primer DNS que respongui. I això és una manera de jugar-nos a fer-ho més oficial. Tenim serveis de DNS fins i tot gratuïts, que ho fan molt bé. CloudSplurn és un, té més de 300 nodes repartits, d'on dominio, que els tenim avades també per aquí. Són també molt bons i tenen DNS en icast, i evidentment els grans, Amazon, Google, també tenen aquests serveis, tenen molts nodes, també són de pagament. Un cas 2, i aquest cas és un cas real. No cal que us digui que la barra verda és la que és problemàtica. Són 7,6 segons el temps que et triga per fabricar aquesta pàgina. Si a més a més tenim en compte que això és unicòmer que realment has de servir un catàleg que és gran, alguns pensareu que els faig caixers i les prefabriu i solucionar el tema. No estan així. 7,6 segons quan teniu el servidor probablement ocupat, si tens mil productes són 3 hores. 3 hores igual prefabricar-la, que és 4 o 5 hores. És molt bèstia. Es fundaràs al servei o no donaràs un bon servei a la resta dels usuaris, no? Evidentment estem aquí amb un tema de sobrepes. Ens hem passat. El primer que tots diem és, ostres, utilitzar els planes mínims. I posa un estès perquè sempre dic que no tots els plugins interfereixen en el procés d'afegir temps, en la construcció. Com una guia, i així ràpida, sense en tant de des, fixa-vos que tots aquells plugins que facin funcionalitat en el procés de pintar, d'alguna manera, estan interrompent i afegint més coses. És com si jo pinta la paret, poso un endoll, he de tornar a pintar la paret, poso ara un quadre, he de tornar a pintar la paret, li esteu fent molt cicles i moltes interrupcions per pintar. I això és molt costós. En la línia de retirar feina, aquest vorprès, perquè vagi més ràpid, hi ha tasques que hauríem de trobar com és els tallafocs. Hi ha planes molt bons de tallafocs. Està molt bé si tu pots permetre en temps de procés. Però fer-li fer una tasca de... de cercar les IPs que han entrat, quants usuaris de login estan entrant en pagina, abans de fer la pàgina, és donar-ne molta feina al vorprès. Perquè en busqueu manera de buscar serveis que tinguin un bon tallafoc fora, que se n'ediquin de forma eficient amb infraestructura dedicada, si pot ser, i allibereu d'aquesta tasca al vorprès. Més en la línia de lliberar el vorprès, aquestes tasques que no hauria de fer, és el tema de les redireccions. És un altre tema que els serveis de pàgines web ho fan molt bé. Cert, hi ha plugins que funcionen molt bé perquè t'ajuden a configurar totes les redireccions. I quan deses, fabriquen un arxiu que se'n va al servei de pàgines web i és ell qui els llegirà i carrega les pàgines i s'encarrega de les redireccions en aquest cas. Però no fer-ho fer treballar a la base dades, que és el que fa molt de temps. La base dades fins fa relativament poc temps era un gran coll d'empoia d'Auroprés. Derrerement en discurs SSD i sobretot amb l'entrada dels motors i no d'EB que hi ha escaix com una estanda, allà no d'EB és com el motor que hi ha darrere de la gestió de les taules, de la informació, del collana, el nostre Maia SQL o MariaDB. Què fa és molt bo perquè és capaç de col·locar que si tots els indensos hi ha informació que necessita o la col·loca en memòria, llavors tot va molt més ràpid. Normalment si tens la capacitat en memòria per poder-ho fer, treballa al MinóDB. I com no? Evitem aquells temes que fan de tot, fan de tot per defecte i que sí, està molt bé, s'està bé en treball, però el que fas és donar-li molta feina a l'Auroprés. Què passa quan ja no puc aprir-me més? He fet tot allò d'allà. Doncs sí, et queda l'opció de posar més infraestructura, millor servidò, millor hosting. Sempre recomano, però a l'aeroport també pot passar, perquè pot passar alguna cosa. S'està fent una consulta que no té els índexos, algú exagerat, podria passar algú. Coerimónitor és un plaer d'aquests que intimiden. Però té una manera que després us l'enfanyaré. Com anem a veure per on van les coses. I la recomano sempre s'hauríeu de fer servir, però fem-la fent abans. M'ho veiem amb infraestructura més ràpida, i sí, aconseguim construir en 2,41 segons. Què fem? Anem a mirar un coerimónitor al plaer. Quan l'instal·les és una mena de developer tools. La pandèmia se't divideix amb dos, també mostra moltes opcions. Però només la pandèmia per defecte s'ha de fer a les seves seccions. Divider tot el procés de càlculs i tot el procés de consultes. Com a mínim, fixeu-vos a 493 consultes que no estan malament per pintar una pàgina. Però en canvi dius, trigues 0,056 sols. Jo no tinc el problema aquí. Tot és temps de procés. Aquí plaguin dos ketons de caixer, poc m'ajudarà. Jo tinc un problema amb els objectes de dades. Què puc fer per passar-me o més infraestructura que no és tan fàcil? O sigui, quan diem posar un millor servidor, ojo, aneu en compte. No és posar més cores, que és una mena de mena que tenim de carciar el núvol. Més cores és com posar més files per atendre més gent. Però el coer per fer processar amb una única línia i aquella única línia, un coer, és el que haurà de pintar per pàgina. Posar més cores atendre més gent, però no baixaràs dels 2,3 segons. Aquí ja vam marxar a muntar caixer. Què passa amb un cas com aquest? Dius, tot es pinta bé, però, ostres, tinc un content d'enlou de 4, 6, 5 segons. Jo m'estic baixant texta, que és l'actemaela. I l'actemaela és el com que hauríem d'anar ràpid. Bàsicament perquè ara avui en dia fem tots els servidors en una cosa que és comprimir el vol. I ho fan molt bé perquè és un procés que fan des de la CPU ja, quasi. Podem veure si el nostre servidor fa que la informació textual viatgi i comprimida si ens posem a sort a la col·leona dels Sais, allà, les Developers Tools, els recursos ens mostrarà el... un volum transferit a través de la xarxa i el volum descompriment. Si hi ha aquesta diferència és que el servidor està comprimint pel camí. Ok, ho estic fent bé. També, perquè és més agosarat, podem mirar les hides, que és una altra pastaneda que hi ha, i us dirà el content encoding, que us dirà el tipus de compresor que està fent servidor. Aquí és on de clara hei, estic comprimint, estic fent servir aquest encoder. Recomanació, darrerement tenim compresors tipus bròdics que es comprimen superbé, si comprimeixen quasi sense consum de recursos i ho faran encara de forma superaficient. Gésip és el clàssic, però si no teniu compresor pel camí, tampoc agafeu un plàguin de caixer que molts anien que diuen, vale, anem a fer gésips dels documents en TMLs. Tampoc és una feina al WordPress, si en aquest cas s'hi fa portar menys. Aquí ja hem pintat la pàgina, ja m'ha quedat aquesta primera etapa, tot el que ha passat fora, l'acta Mela Bers, i després que ja arribem a la nostra navegador, munt de dades, CSS, JavaScripts, imatges, penesers, totes comencem a construir, i aquest és un món complex. Aquest cascada waterfall és el que podem veure també en la developer tools, que passa en moltes coses, l'ordre importa, el volume també, fins no fa molt, teníem dues mètriques que feien servir, que eren aquestes dues ressaltades a baix, però que no ho acaben de demostrar, o desregarà el que és una bona experiència d'usuari, i Google, novamente, porta temps darrere de buscar unes mètriques que ens ajudin a dir, bé, ho estic fent bé o no ho estic fent bé, i és quan entrenen totes les webvitals que han anat canviant allà del temps, és com qualcom que tots coneixem. Què passa que d'alguna manera aquestes webvitals et fan fer treballar-ho tot bé, des del que hem vist fins ara de fora del meu servidor, fins al que és el procés de pintat, i qui posa la pàgina i què no. On podem veure mètriques que ens ajudin, normalment en les developer tools? Hi ha una pastanya, que és el Lighthouse al final, i els Lighthouse són el que em diuen mètriques sintètiques de la laboratòria. És tot allò que puc mesurar entre el meu ordinador i el que passa al món real, no el que fan els usuaris. En tornar a tot un contingut de mètriques, també podem veure les mètriques, les webvitals, les Search Console, si tu fas servir Google per indexar a cap de 28 dies també reportarà informació de no només les sintètiques que faràs també sinó dels teus usuaris. Quins resultats de mètriques de velocitat estan tenint els teus usuaris? Quines passen, quines no passen? No et donen, però és una idea de tot el que pot passar a la teva web. I si després tenim el PageSpeedInside, que ens dona ja informació més detallada, podem fer test sintètic en l'instant, però ens dona també informació de quina és la resultat d'experiència dels usuaris a la xarça, que són les proves de dalt. Normalment apareixen a passats 28 dies si tens un tràfic suficient. I aquí ens dona una sèrie de paràmetres, però ens fixarem amb 3, que són les que Google no diu que són les constants vitals. Diu, si tu controles aquestes 3, més o menys tu estàs fent bé les coses, els usuaris tindran una bona experiència. La primera d'aquestes vitals és la LSP, o les Descontento Paint, que ve a dir, en 2,5 segons, Google considera que és una bona experiència si en 2,5 segons es carrega el camp de visualització i aquell metge més permanent o contingut més permanent, potser texta. No és una mesura real de tot el que passa, però, com a mínim, em permet fer una mesura. Perquè s'entengui, això és com una pel·lícula de tot el que es va carregant en aquest camp de visualització. Google va fixant-se en tota la informació que apareix i es queda amb la més culminant, amb tot un ampli de temps. Allà talla i marga. Això és la LSP. Què he de fer perquè les coses funcionin bé? Evidentment, tot el que hem parlat abans, d'aquell mundo web server dns, es funcioni bé. Això ho he de fer bé. I després fixar-nos en la imatge, col·locant en el camp de visualització de l'usuari. Optimitzem-la. Una segona constància és el FID. Aquest és el First Input Delay. I no té a veure amb velocitat de carregalitat, sinó... Es considera que l'usuari té una bona experiència d'usuari quan, a l'hora d'interactuar amb la pàgina, la pàgina respon la forma eficient i ràtiga. I es considera una bona resposta quan en més de 100 milis de segons les coses funcionen. Apreta el butó i va, o entra un camp de texta i ja ja funciona. Què pot passar perquè això no vagi bé? Quina és el gran problema? JavaScript. JavaScript el que fa és ocupar moltíssim en la nostra navegador. Mentre està treballant a JavaScript, no li deixa tintant ni treballant amb l'usuari. Què podem fer? Una cosa és diferir. Haureu trobat aquesta opció amb molts plaquins de gestió de caixer o d'optimització. Que el que ve hi ha d'hi, és... Tot aquell JavaScript que no necessites per tot el que és el procés de pintar principal, envia-la al final i allibera-la a fer-ho perquè l'usuari pugui interactuar. En aquesta línia jo faig un jocet, elimina el JavaScript. No existeix aquest tribut de lete, sinó tot aquell JavaScript que no necessitem perquè estàs ocupant la CPU. Especialment amb la navegador dels mòbils. Això es pot ser important. Hi ha una última d'aquestes vitals que és el Comunitativ Light of Shifting. Aquesta també és de les que no s'entenen. Què vol dir això? Què vol dir això? Tampoc agrada els usuaris que les coses es moguin molt. És molt mala experiència, i això tots els molesta. Vaig apretar un botó i m'ha pres un bane. Es considera que no és una bona experiència de l'usuari que les coses es moguin en el camp de visualització. No em refereixo que es moguin quan estàs fent escró, però quan no tinguem una pantalla parada, deixem les coses quietes. I sí que passa una cosa darrerement, i és que els que hem fet web responsifs ens hem anat oblidant de senyalitzar que és l'amplada i l'alçada de les imatges. Per a aquests, les webs són fluides. Quina amplada i l'alçada? Hi ha una cosa que és important. Li hem de donar l'alçada i l'amplada de totes les imatges perquè no s'hagi de descarregar la imatge. Quan ja tinguis l'acte ML i el CSS que va ràpid, hi ha pugui calcular-se. Amb un aspect ratio, amb el ràpid de la imatge, ell sabrà calcular la forma molt ràpid a l'espai de la imatge. Per tant, anem amb compte que aquells logos que posem a l'escapçalera és tal col·loquem les dimensions bé. Això és una de les opcions. A les core web vitals, Google dona pistes de tot el que anem i podem anar fent arross i hem de poder anar a reparar. Evidentment, el camí d'allà recorre vol dir qui és posar-s'hi i anar fent ceina. I el que anem amb la màxima m'ha aprofitat al dali i aquells àrees de diquit no s'obsessionava amb el tema de velocitat perquè el temps és relatiu, ni les web vides d'aquestes depèn del públic del teu usuari. A vegades dues webs fetes iguals amb les metages eines. Amb públics diferents tindràs mesures diferents, de l'última generació. Allà anirem ratíssim i les vitals miren superbé. Hi ha un usuari que igual, teu públic és mòbil, doncs les vitals no seran tan així, pitaràs més. En fi, lo de la velocitat és relatiu, invertir un temps al necessari. Tampoc ho s'obsessionaven passant al 99 al 100. Moltes gràcies. Hola, gràcies molt, informatiu tot. Jo tinc una qüestió quan el deferre del JavaScript... Quan el deferre del JavaScript has trobat cap diferència entre l'efecte que fa a posar-li el deferre i posar la carregada del script al footer? A la 5 o al footer. No, de fet, posar-los al footer ja és això. Esportar-los al final del procés de pintat. Ja has tractat això, que a vegades els tenim intercalats, no? Ja també el deferre, a la 5 o a la 5, no es recomana a plaer, perquè la 5 vol dir quan no ho pugui. Llavors sí que et va res a l'hora de pintar. El deferre costuma ser una cosa bastant raonable a fer-ho. Ostres, sí que cala, clar, tot. Moltíssimes gràcies per la xerrada. Joan, creadora de continguts, com podria equilibrar la necessitat... Com podria trobar l'equilibri entre el contingut atractiu, amb imatges, amb algunes transicions i les funcionalitats en una pagina web sense haver de comprometre la velocitat de càrrega i que sigui una càrrega eterna per tal que l'usuari tingui una experiència molt més plantera en el moment que accedeix a la pagina web? Bueno, sempre és un compromís. El compromís és gairebé des d'inici, evidentment el que deia. A vegades recursos prenen la cura de treballar, els recursos de cocopint poc espai. Si en lloc de col·locar la informació que tu vulguis, el ritme que tu vulguis de volum i pes i d'això que es pleguin facin la feina, doncs sigues curós. Treballa les imatges amb la càrrega i retira aquest pla d'optimització, el vol que fa tot el procés de càrrega. És una manera de posar consciència amb això des del principi, i sobretot que seré conscients que tot allò que anem afegint el WordPress compta, i compta bastant. Hola, has comentat, has parlat del tema de les redireccions, de millor deixar-les fora del WordPress. Això inclou el mapeig que fa WordPress MultiSight, per exemple. Ah, aquest refereixes el mapeig que fa. Per exemple, quan tenim un MultiSight amb varios subdominis, etcètera, que el mateix WordPress pot posar un domini que apunti a uns subdominis. Sí, és que això no ho pots evitar. A la fi, te n'has d'anar a que el WordPress et digui que ella està gestionant múltiples sites. I sí que en el moment que tu li entregues una borrera, et trobes certa informació que hi ha una borrera que el WordPress ha de fer a quin MultiSight va. No tens manera de dir-li, vés directe. No es consideraria una redirecció. Gràcies. Si no tens la opció de cacher el servidor, quin pluguis fa servir? Bueno, si el site està més o menys bé i fa servir plugins que facin bonus de les regles per fer un pressupress, hi ha un d'economi que gestiona més a més automàtic, que és WordPress Supercacher, que està molt bé. Fa moltes coses i quasi mai li diré que a mi mai m'ha trencat el site. Si tens una web guarreta i hi ha altres opcions, hi ha algunes, hi ha plugins en nom, vipirrockets o Lightspeed, també fan molt bé les coses. I sobretot fan algunes coses molt bé com més, per exemple, les mètriques sintètiques d'enganyar. S'aprofita del fet que el plugin aquest de caixers es queda amb el control del JavaScript. Diu, jo no activo el JavaScript fins que l'usuari no mogui el retolí o faci una interacció. Això m'agradarà tant perquè dir que com els crawlers carregaran la pàgina i no m'hauran d'interfície, aquells JavaScript mai carrega i les mètriques teves són alucinants. Les de l'usuari no, les orgàniques petaran, però les sintètiques quedaràs molt bé amb el client. I llavors sí, és una opció, però bueno, la resta de plugins, la majoria que ets reconeguts, fan bona feina. Sobretot ajudar a diferir, codi, ja vas fer-hi... Més o menys, enllà amb molt més. Alguna pregunta més? Moltíssimes gràcies, Joan.