Front-end levering in het tijdperk van hoogfrequent publiceren moet caching en compressie-samenwerking opnieuw ontwerpen

Zodra front-end-bronnen een hoogfrequent releaseritme bereiken, zullen prestatieproblemen binnenkort niet langer zo eenvoudig zijn als het “aanzetten van Brotli”. Het eerste scherm wordt langzamer, het back-to-origin-verkeer neemt toe en de CPU van het edge-knooppunt trilt. Op het eerste gezicht lijkt het erop dat de compressie niet agressief genoeg is. Als we dieper kijken, zijn het vaak de caching en compressie die afzonderlijk worden geoptimaliseerd en elkaar uiteindelijk ondermijnen op de publicatielink.

Dit soort problemen komen in de eerste versie doorgaans niet aan het licht. In het begin zag het team slechts enkele verspreide signalen: een kleine verandering veroorzaakte een storing in de hitrate van statische bronnen, een abnormale toename van de CPU voor randcompressie aan de vooravond van een grote promotie, en het retourpakketvolume in de grijswaardenfase kwam niet overeen met het officiële verkeer. Als je doorgaat met controleren, komen de aanwijzingen meestal op hetzelfde neer: hoewel de inhoud van de bronnen maar een klein beetje is veranderd, zijn de cachesleutel, het splitsen van chunks en de gecomprimeerde invoer een andere reeks dingen geworden, en wordt de transportlaag gedwongen om opnieuw de volledige kosten op zich te nemen.

Totdat de resource-hash stabiel is, zijn de compressievoordelen eenvoudigweg onhoudbaar.

Nadat front-end-projecten parallel met meerdere pagina’s, meerdere routes en meerdere teams zijn uitgebracht, is het aspect dat het gemakkelijkst over het hoofd wordt gezien de stabiliteit van de bestandsnaam. Zolang de chunk-segmentatie enigszins afwijkt, zelfs als de bedrijfscode alleen de kopie van een knop verandert, kan het eindproduct ook de hash van een reeks openbare bundels herschrijven. Wat het cachingsysteem ziet is een reeks gloednieuwe objecten, en wat het compressiesysteem ziet is een reeks invoer die voor de eerste keer verschijnt.

Op dit moment kan het, hoe hoog de compressiesnelheid ook is, de treffersnelheid niet voor instorting behoeden. De oude bestanden liggen nog steeds in de randknooppunten en de nieuwe bestanden zijn opnieuw gecodeerd; de lokale cache van de browser is volledig ongeldig en de CDN moet de broncode opnieuw ophalen, opnieuw comprimeren en opnieuw distribueren. Een kleine bedrijfsverandering wordt uitvergroot tot herhaald werk voor de gehele transmissieverbinding.

De echt nuttige actie is meestal niet om het compressieniveau verder aan te passen, maar om eerst de stabiliteit van het vrijgegeven product te controleren:

• Publieke afhankelijkheden worden in afzonderlijke lagen opgedeeld om bedrijfsveranderingen te verminderen en basispakketten samen te brengen om de hash te veranderen.
• Vermijd het combineren van hoogfrequente wijzigingen, zoals tijdstempels, en bouw cijfers rechtstreeks in de productinhoud
• Laat de code in de buurt van dezelfde route zoveel mogelijk in stabiele delen vallen, in plaats van dat deze elke keer dat deze wordt gecompileerd, opnieuw wordt geschud.

Alleen wanneer de bronidentiteit is gestabiliseerd, kan de cache continu worden hergebruikt en hebben de compressieresultaten cumulatieve waarde.

Hoogfrequente persconferentie herschrijft het compressieprobleem in een woordenboekversieprobleem

Nu bronnen steeds meer gefragmenteerd raken, is Brotli of gzip met één bestand nog steeds belangrijk, maar het is niet langer alles. De werkelijke kosten beginnen te verschuiven naar dubbele stukken: raamwerkruntimecode, stijlsjablonen, interfacetypedeclaraties, verpakkingslagen gegenereerd door verpakkers, zijn vaak zeer vergelijkbaar tussen batches versies. Met een snel releasetempo worden deze riffs steeds opnieuw overgedragen.

Het probleem is dat het compressiewoordenboek gemakkelijk kan omslaan van een optimalisatie in een verstoring als het niet samen met de release-cadans wordt beheerd. Als het woordenboek vooraf wordt gewijzigd, zal het nieuwe woordenboek waarnaar op de oude pagina wordt verwezen, niet overeenkomen; het woordenboek is in te veel stukken opgedeeld en het aantal versies dat door randknooppunten moet worden onderhouden neemt sterk toe; de woordenboekupdate wordt niet gesynchroniseerd met de online bron en de objecten die hadden moeten worden geraakt, worden weer volledig verzonden.

Dit is ook een zeer praktische verandering in de recente front-end-levering: cachingstrategieën en compressieprotocollen kunnen niet langer door verschillende teams worden onderhouden. Bronversies, woordenboekversies en cachesleutelruimten zijn in essentie hetzelfde publicatieprobleem.

Een hiërarchische benadering zoals de volgende is meestal stabieler dan “uniforme sterke compressie voor de hele site”:

const policy = {
  immutableAssets: 'public, max-age=31536000, immutable',
  releaseManifest: 'public, max-age=60, stale-while-revalidate=30',
  sharedDictionary: 'versioned-by-release-train'
}

De sleutel is niet de configuratie zelf van deze drie regels, maar de beperkingen die deze tot uitdrukking brengen: bronnen met een lange levenscyclus, een korte levenscycluslijst en de gecomprimeerde woordenboekversie moeten samen evolueren volgens hetzelfde releaseritme.

De druk om terug te keren naar de bron is vaak niet dat het bestand te groot is, maar dat de foutmethode te ruw is.

Een andere veel voorkomende misvatting is om de toename van de bandbreedte rechtstreeks toe te schrijven aan het gewicht van de pagina. Pagina’s worden zeker zwaarder, maar de gevaarlijkere versterkers online zijn meestal de beste keuze.

Als u elke keer dat u publiceert per map, voorvoegsel of zelfs de hele site opschoont, verliest de cachelaag onmiddellijk zijn geheugen. Op dit moment zal de return-to-origin-piekwaarde vanzelf omhoog gaan, zelfs als de bestandsgrootte niet blijft groeien. Zodra de broncode wordt geretourneerd, worden de randen opnieuw gecomprimeerd, worden de objecten opnieuw opgewarmd en wordt de browser opnieuw gedownload. Het publicatievenster verandert van een kleine stapsgewijze wijziging naar een volledige verplaatsing van de site.

In dit soort scenario’s is de beheersbare faalradius het meest waardevol:

• Maak alleen manifest-, HTML- en veranderlijke bronnen ongeldig die daadwerkelijk zijn gewijzigd
• Probeer statische bestanden niet met hash op te schonen en geef ze over aan nieuwe referenties voor natuurlijk schakelen.
• Splits de release op in de volgorde van “eerst nieuwe bronnen uploaden, dan referenties verwijderen en dan oude bronnen recyclen” in plaats van ze allemaal in één keer te wissen

Wat echt gevoelig is aan de overdrachtskosten is niet alleen de bestandsgrootte, maar ook de manier waarop het systeem beslist welke inhoud opnieuw moet worden opgehaald.

De toepasselijke grens wordt bepaald samen met de omvang van de hulpbronnen en de vrijgavefrequentie.

Deze set co-design is niet voor alle sites vereist. Voor projecten met een klein aantal statische pagina’s, een klein bronpakket en een releasefrequentie van wekelijks of zelfs maandelijks is het gebruik van traditionele hashbestandsnamen plus Brotli-pre-compressie meestal stabiel genoeg.

Caching en compressie worden samen snel een leveringsinfrastructuur zodra deze kenmerken aanwezig zijn:

• Meerdere keren per dag uitgebracht, met grijstinten, rollback of regionale lanceringen
• Het front-endproduct is groot van formaat, heeft veel publieke afhankelijkheden en heeft complexe chunk-relaties.
• CDN, objectopslag, edge-compressie en browsercaching nemen tegelijkertijd deel aan de transmissielink
• Het verkeer is zo hoog dat het cachetrefferpercentage en de return-to-origin-piekwaarde een directe weerspiegeling zijn van de kosten en stabiliteit.

Nadat front-end-levering deze fase is ingegaan, betekent compressie niet langer alleen maar ‘bestanden kleiner maken’, en caching is niet langer alleen maar ‘het opslaan van meer kopieën van inhoud’. Wat de twee samen beslissen is: voor een verandering in een klein bedrijf, of het nu gaat om het verzenden van nog een stuk, of dat de hele transmissieverbinding opnieuw moet worden uitgevoerd. Hoe vaker je publiceert, hoe duurder dit verschil wordt.