Els Core Web Vitals s\u00f3n tres m\u00e8triques que descriuen l’experi\u00e8ncia de c\u00e0rrega tal com la viu un usuari real. El LCP mesura el temps d’exhibici\u00f3 del contingut principal. El CLS quantifica els salts de disseny mentre la p\u00e0gina es construeix. L’INP mesura el retard entre una acci\u00f3 de l’usuari i la resposta visible de la interf\u00edcie. <\/p>\n
El mat\u00eds que gaireb\u00e9 tothom passa per alt es troba en el m\u00e8tode d’avaluaci\u00f3. Google no ret\u00e9 la mitjana de les vostres visites. Ret\u00e9 el 75\u00e8<\/sup> percentil, en una finestra lliscant de 28 dies, i separa el m\u00f2bil de l’escriptori. Dit d’una altra manera, tres de cada quatre visitants han de quedar per sota del llindar perqu\u00e8 la m\u00e8trica sigui validada. Un lloc r\u00e0pid per a la majoria per\u00f2 catastr\u00f2fic per al quart d’usuaris amb 4G degradada falla. <\/p>\n Aquesta mec\u00e0nica explica per qu\u00e8 tants llocs web mostren una puntuaci\u00f3 de Lighthouse de 95 en local i es mantenen en vermell a la Search Console. La puntuaci\u00f3 de Lighthouse simula una visita en condicions fixes. Els Core Web Vitals, en canvi, provenen del Chrome User Experience Report, la base de dades que Chrome alimenta amb les visites reals dels usuaris que han acceptat l’enviament d’estad\u00edstiques. <\/p>\n Els llindars oficials de Google: LCP inferior o igual a 2,5 segons, CLS inferior o igual a 0,1, INP inferior o igual a 200 mil\u00b7lisegons. Entre 2,5 i 4 segons, entre 0,1 i 0,25, entre 200 i 500 mil\u00b7lisegons, la m\u00e8trica es classifica com a \u00abmillorable\u00bb. M\u00e9s enll\u00e0, es classifica com a \u00abdeficient\u00bb. Una URL nom\u00e9s es considera conforme si les tres m\u00e8triques passen simult\u00e0niament. <\/p>\n<\/div>\n Aquests tres indicadors tenen una hist\u00f2ria canviant. El FID, First Input Delay, va ser substitu\u00eft per l’INP el 12 de mar\u00e7 de 2024 perqu\u00e8 nom\u00e9s mesurava el retard abans del processament de la primera interacci\u00f3, cosa que deixava passar interf\u00edcies realment pesades. L’INP va fer caure immediatament en vermell milers de llocs WordPress sobrecarregats de scripts que fins aleshores mostraven un FID confortable. En les auditories que realitzem des de llavors, \u00e9s la m\u00e8trica que falla m\u00e9s sovint. <\/p>\n El Largest Contentful Paint registra el moment en qu\u00e8 l’element de contingut m\u00e9s gran visible a la finestra inicial s’acaba de mostrar. A la pr\u00e0ctica, es tracta gaireb\u00e9 sempre de la imatge de cap\u00e7alera, d’un v\u00eddeo de fons o del bloc de t\u00edtol principal. Google ha triat aquesta m\u00e8trica perqu\u00e8 correspon al moment en qu\u00e8 el visitant considera que la p\u00e0gina ja hi \u00e9s. <\/p>\n Optimitzar sense saber quin element s’est\u00e0 mesurant fa perdre setmanes. La pestanya Performance de les DevTools de Chrome mostra un marcador LCP directament a la l\u00ednia de temps, i PageSpeed Insights anomena l’element afectat a la secci\u00f3 de diagn\u00f2stics. En una web corporativa, \u00e9s la imatge hero en el 80% dels casos. En una fitxa de producte, \u00e9s la imatge principal del producte. En un article de blog, sovint \u00e9s el mateix t\u00edtol H1 quan la imatge destacada es carrega en diferit. <\/p>\n Un LCP de 4,8 segons no diu res fins que no es desglossa. El primer segment \u00e9s el TTFB, el temps que triga el vostre servidor a retornar el primer byte. El segon \u00e9s el retard abans del descobriment del recurs, \u00e9s a dir, la difer\u00e8ncia entre l’arribada de l’HTML i el moment en qu\u00e8 el navegador ent\u00e9n que ha de descarregar aquesta imatge. El tercer \u00e9s la desc\u00e0rrega del recurs. El quart \u00e9s el retard de renderitzaci\u00f3, sovint causat per un CSS o un JavaScript que bloqueja. <\/p>\n Aquesta descomposici\u00f3 ho canvia tot, perqu\u00e8 cada segment requereix una correcci\u00f3 diferent. Un TTFB d’1,2 segons se soluciona des de l’allotjament i la mem\u00f2ria cau del servidor, mai comprimint imatges. Un retard de descobriment elevat se soluciona eliminant el lazy loading de l’element LCP i afegint un atribut El precarregament mereix una menci\u00f3 especial perqu\u00e8 sovint s’utilitza malament. Declarar una desena de recursos en Google recomana un TTFB per sota dels 800 mil\u00b7lisegons per deixar un marge suficient als altres tres segments. En un WordPress compartit amb PHP 7.4 sense mem\u00f2ria cau d’objectes, aquest llindar \u00e9s inabastable independentment del treball realitzat al front-end. \u00c9s el primer punt que verifiquem durant una auditoria SEO t\u00e8cnica<\/a>, abans fins i tot de mirar el contingut. <\/p>\n El Cumulative Layout Shift mesura els despla\u00e7aments inesperats dels elements durant la c\u00e0rrega. Cada despla\u00e7ament rep una puntuaci\u00f3 que combina la fracci\u00f3 de la pantalla afectada i la dist\u00e0ncia recorreguda per l’element. El CLS retingut \u00e9s el de la pitjor finestra de sessi\u00f3, una finestra de 5 segons com a m\u00e0xim, amb un interval d’un segon entre dos despla\u00e7aments. <\/p>\n Ning\u00fa es queixa d’un CLS elevat, i aix\u00f2 \u00e9s precisament el que el fa perill\u00f3s. El visitant que apunta a un bot\u00f3 i clica en un b\u00e0ner publicitari perqu\u00e8 la p\u00e0gina s’ha mogut no omple cap formulari de contacte per informar-ne. Se’n va. En els llocs d’e-commerce que auditem, un CLS superior a 0,25 acompanya gaireb\u00e9 sistem\u00e0ticament una taxa d’abandonament anormal a la fitxa de producte. <\/p>\n Les imatges sense atributs A continuaci\u00f3 venen els continguts injectats din\u00e0micament per sobre de la part superior de la p\u00e0gina: b\u00e0ners de consentiment, barres de promoci\u00f3, notificacions d’estoc. Cadascun empeny tota la resta cap avall. La soluci\u00f3 consisteix a reservar l’al\u00e7ada pr\u00e8viament amb un contenidor de dimensi\u00f3 fixa, o a superposar l’element en lloc d’inserir-lo en el flux. <\/p>\n Les fonts web constitueixen la tercera causa. Quan una font personalitzada substitueix la font de reserva, les m\u00e8triques tipogr\u00e0fiques canvien i el text es reajusta. La combinaci\u00f3 de Els iframes i les integracions de tercers tanquen la llista. Un mapa, un reproductor de v\u00eddeo o un giny d’opinions de clients que es dimensiona a posteriori provoca un despla\u00e7ament sistem\u00e0tic. Reservar la r\u00e0tio d’exhibici\u00f3 en CSS soluciona el problema sense tocar el servei de tercers. <\/p>\n \u00abUn CLS net no es corregeix a posteriori, es dissenya. En un lloc constru\u00eft correctament des de la maqueta, amb r\u00e0tios d’imatge definides i zones reservades per a cada element as\u00edncron, la m\u00e8trica cau naturalment per sota de 0,05.\u00bb<\/p>\n<\/div>\n L’Interaction to Next Paint mesura el temps entre una interacci\u00f3 i l’actualitzaci\u00f3 visible de la pantalla. A difer\u00e8ncia del FID al qual ha substitu\u00eft, observa totes les interaccions de la visita, no nom\u00e9s la primera, i ret\u00e9 la m\u00e9s lenta o gaireb\u00e9. En les p\u00e0gines que superen la cinquantena d’interaccions, l’algoritme ignora un cas extrem per cada tram de cinquanta per evitar que un incident a\u00efllat penalitzi el conjunt. <\/p>\n L’INP es descompon en retard d’entrada, temps de processament i retard de presentaci\u00f3. El retard d’entrada correspon a l’espera abans que el navegador pugui tan sols comen\u00e7ar a processar el clic, perqu\u00e8 el fil d’execuci\u00f3 principal est\u00e0 ocupat amb una altra cosa. El temps de processament \u00e9s la durada d’execuci\u00f3 dels vostres gestors d’esdeveniments. El retard de presentaci\u00f3 cobreix el rec\u00e0lcul del disseny i la renderitzaci\u00f3. <\/p>\n En la gran majoria dels casos trobats a WordPress, el culpable \u00e9s el retard d’entrada, i el culpable darrere del culpable \u00e9s un script de tercers. Un gestor d’etiquetes que carrega sis eines de seguiment, un giny de xat en directe, un m\u00f2dul d’opinions, un p\u00edxel publicitari: cadascun afegeix tasques llargues que monopolitzen el fil principal. El visitant clica, no passa res durant 600 mil\u00b7lisegons, i torna a clicar. <\/p>\n La primera mesura consisteix a fer l’inventari dels scripts de tercers i eliminar aquells dels quals ning\u00fa consulta les dades. En els llocs que gestionem en manteniment WordPress<\/a>, no \u00e9s estrany desactivar tres eines de seguiment redundants instal\u00b7lades en \u00e8poques diferents per prove\u00efdors successius. <\/p>\n La segona consisteix a diferir el que es pugui. Un giny de xat no t\u00e9 cap motiu per carregar-se abans de la primera interacci\u00f3 del visitant. Carregar-lo al primer despla\u00e7ament o en passar el ratol\u00ed per sobre del bot\u00f3 allibera el fil principal durant la fase cr\u00edtica. <\/p>\n La tercera consisteix a fragmentar les tasques llargues. Un gestor d’esdeveniments que executa 400 mil\u00b7lisegons de c\u00e0lcul d’un bloc ha de retornar el control al navegador entre dues etapes, amb <\/p>\n <\/a><\/p>\n Confondre aquestes dues fonts \u00e9s l’error metodol\u00f2gic m\u00e9s est\u00e8s. Les dades de camp provenen dels vostres visitants reals i constitueixen l’\u00fanica font utilitzada per Google per a l’avaluaci\u00f3. Les dades de laboratori provenen d’una simulaci\u00f3 executada a petici\u00f3, en un entorn estandarditzat. Les primeres diuen on sou. Les segones diuen per qu\u00e8. <\/p>\n L’eina mostra els dos blocs a la mateixa p\u00e0gina. A la part superior, l’avaluaci\u00f3 de l’experi\u00e8ncia d’usuari real, extreta del Chrome User Experience Report durant 28 dies. A la part inferior, el diagn\u00f2stic de Lighthouse i la seva llista d’oportunitats. El bloc superior \u00e9s el que compta per al posicionament. El bloc inferior \u00e9s el que us diu qu\u00e8 heu de corregir. <\/p>\n Una p\u00e0gina amb poc tr\u00e0nsit no t\u00e9 prou visites per alimentar l’informe. PageSpeed Insights llavors passa a les dades de tot el domini, cosa que oculta totalment el comportament de la URL provada. Una fitxa de producte lenta pot aix\u00ed mostrar un verd tranquil\u00b7litzador heretat de la p\u00e0gina d’inici. <\/p>\n L’informe de Core Web Vitals agrupa les URL per similitud d’estructura i assenyala els grups que fallen. \u00c9s l’eina que permet entendre que un problema prov\u00e9 d’una plantilla i no d’una p\u00e0gina. Quan 240 fitxes de producte apareixen en el mateix grup en vermell, la correcci\u00f3 es fa una vegada a la plantilla i cobreix tot el cat\u00e0leg. Aquest raonament per plantilla \u00e9s central en un projecte de SEO e-commerce<\/a>, on el volum d’URL fa impossible qualsevol correcci\u00f3 unit\u00e0ria. <\/p>\n Cal comptar 28 dies despr\u00e9s d’una correcci\u00f3 per veure com la Search Console passa al verd. La finestra lliscant de l’informe integra progressivament les noves visites. Validar un correctiu es fa al laboratori en una hora; confirmar-lo sobre el terreny triga un mes. <\/p>\n<\/div>\n La biblioteca oficial web-vitals de Google permet recollir les tres m\u00e8triques directament al navegador dels vostres visitants i enviar-les a la vostra eina d’an\u00e0lisi. L’inter\u00e8s \u00e9s segmentar per tipus de dispositiu, per navegador, per p\u00e0gina i per pa\u00eds, cosa que l’informe agregat no permet. En un lloc multiling\u00fce que serveix a Andorra, Fran\u00e7a i Espanya, aquesta segmentaci\u00f3 revela de vegades que el problema es limita a una zona geogr\u00e0fica mal coberta pel CDN. <\/p>\n WordPress no \u00e9s lent per naturalesa. Es torna lent per acumulaci\u00f3: un tema gen\u00e8ric carregat de funcionalitats no utilitzades, trenta extensions de les quals dotze injecten el seu CSS a totes les p\u00e0gines, un constructor de p\u00e0gines configurat per defecte, un allotjament compartit. Cada capa afegeix uns quants centenars de mil\u00b7lisegons. <\/p>\n Cap optimitzaci\u00f3 front-end pot compensar un servidor lent. PHP 8.2 o superior, OPcache actiu, mem\u00f2ria cau d’objectes persistent amb Redis, mem\u00f2ria cau de p\u00e0gina completa, HTTP\/2 com a m\u00ednim: aquesta base sol dividir el TTFB per tres. En un lloc amb tr\u00e0nsit internacional, un CDN que serveixi els recursos est\u00e0tics des d’un punt de pres\u00e8ncia proper al visitant completa el dispositiu. Aix\u00f2 \u00e9s exactament el que cobreix una oferta d’allotjament gestionat<\/a>, a difer\u00e8ncia d’un allotjament compartit d’uns pocs euros al mes on el vostre lloc comparteix recursos amb centenars d’altres. <\/p>\n Tres accions en ordre. Servir WebP o AVIF en lloc de JPEG, cosa que redueix el pes entre un 30 i un 50% amb una qualitat visual constant. Redimensionar realment els fitxers en lloc de deixar que el navegador redueixi una imatge de 3000 p\u00edxels d’ample en un contenidor de 800. Aplicar el lazy loading a tot arreu excepte a l’element LCP, amb El principi es resumeix en una frase: carregar en una p\u00e0gina nom\u00e9s el que aquesta p\u00e0gina utilitza. Un formulari de contacte que injecta el seu CSS i el seu JavaScript a tot el lloc quan nom\u00e9s apareix en una URL representa un malbaratament pur. La c\u00e0rrega condicional dels recursos per extensi\u00f3, la publicaci\u00f3 del CSS cr\u00edtic al document i l’ajornament de la resta constitueixen el gruix del treball. <\/p>\n Elementor Pro arrossega una reputaci\u00f3 de pesadesa heretada en gran part de les seves versions antigues i de configuracions deixades per defecte. Les funcionalitats experimentals que cal activar s\u00f3n conegudes: c\u00e0rrega optimitzada de recursos, c\u00e0rrega de CSS sota demanda, icones de font en l\u00ednia, sortida DOM optimitzada. Aquestes eliminen diverses desenes de kilobytes a cada p\u00e0gina. <\/p>\n La resta dep\u00e8n del m\u00e8tode de construcci\u00f3. Els contenidors flexbox substitueixen amb avantatge l’antiga estructura de secci\u00f3, columna i giny, que multiplicava els nivells d’imbricaci\u00f3 i sobrecarregava l’arbre del document. Desactivar les biblioteques d’icones i les animacions no utilitzades elimina peticions senceres. En els nostres projectes de web a mida<\/a>, limitem volunt\u00e0riament el nombre de ginys de tercers i reescrivim en HTML i CSS natius els blocs la versi\u00f3 de giny dels quals costa massa en rendiment. <\/p>\n Aquesta disciplina t\u00e9 un l\u00edmit que cal assumir. En un lloc que acumula vuit anys de continguts, tres redissenys parcials i una biblioteca d’extensions heretada, l’optimitzaci\u00f3 marginal arriba a un sostre. Un redisseny de lloc web<\/a> sovint costa menys que dotze mesos de correctius successius sobre una base estructuralment compromesa, i dona un resultat que el peda\u00e7 mai no assolir\u00e0. <\/p>\n Una instal\u00b7laci\u00f3 de WordPress de diversos anys acumula silenciosament un pes invisible des del front-end. Les revisions d’articles de vegades es compten per desenes de milers de l\u00ednies, les taules de les extensions desinstal\u00b7lades es mantenen al seu lloc, les entrades transit\u00f2ries caducades mai no es purguen. Cada petici\u00f3 de p\u00e0gina travessa aquesta massa i el TTFB s’allarga unes quantes desenes de mil\u00b7lisegons a cada capa. <\/p>\n La neteja es fa amb una c\u00f2pia de seguretat pr\u00e8via, mai en calent en un lloc en producci\u00f3. Limitar el nombre de revisions conservades, purgar les taules \u00f2rfenes, indexar correctament les columnes consultades per les extensions exigents: el guany rarament \u00e9s espectacular per si sol, per\u00f2 se suma als altres i evita la deriva lenta que es constata en els llocs deixats sense seguiment. Aix\u00f2 \u00e9s precisament el que cobreix un contracte de manteniment<\/a> seri\u00f3s, a difer\u00e8ncia d’una simple vigil\u00e0ncia de disponibilitat. <\/p>\n Queda la q\u00fcesti\u00f3 del nombre d’extensions, sobre la qual circulen moltes aproximacions. Trenta extensions lleugeres i ben programades pesen menys que cinc extensions que carreguen cadascuna la seva biblioteca JavaScript completa a totes les p\u00e0gines del lloc. El criteri \u00fatil no \u00e9s la quantitat, sin\u00f3 el pes realment injectat p\u00e0gina per p\u00e0gina, que la pestanya Xarxa de les DevTools revela en pocs minuts. <\/p>\n Cal ser honest sobre el pes d’aquestes m\u00e8triques en l’algoritme. Els Core Web Vitals s\u00f3n un senyal de classificaci\u00f3, confirmat i documentat per Google, per\u00f2 un senyal entre centenars. Un lloc perfectament optimitzat t\u00e8cnicament i buit de contingut \u00fatil mai no passar\u00e0 per davant d’una p\u00e0gina de refer\u00e8ncia lenta en una cerca competitiva. La rellev\u00e0ncia i l’autoritat continuen sent el m\u00e9s important. <\/p>\n La seva influ\u00e8ncia es manifesta en dues situacions precises. La primera \u00e9s l’arbitratge entre p\u00e0gines de qualitat comparable: a rellev\u00e0ncia equivalent, l’experi\u00e8ncia de p\u00e0gina decideix. En una cerca on deu resultats tracten el mateix tema amb la mateixa serietat, la difer\u00e8ncia es juga aqu\u00ed. La segona \u00e9s el pressupost de rastreig. Un servidor lent redueix el nombre de p\u00e0gines que Google explora per sessi\u00f3, cosa que retarda la indexaci\u00f3 de les novetats en els llocs voluminosos. <\/p>\n L’efecte indirecte, per\u00f2, pesa m\u00e9s que l’efecte directe. Una p\u00e0gina lenta augmenta la taxa de rebot, redueix el nombre de p\u00e0gines vistes per visita i fa caure la taxa de conversi\u00f3. Aquests comportaments s’acaben reflectint en les dades que Google recull a escala web. Un proc\u00e9s de compra que triga quatre segons a reaccionar a cada clic perd cistelles abans fins i tot de perdre posicions. <\/p>\n Aquesta \u00e9s tamb\u00e9 la ra\u00f3 per la qual tractem el rendiment com una restricci\u00f3 de disseny i no com una fase d’optimitzaci\u00f3 final. Un lloc dissenyat amb un pressupost de rendiment definit des de la maqueta no necessita ser corregit a posteriori. Els projectes visibles a les nostres realitzacions<\/a> es lliuren directament en verd, sense extensions miracle instal\u00b7lades a l’\u00faltim minut. <\/p>\n L’ordre compta tant com les accions. Molts projectes fallen perqu\u00e8 comencen pel m\u00e9s visible en lloc del m\u00e9s determinant. <\/p>\n Aquesta seq\u00fc\u00e8ncia s’aplica tant a una web corporativa<\/a> de dotze p\u00e0gines com a un cat\u00e0leg de milers de refer\u00e8ncies. Nom\u00e9s canvia l’abast del treball per etapa. En un lloc d’e-commerce<\/a>, l’etapa tres i l’etapa cinc representen per si soles la major part de l’esfor\u00e7, perqu\u00e8 les fitxes de producte concentren les imatges pesades i els scripts de personalitzaci\u00f3. <\/p>\n Una observaci\u00f3 sobre el pressupost. El rendiment no \u00e9s una l\u00ednia opcional del pressupost, \u00e9s una conseq\u00fc\u00e8ncia de les eleccions d’arquitectura fetes al principi. Un projecte constru\u00eft sobre un tema gen\u00e8ric comprat per 60 euros costar\u00e0 m\u00e9s de corregir en tres anys que un desenvolupament net. El nostre simulador de preus de llocs web<\/a> dona una forquilla realista en pocs minuts, i l’article que detalla quant costa un lloc web el 2026<\/a> explica qu\u00e8 cobreix cada partida. <\/p>\nLCP: l’element visible m\u00e9s gran decideix la vostra percepci\u00f3 de velocitat<\/h2>\n
Identificar l’element LCP abans d’intentar res<\/h3>\n
Descompondre el LCP en quatre segments<\/h3>\n
fetchpriority=\"high\"<\/code>. Un temps de desc\u00e0rrega excessiu requereix WebP o AVIF, un redimensionament real i un CDN. Un retard de renderitzaci\u00f3 llarg delata una fulla d’estil massa pesada o una font web mal declarada. <\/p>\npreload<\/code> equival a no prioritzar res: el navegador es troba amb deu urg\u00e8ncies simult\u00e0nies i l’ample de banda es reparteix entre elles. Un sol precarregament ben orientat a la imatge LCP, associat a un preconnect<\/code> cap al domini que l’allotja quan prov\u00e9 d’un CDN, produeix un guany net. M\u00e9s enll\u00e0 d’aix\u00f2, l’efecte s’inverteix. <\/p>\nloading=\"lazy\"<\/code> a totes les imatges del lloc, inclosa la de l’hero. El navegador llavors posposa la desc\u00e0rrega de l’element LCP i la m\u00e8trica es dispara. La imatge visible en carregar-se no s’ha de diferir mai.\n<\/div>\nCLS: l’instabilitat visual que els vostres visitants pateixen sense dir-ho<\/h2>\n
Les quatre causes que produeixen el 90% del CLS<\/h3>\n
width<\/code> i height<\/code> encap\u00e7alen la llista. Sense aquestes dimensions, el navegador no pot reservar l’espai i el text puja bruscament quan la imatge es carrega. La correcci\u00f3 consisteix en dos atributs, i WordPress els afegeix nativament des de la versi\u00f3 5.5 per a les imatges inserides mitjan\u00e7ant l’editor, per\u00f2 no sempre per a les injectades per un tema o un constructor de p\u00e0gines. <\/p>\nfont-display: swap<\/code> i size-adjust<\/code> limita el fenomen, a condici\u00f3 de precarregar el fitxer de la font i allotjar-lo al vostre propi domini en lloc d’anar a buscar-lo a un tercer. <\/p>\nINP: la m\u00e8trica que sanciona els llocs sobrecarregats de scripts<\/h2>\n
Tres components, tres responsables diferents<\/h3>\n
Reduir l’INP sense trencar les funcionalitats<\/h3>\n
scheduler.yield()<\/code> quan estigui disponible o un simple ajornament de l’execuci\u00f3. El treball total continua sent el mateix, per\u00f2 la interf\u00edcie respon entre els segments. <\/p>\nMesurar els Core Web Vitals: dades de camp contra dades de laboratori<\/h2>\n
PageSpeed Insights, el punt de partida<\/h3>\n
La Search Console, per analitzar a escala de tot el lloc<\/h3>\n
Mesurar en els vostres propis visitants<\/h3>\n
Corregir els Core Web Vitals a WordPress i Elementor<\/h2>\n
L’allotjament i el TTFB, la base<\/h3>\n
Les imatges, el recurs m\u00e9s rendible<\/h3>\n
fetchpriority=\"high\"<\/code> en aquest \u00faltim. <\/p>\nEl CSS i el JavaScript, la disciplina de la c\u00e0rrega<\/h3>\n
Elementor, els ajustos que marquen la difer\u00e8ncia<\/h3>\n
La base de dades i les extensions, el punt que ning\u00fa mira<\/h3>\n
L’impacte real en el vostre posicionament, sense exageracions<\/h2>\n
El m\u00e8tode d’intervenci\u00f3, en l’ordre que produeix resultats<\/h2>\n
\n