L’optimització està acabada i arriba l’informe. Hi ha captures verdes, diverses gràfiques i una frase estupenda: «el web ja va molt millor». Falta una peça petita, però força útil: saber què pots donar per comprovat.
Un informe d’optimització WordPress hauria de permetre revisar la feina sense haver de reconstruir-la a base de correus. Què ha canviat, què s’ha mesurat, sota quines condicions, quines funcions continuen operatives i què queda pendent. Aquesta és la base per acceptar un lliurament amb criteri.
Aquí tens una plantilla original, una matriu de revisió i un exemple de càlcul amb dades fictícies. Serveixen per llegir i demanar evidències; no descriuen una optimització realitzada per a un client. Si necessites revisar una entrega, pots sol·licitar una avaluació de resultats de rendiment WordPress indicant abast, URL i problema.
L’informe ha de respondre a l’encàrrec aprovat
Abans de llegir les xifres, recupera la proposta acceptada. Identifica les pàgines, perfils i funcions inclosos. Una millora a la portada pot ser rellevant, però no respon per si sola a un encàrrec sobre filtres de producte o càlcul d’enviament.
Relaciona cada requisit amb una evidència. Si l’abast incloïa una interacció, demana el registre d’aquella interacció. Si incloïa conservar el disseny, demana la revisió dels elements acordats. La comprovació ha de seguir la promesa concreta que es va aprovar.
La guia de pressupost d’optimització WordPress per al 2027 ajuda a definir aquesta relació abans de contractar. Aquest informe se situa al final: organitza l’evidència que es lliura i les decisions que permet prendre.
Plantilla copiable per a un lliurament revisable
Fes servir una fitxa per intervenció i enllaça-hi els informes detallats. La fitxa és un índex de decisions, no un lloc per enganxar contrasenyes, dades de clients o traces completes de sessions privades.
Informe d'optimització WordPress | referència:
Abast aprovat i responsable de l'acceptació:
URL, plantilla, idioma i acció revisats:
Versió anterior / versió lliurada / data del canvi:
Canvis aplicats i dependència de cadascun:
Mètode, eina i condicions de mesura:
Mostres originals i resum utilitzat:
Resultat de rendiment per requisit:
Resultat funcional i visual per recorregut:
Comprovació després de publicar i alternativa segura:
Limitacions, excepcions i tasques pendents:
Decisió, evidència citada, responsable i data:Assigna referències als arxius i resultats per poder localitzar-los després. «Captura final» diu poc quan hi ha sis versions adjuntes. Un nom d’informe, data i URL permeten trobar l’evidència concreta que va sustentar la decisió.
Si una casella no té resultat, conserva «no mesurat» o «pendent» amb el motiu. Completar-la amb una suposició fa més difícil el diagnòstic següent. Un informe útil diferencia el que es coneix del que encara necessita feina.
Comprova la comparabilitat abans de calcular la millora
Revisa URL, eina, perfil, xarxa, estat de sessió, consentiment i criteri de memòria cau. La versió desplegada ha d’estar identificada. Quan una condició canvia, l’informe ha d’explicar si la comparació continua responent a la mateixa pregunta.
La guia de proves reproduïbles de WordPress desenvolupa com preparar aquest assaig. En revisar una entrega, demana el protocol aplicat i les diferències documentades. No necessites tornar a definir cada eina per comprovar si es van respectar les condicions acordades.
Una comparació entre dos estats diferents pot ser útil per diagnosticar. El problema apareix quan es presenta com un abans i després de la intervenció sense justificar-ho. Un dispositiu diferent o una sessió distinta poden canviar la lectura de les xifres.
Matriu de revisió del lliurament
Aquesta matriu és una eina editorial pròpia. A cada fila registra resultat, referència i responsable. Els estats possibles poden ser «verificat», «fallit», «incomplet» o «no aplicable amb motiu»; defineix-ne l’ús amb l’equip que aprova.
| Referència | Pregunta de revisió | Evidència que cal localitzar |
|---|---|---|
| VAL-01 | S’ha mesurat l’abast acordat? | URL, accions, perfils i versió |
| VAL-02 | La comparació fa servir condicions coherents? | Protocol, mostres i diferències |
| VAL-03 | Ha millorat l’indicador pertinent? | Resultat per requisit i els seus límits |
| VAL-04 | Funcionen els recorreguts afectats? | Proves funcionals i resultats |
| VAL-05 | Es conserva el que s’ha acordat de disseny i consentiment? | Revisió dels estats i elements inclosos |
| VAL-06 | S’ha verificat la versió publicada? | Desplegament, revisió i pendents assignats |
No converteixis la taula en sis marques verdes sense arxius al darrere. Si el proveïdor lliura una captura de laboratori, registra quin requisit acredita. El mateix document pot servir per a diverses files, però només quan el seu abast cobreixi realment aquelles preguntes.
L’acceptació també necessita mirar què falla. Una funció comercial trencada requereix una decisió explícita i la seva correcció o alternativa acordada. La mitjana de la resta de la taula no transforma aquest error en un lliurament complet.
Tres exemples de decisió escrita
Els casos següents són ficticis i mostren com registrar el resultat d’una revisió. No representen feines realitzades ni aprovacions de clients.
- REV-01: comprovació acotada tancada. L’informe conté mostres comparables i proves de les funcions incloses. El responsable accepta aquells requisits identificats; el seguiment posterior d’usuaris continua obert amb data i propietari. La nota cita els arxius revisats i deixa fora els escenaris no provats. Així se sap què s’ha acceptat sense ampliar la conclusió a tot el web.
- REV-02: funció que falla. Una mètrica de càrrega millora a l’exemple, però el formulari del recorregut acordat no completa l’operació. Es registra l’error, l’evidència i el responsable de corregir-lo. La decisió sobre corregir o tornar a un estat segur correspon al procediment de canvi. No es dona per completa aquella part de l’encàrrec pel resultat de la mètrica.
- REV-03: falta evidència localitzable. La presentació conté xifres, però no permet localitzar condicions ni mostres. Se sol·licita la documentació necessària per valorar la comparació. L’estat continua incomplet: això identifica una mancança de l’informe, sense concloure encara que la intervenció tècnica no va funcionar ni contractar una altra optimització a cegues.
En tots tres casos queda escrita l’acció següent i qui l’assumeix. Aquest registre redueix converses circulars: el proveïdor sap què ha de lliurar i qui aprova sap què haurà de revisar per canviar l’estat.
Exercici original: el compte surt bé i la conclusió no
Aquestes dades són fictícies. El 25 d’octubre de 2026 vam executar un càlcul local amb dues sèries inventades de cinc temps. Les vam etiquetar deliberadament amb perfils diferents per comprovar què permet concloure el seu resum. No provenen de proves d’un web ni d’una intervenció de client.
Sèrie A, perfil mòbil: 3200, 2800, 3000, 3100, 2900 ms
Sèrie B, perfil escriptori: 2600, 2400, 2500, 2700, 2300 ms
Medianes calculades: 3000 ms i 2500 ms
Diferència aritmètica: 500 ms menys; 16,67 %
Perfils coincidents: noEl càlcul de les medianes i la diferència és correcte per a aquestes sèries. No demostra una millora de rendiment causada per una optimització: hem canviat el perfil de comparació. La decisió de revisió seria demanar evidència comparable abans d’acceptar aquella afirmació.
L’exemple separa dues comprovacions de l’informe: exactitud del resum i validesa de la comparació. Un full de càlcul pot resoldre la primera sense resoldre la segona. Cap d’aquests números no és un resultat real que hagis d’exigir al teu projecte.
Un cas observat que tampoc no és un abans i després
A la guia sobre PageSpeed aprovat i recorreguts lents documentem perfils de laboratori d’aquest web: escriptori 99 i mòbil emulat 79. No hi va haver una optimització entre tots dos, i no hi havia dades d’usuaris reals disponibles.
Si aquelles dues captures arribessin sense context a un informe, seria fàcil confondre-les amb una evolució. La pregunta de revisió és què ha canviat entre elles. L’enllaç a l’informe, el perfil i la data permeten comprovar que responen a condicions diferents.
La feina d’acceptar un lliurament consisteix precisament a conservar aquest context. Una xifra pot ser autèntica i estar utilitzada per a una conclusió que no acredita. Demana que cada resultat es relacioni amb la prova i el requisit que pretén tancar.
Un resum visual ha de permetre arribar al detall
La referència serveix per pensar en la jerarquia d’un informe: resum, comparació i detall localitzable. Els seus indicadors pertanyen al projecte mostrat. Al teu lliurament, cada targeta necessita identificar què mesura i enllaçar l’evidència que permet revisar-la.
Separa resultats de càrrega, interacció i funció
Una mesura de càrrega inicial no acredita automàticament la resposta de filtres, menús o formularis. Organitza l’informe segons el moment observat. Així pots veure si el problema de l’encàrrec ha rebut una comprovació específica.
La guia de web.dev sobre mesura diferencia laboratori i camp. Al lliurament, identifica l’origen de cada resultat i conserva’n l’abast. Les dades històriques d’usuaris i una prova controlada no s’han de tractar com la mateixa mostra.
A més, comprova que el recorregut acabi correctament. Un formulari pot respondre aviat i no completar l’operació esperada. L’informe necessita el resultat funcional acordat, juntament amb el temps observat quan aquell temps formi part de l’objectiu.
Disseny i consentiment també formen part de la revisió
Identifica què s’havia de conservar: imatges, tipografia, navegació, moviment o estats del bàner, segons l’encàrrec. Demana una revisió de les vistes rellevants i dels canvis aprovats. No pressuposis que un recurs eliminat era prescindible.
Si la intervenció modifica càrrega diferida o scripts, registra quins estats de consentiment es van comprovar i quines funcions s’hi van observar. Una prova sense elecció de cookies no acredita automàticament el comportament posterior a una altra elecció.
Quan una comprovació no es va poder fer, deixa l’estat incomplet amb la seva dependència. Aquesta informació permet programar la revisió pendent sense presentar com a verificat un escenari que ningú no ha recorregut.
Què ha de quedar documentat en publicar
L’informe ha d’identificar la versió posada en producció, data i canvis aplicats. Conserva quines diferències hi havia respecte a l’entorn d’assaig i què es va revisar després del desplegament. Aprovar una còpia de proves no equival a observar la versió publicada.
Afegeix configuració i dependències que un altre professional necessitarà mantenir, amb les seves ubicacions protegides. Registra llicències, regles rellevants i responsables; els valors secrets pertanyen al seu sistema de gestió, no al PDF comercial.
Si després d’una actualització reapareix una lentitud, la guia de comparació després de canvis de WordPress ajuda a investigar des d’una versió coneguda. Un bon informe de lliurament deixa aquesta referència disponible.
Com registrar la decisió i els pendents
Escriu quin abast s’accepta, amb quines evidències i en quina data. Una acceptació parcial ha de nomenar les files pendents i el seu efecte sobre el lliurament. Cada tasca necessita responsable, comprovació següent i criteri de tancament.
Separa defectes observats, funcions addicionals sol·licitades i seguiment de dades que requereix temps. Són converses diferents. L’informe ha de permetre decidir-les sense esborrar el resultat original ni atribuir a la intervenció qualsevol canvi posterior.
Si la feina inclou observar dades d’usuaris després del llançament, conserva aquest compromís amb el mètode i el termini. Una comprovació de laboratori es pot tancar mentre aquell seguiment continua obert, sempre que el document ho indiqui amb claredat.
Un abans i després real d’aquest web: com es lliura la font
El 25 d’octubre de 2026 vam canviar el lliurament de Sora al nostre web. Abans, la portada espanyola demanava un full d’estils de Google Fonts i després el fitxer tipogràfic. Ara fa servir els mateixos fitxers originals des del domini de WebSpeed Optimize i les declaracions de font van incloses a l’HTML. Vam conservar la tipografia, els pesos, els subconjunts de caràcters i la llicència SIL Open Font License dels autors de Sora.
La intervenció va eliminar una dependència externa d’estils; no va ser un redisseny ni un canvi de contingut. Els fitxers del tema van conservar les empremtes i les nou pàgines i entrades comprovades van mantenir les dades durant la intervenció. També vam contrastar el text principal i la família, pes, mida i dimensions del títol en les dotze càrregues: coincidien.
El protocol que vam fer servir per comparar
Vam mesurar sis càrregues abans i sis després de la mateixa portada pública en espanyol, amb Chromium 152.0.7977.82. Cada visita va obrir un navegador nou, finestra de 1280 × 900 píxels, escala 1 i configuració regional es-ES. Vam desactivar la memòria cau del navegador i vam fixar una emulació de xarxa de 150 ms de latència, 200.000 bytes per segon de baixada i 93.750 de pujada, amb alentiment de CPU per quatre.
No hi va haver interacció ni elecció de galetes durant la mostra: totes les visites van començar amb un context anònim nou. Vam registrar el candidat LCP, FCP i desplaçaments de disseny en una finestra inicial d’aproximadament vuit segons. És una mesura d’escriptori amb emulació; no representa un telèfon físic ni dades d’usuaris reals. Tampoc garanteix una memòria cau freda de DNS, sistema operatiu o CDN.
| Indicador | Abans | Després |
|---|---|---|
| Càrregues | 6 | 6 |
| Candidat LCP, mediana | 2396 ms | 2316 ms |
| Candidat LCP, mínim–màxim | 2300–2512 ms | 2224–2608 ms |
| CLS de la finestra, mediana | 0,0264 | 0,0264 |
| Peticions per a la font observades per visita | 2 externes: CSS i WOFF2 | 1 local: WOFF2 |
La conclusió necessita alguna cosa més que un número verd
La mediana del candidat LCP va baixar 80 ms, però els rangs se solapen. La càrrega posterior més lenta també va ser més lenta que qualsevol de les anteriors. Hem conservat aquest resultat, no l’hem enviat a fer un cafè fora de la taula. Les dues sèries es van executar de manera consecutiva; la variació de xarxa i servidor continua sent una possible influència.
El que sí que queda comprovat és el canvi de lliurament: a les sis visites anteriors van aparèixer les dues peticions externes per a la font; a les sis posteriors, una petició al fitxer local. El navegador va continuar representant Sora i el títol va mantenir les dimensions. Conservem el lliurament local per aquesta reducció de dependències i per l’absència d’una regressió de disseny observada, sense convertir 80 ms d’aquesta mostra en una promesa universal.
Descarrega les dotze mesures, el CSV i el context de les respostes. El paquet inclou tots els intents de la sèrie, les condicions i les dates. La guia de web.dev sobre fonts també recomana comprovar el lliurament en lloc de donar per fet que servir-les localment sempre serà més ràpid.
Aquest cas no acredita INP de camp, una puntuació Lighthouse, més vendes ni una pujada de clics a Google. Per revisar un lliurament, demana aquest mateix conjunt: canvi identificable, condicions comparables, sèrie completa, comprovacions de disseny i una conclusió proporcional al que s’ha mesurat. L’informe t’ha d’ajudar a acceptar la feina i decidir què mereix investigar-se després.
Què cal enviar per a una segona revisió
Comparteix l’abast aprovat, les URL i els informes disponibles, indicant quina afirmació no pots comprovar. Una descripció i referències públiques són suficients per començar a delimitar la revisió. Els arxius privats se sol·liciten per un canal acordat quan siguin necessaris.
La pregunta útil és concreta: quin requisit falta per acreditar i quina evidència permetria resoldre’l. Amb aquesta informació es pot acordar una revisió de l’informe, proves noves o una correcció, segons el cas, abans d’intervenir de nou en producció.