Dimensiunea imaginii Open Graph: un singur fișier pentru fiecare platformă

O singură imagine de 1200 pe 630 de pixeli, în PNG sau JPEG, sub aproximativ 1 MB, cu conținutul important încadrat în zona centrală de 1080 pe 600. Acel fișier se randează corect pe Facebook, LinkedIn, X, Slack, Discord, WhatsApp și iMessage, ceea ce reprezintă întregul răspuns la întrebarea despre dimensiunea imaginii Open Graph pentru aproape orice site.

Dimensiunile sunt partea ușoară. De obicei, nici nu ele se strică. Ce se strică este textul așezat prea aproape de o margine pe care o platformă o decupează, o imagine care nu se actualizează niciodată pentru că un crawler a memorat-o în cache pe cea veche cu luni în urmă, sau un card care se randează fără nicio imagine pentru că fișierul avea 4 MB pe o origine lentă. Întrebarea despre dimensiunea imaginii OG este de fapt trei întrebări, și doar una dintre ele ține de pixeli. Acest ghid acoperă specificația, zona sigură, comportamentul de cache care îi face pe oameni să creadă că tagurile lor sunt greșite, și cum se rezolvă previzualizările atunci când lucrul distribuit este un link scurt. Dacă previzualizarea îți lipsește complet, nu doar decupată urât, previzualizarea linkului nu apare este ghidul de diagnosticare.

Dimensiunea, și de ce este exact aceasta

Raportul de 1.91:1 provine din cardul de link al lui Facebook, și a rămas pentru că toți ceilalți au adoptat un layout compatibil în loc să-și inventeze propriul lor. Protocolul Open Graph în sine nu spune nimic despre pixeli; definește og:image ca un URL și lasă randarea în seama consumatorului, motiv exact pentru care s-a format un standard de facto în jurul unei singure dimensiuni convenabile.

Ghidul oficial al Facebook despre distribuirea imaginilor stabilește minimul la 200 pe 200 și recomandă fișierul mai mare pentru afișaje de rezoluție înaltă, iar X documentează separat marcajul de card, care este singurul loc unde ai nevoie de un tag specific platformei, nu de un fișier specific platformei.

Zona sigură pe care nimeni n-o menționează

Un card este rareori afișat la raportul la care l-ai proiectat. Aplicațiile de chat decupează spre pătrat pentru miniatură, unele fluxuri taie marginile pe viewport-uri înguste, iar un colț rotunjit mănâncă ultimii câțiva pixeli dintr-un logo din colț.

Păstrează tot ce trebuie să supraviețuiască în interiorul zonei centrale de 1080 pe 600, centrat, și tratează banda exterioară ca pe o decorație pe care îți permiți s-o pierzi. În practică, asta înseamnă că titlul stă centru-stânga în loc de lipit de margine, logo-ul trăiește în interiorul marginii în loc de colț, și nu există niciun chenar subțire, pentru că un chenar este singurul element de design care arată stricat în clipa în care este decupat.

Contrastul contează mai mult decât pare, la rândul lui. Cardurile se randează pe alb într-un client și aproape negru în altul, așa că o imagine care se bazează pe fundalul din jur pentru separare își pierde marginile în jumătate dintre ele.

Tagurile din jurul imaginii

Patru taguri fac treaba. Două dintre ele sunt cele pe care oamenii le sar.

<meta property="og:image" content="https://example.com/og/spring-launch.png" />
<meta property="og:image:width" content="1200" />
<meta property="og:image:height" content="630" />
<meta
  property="og:image:alt"
  content="Spring launch: 30 percent off through May"
/>
<meta name="twitter:card" content="summary_large_image" />

URL-ul trebuie să fie absolut, incluzând schema și host-ul, pentru că crawlerul citește tagul fără niciun context de pagină din care să rezolve o cale relativă. Lățimea și înălțimea permit platformei să rezerve spațiul potrivit înainte ca fișierul să sosească, ceea ce face diferența dintre un card care apare instantaneu și unul care se rearanjează. Iar og:image:alt este tagul de accesibilitate care nu costă nimic și lipsește aproape peste tot.

De ce noua ta imagine nu va apărea

Asta este cea care generează tichete de suport. Ai reparat imaginea, poți vedea noul fișier la URL-ul lui, iar cardul tot arată designul din trimestrul trecut.

Crawlerele sociale fac cache agresiv, și nu sunt deloc subtile în privința asta. Odată ce un URL a fost accesat, versiunea stocată este cea care se randează la distribuirile ulterioare, uneori timp de săptămâni, iar editarea codului tău HTML nu le spune nimic despre a verifica din nou. Trei căi de ieșire, în ordinea în care le-aș încerca:

• Forțează o reaccesare cu instrumentul propriu al platformei: atât Sharing Debugger de la Facebook, cât și Post Inspector de la LinkedIn repreiau conținutul la cerere.
• Publică imaginea sub un nume de fișier nou, care este un URL diferit și, prin urmare, nu are nicio intrare în cache. Aceasta este varianta sigură.
• Schimbă chiar URL-ul distribuit, ceea ce este banal de ușor atunci când ceea ce distribui este un link scurt pe care îl controlezi, nu adresa permanentă a unei pagini.

Înainte să publici orice, verificatorul Open Graph îți arată cardul exact așa cum l-ar construi un crawler, ceea ce durează zece secunde și îți scutește redistribuirea stânjenitoare.

Previzualizări atunci când distribui un link scurt

Un link scurt nu are propriile taguri Open Graph și nici nu are nevoie de ele. Crawlerul urmează redirecționarea, ajunge la destinație și construiește cardul din tagurile de acolo, ceea ce înseamnă că un URL scurtat moștenește orice previzualizare are pagina țintă. Dacă cardul este greșit, tagurile de pe destinație sunt greșite.

Două lucruri depind totuși de nivelul linkului. Redirecționarea trebuie să poată fi urmată de un crawler, ceea ce este cazul normal pentru un salt pe server, dar nu pentru o redirecționare JavaScript, încă un motiv să păstrezi lanțul scurt și pe server. Și pentru că previzualizarea aparține destinației, repunctarea unui link scurt îi schimbă și previzualizarea, o proprietate discret utilă atunci când o pagină de campanie este înlocuită după ce linkul a fost deja distribuit.

Dacă vrei linkul, cardul și datele despre clicuri într-un singur loc, pornește un spațiu de lucru pe propriul tău domeniu și verifică cardul cu instrumentul înainte de trimitere, nu după.

O listă de verificare demnă de păstrat

• 1200 pe 630, PNG sau JPEG, sub 1 MB, URL absolut HTTPS. Asta e întreaga decizie despre dimensiunea imaginii OG.
• Nimic important în afara zonei centrale de 1080 pe 600, niciun chenar subțire.
• og:image:width, og:image:height și og:image:alt prezente.
• twitter:card setat la summary_large_image dacă vrei cardul mare pe X.
• Imagine nouă, nume de fișier nou, apoi reaccesare înainte să anunți orice.

Fă bine aceste cinci lucruri o dată, transformă-le în șablon în head-ul paginii tale, iar imaginile Open Graph încetează să mai fie ceva la care te gândești. Ceea ce este exact atenția potrivită pe care merită s-o primească.

Citește seria fundamentală

Acest articol face parte din clusterul tutorials. Pentru previzualizări care eșuează complet, nu doar se decupează urât, previzualizarea linkului nu apare este soluția platformă cu platformă, iar cum să faci un link pe care se poate da clic acoperă nivelul de dedesubt.

Alte articole de pe blog

• Previzualizarea linkului nu apare? Cauze și cum o repari
• Cum să scurtezi un link pentru X (Twitter): ce îi face t.co
• Cum să urmărești linkurile de social media: clicuri pe canal
• Ce este un link cu brand propriu și de ce convertește mai bine
• Cum să redirecționezi un URL: șase moduri, și când e potrivit fiecare
• Linkuri scurte cu domeniu personalizat: DNS, TLS și edge