5 november 2026 · patrik bronner

Payload-optimering i RCS API: Minimera latens och layout shifts

RCS (Rich Communication Services) förvandlar traditionell textkommunikation till en interaktiv app-liknande upplevelse direkt i användarens standardmeddelande-app. Men med större frihet och rikare komponenter, som karuseller, högupplöst media och dynamiska åtgärdsknappar, ökar också kraven på hur du utformar dina anrop. En felstrukturerad eller onödigt tung JSON-payload leder snabbt till fördröjningar i leveranskedjan, layoutförskjutningar och i värsta

Konceptbild payload optimering för RCS

RCS (Rich Communication Services) förvandlar traditionell textkommunikation till en interaktiv app-liknande upplevelse direkt i användarens standardmeddelande-app. Men med större frihet och rikare komponenter, som karuseller, högupplöst media och dynamiska åtgärdsknappar, ökar också kraven på hur du utformar dina anrop.

En felstrukturerad eller onödigt tung JSON-payload leder snabbt till fördröjningar i leveranskedjan, layoutförskjutningar och i värsta fall timeouter. I storskaliga integrationer via RCS-API:et gör varje byte och varje millisekund skillnad. Här går vi igenom hur du optimerar dina API-anrop för att minimera latens, spara bandbredd och garantera en sömlös visuell upplevelse.

Rätt struktur för rendering utan layout shifts

En av de mest kritiska faktorerna för användarupplevelsen är att undvika kumulativa layoutförskjutningar (CLS) när meddelandet öppnas. Om kortets format inte deklareras måste RCS-klienten gissa höjden innan bilden laddats färdigt från din mediaUrl.

För att undvika att gränssnittet ”hoppar” tillåter API:et att du på förhand definierar kortets dimensioner och inriktning. Skicka alltid med parametrarna height och orientation i ditt card-objekt.

Optimerad payload (Exempel för Rich Card):

{
  "brand": "Min-Butik-AB",
  "agent": "Kundservice",
  "recipients": {
    "46700123456": {}
  },
  "type": "Card",
  "card": {
    "title": "Vårens produktnyheter",
    "content": "Upptäck vårt nya sortiment med hållbara material och modern design.",
    "mediaUrl": "https://cdn.foretag.se/media/kampanj-2026-hq.webp",
    "height": "Medium",
    "orientation": "Vertical"
  },
  "suggestions": [
    {
      "text": "Visa katalog",
      "type": "OpenUrlAction",
      "order": 0,
      "url": "https://foretag.se/shop",
      "postbackData": "c=v26"
    }
  ]
}

Genom att ange height: ”Medium” vet klienten att den ska reservera plats för en 16:9-bild omedelbart.

Pro-tips: Säkerställ att källbilden på ditt CDN är förbeskuren till exakt det bildförhållande du specificerar (t.ex. 16:9 för Medium). Om du skickar en kvadratisk bild (1:1) till en plats reserverad för Medium, måste RCS-klienten antingen beskära bilden eller lägga till svarta kanter (pillarboxing), vilket ser oprofessionellt ut.

Mediestrategi: Lätta referenser och snabba CDN

I API:et hanteras media enbart via referenser (URL:er) i fältet mediaUrl. Det är en enorm fördel för payload-storleken jämfört med äldre tekniker (som MMS där man Base64-kodade binärdata), men det ställer krav på hur du levererar filerna.

  • Använd globala CDN-länkar: Mediefilen hämtas direkt av mottagarens enhet, inte av API-gatewayen. Se till att mediaUrl pekar mot ett CDN med låg latens.

  • Komprimering och filformat: WebP stöds brett och ger upp till 30 % bättre komprimering än JPEG. Håll bilder till under 300 KB för att säkerställa att de laddas blixtsnabbt även vid svag mobiltäckning. För video rekommenderas H.264 (AVC) i en MP4-container.

  • HTTP-headers: Din medieserver måste returnera korrekta headers (Content-Type och Content-Length), annars riskerar nedladdningen att tyst misslyckas i vissa operatörsnätverk.

Kompakta Webhooks: Optimera ditt postbackData

När du lägger till knappar (Suggestions) i arrayen måste du skicka med fältet postbackData. Värdet här returneras till ditt system som en webhook när kunden klickar.

Vid storskaliga utskick och högt engagemang kan returtrafiken bli enorm om du fyller postbackData med långa tillståndssträngar eller hela JSON-objekt.

❌ Undvik:

"postbackData": "{\"user_id\": 98124, \"action\": \"view_catalog\", \"campaign\": \"spring_2026\"}"

✅ Föredra:

"postbackData": "u=98124&a=cat&c=s26"

Korta, URL-kodade parametrar eller unika referens-ID:n sparar utrymme både i utgående anrop och i inkommande callbacks.

Slanka payloads: Skala bort onödig metadata

Vid hög meddelandevolym gör varje byte i JSON-strukturen skillnad för systemets prestanda. En vanlig orsak till stora payloads är att utvecklare skickar in alla tillgängliga parametrar, men sätter dem till null eller tomma arrayer.

Eliminera tomma fält

API:et har inbyggda standardvärden. Om du inte behöver använda en funktion, utelämna fältet helt istället för att skicka tomt data.

❌ Ineffektiv payload:

{
  "brand": "Min-Butik-AB",
  "agent": "Kundservice",
  "recipients": {
    "46700123456": {}
  }
  "reference": null,
  "tags": [],
  "deliveryReportUrl": "",
  "fallbackPolicy": "NoFallback",
  "type": "Text",
  "content": "Din kod är 849201"
}

✅ Optimerad payload:

{
  "brand": "Min-Butik-AB",
  "agent": "Kundservice",
  "recipients": {
    "46700123456": {}
  },
  "type": "Text",
  "content": "Din kod är 849201"
}

Genom att strikt utesluta det som inte används (såsom taggar, tomma fallback-regler eller referenser för 2FA-koder) minskar serialiseringstiden avsevärt.

Konfigurera smart och effektiv SMS-fallback

För att garantera 100 % leverans även till enheter utan RCS-stöd hanterar API:et fallback sömlöst, men strukturen på fallback-data kan optimeras för att inte tynga ner standardanropen.

När du definierar fallbackPolicy (exempelvis ”FallbackOnNoCapability,FallbackOnFailure,FallbackAfterTimeout”), se till att:

  1. Hålla fallback-strängen kort: Skicka endast den text i fallbackMessage som behövs. Om utskicket är ett rikt kampanjkort, kan fallback-texten vara en kort länk till kampanjen istället för en massiv beskrivning.

  2. Utelämna vid rena textmeddelanden: Om din type är Text och du inte skickar med några knappar eller bilder, kan fallback-texten oftast autogenereras från content. Du behöver därmed inte skicka in ett duplicerat värde i fallbackMessage.

Checklista inför driftsättning

Innan du lanserar större utskick och kampanjer, säkerställ följande punkter i dina anrop:

  • Payloaden följer API:ets exakta struktur (med type, card/carousel och suggestions).

  • Alla medielänkar i mediaUrl använder HTTPS och levereras från ett optimerat CDN.

  • Rich Cards deklarerar height (t.ex. Medium) för att undvika Layout Shifts vid laddning.

  • JSON-strukturen är fri från null-värden och oanvända parametrar.

  • Långa spårningssträngar är komprimerade i postbackData.

  • Bilder är sparade i WebP-format och understiger 300 KB per fil.

När du strukturerar anropen enligt RCS-API:ets best practice kapar du onödig overhead. Resultatet är blixtsnabba meddelanden, garanterad leverans och en visuellt fläckfri upplevelse för dina användare.

RCS API

Vill du veta mer om vårt API?

⌘ K