{"id":54566,"date":"2019-12-29T00:00:00","date_gmt":"2019-12-28T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj"},"modified":"2020-02-18T14:02:35","modified_gmt":"2020-02-18T11:02:35","slug":"samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/samostoyatelnyj-hosting-storonnih-resursov-horoshij-plohoj-zloj","title":{"rendered":"Selvst\u00e6ndig hosting af tredjeparts ressourcer: god, d\u00e5rlig, ond","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

I de seneste \u00e5r har flere platforme til optimering af frontend-projekter tilbudt muligheder for selvhosting eller proxy til tredjepartsressourcer. Akamai giver mulighed for at angive specifikke parametre<\/a><\/noindex> til selvoprettede URL'er. Cloudflare har teknologien Edge Workers. Fasterzine kan omskrive<\/a><\/noindex> URL'er p\u00e5 siderne, s\u00e5 de peger p\u00e5 tredjepartsressourcer, der findes p\u00e5 hoveddom\u00e6net for hjemmesiden.<\/p>\n

\"Selvst\u00e6ndig<\/a><\/noindex><\/p>\n

Hvis det er kendt, at de tredjepartstjenester, der bruges i dit projekt, ikke \u00e6ndrer sig for ofte, og at processen for deres levering til kunderne kan forbedres, er du helt sikkert begyndt at overveje proxying af s\u00e5danne tjenester. Med denne tilgang kan du i h\u00f8j grad \"n\u00e6rme\" disse ressourcer til brugerne og f\u00e5 bedre kontrol over deres caching p\u00e5 klientsiden. Dette beskytter ogs\u00e5 brugerne mod problemer for\u00e5rsaget af \"nedbrud\" af tredjepartstjenesten eller forringelse af dens ydeevne.
\n<\/a><\/noindex><\/p>\n

Godt: forbedring af ydeevne<\/h2>\n

\nSelvhosting af andres ressourcer forbedrer ydeevnen p\u00e5 en ret \u00e5benlys m\u00e5de. Browseren beh\u00f8ver ikke at kontakte DNS igen, den skal ikke etablere en TCP-forbindelse og udf\u00f8re en TLS-h\u00e5ndtryk p\u00e5 en tredjepartsdom\u00e6ne. Den m\u00e5de, hvorp\u00e5 selvhosting af andres ressourcer p\u00e5virker ydeevnen, kan ses ved at sammenligne de to f\u00f8lgende billeder.<\/p>\n

\"Selvst\u00e6ndig
\nTredjepartsressourcer indl\u00e6ses fra eksterne kilder (taget from here<\/a><\/noindex>)<\/i><\/p>\n

\"Selvst\u00e6ndig
\nTredjepartsressourcer gemmes der, hvor de \u00f8vrige materialer p\u00e5 hjemmesiden ogs\u00e5 findes (taget from here<\/a><\/noindex>)<\/i><\/p>\n

Situationen forbedres yderligere af, at browseren vil udnytte mulighederne for multiplexing og prioritering af data i HTTP\/2-forbindelsen, der allerede er etableret med hoveddom\u00e6net.<\/p>\n

Hvis man ikke hoster tredjepartsressourcer, s\u00e5 da de vil blive indl\u00e6st fra et dom\u00e6ne, der er forskelligt fra hoveddom\u00e6net, kan de ikke prioriteres. Dette vil f\u00f8re til, at de konkurrerer med hinanden om b\u00e5ndbredden for klienten. Dette kan resultere i, at indl\u00e6sningstiden for materialer, der er kritiske for at danne siden, bliver meget l\u00e6ngere end den tid, der kan opn\u00e5s under ideelle omst\u00e6ndigheder. Her er<\/a><\/noindex> en pr\u00e6sentation om HTTP\/2-prioritering, hvor alt dette meget godt forklares.<\/p>\n

Det kan antages, at brugen af attributterne i links til eksterne ressourcer preconnect<\/code> vil hj\u00e6lpe med at l\u00f8se problemet. Men hvis der er for mange links til forskellige dom\u00e6ner, kan det faktisk overbelaste forbindelsen p\u00e5 det mest kritiske tidspunkt.<\/p>\n

Hvis man hoster tredjepartsressourcer selv, kan man kontrollere, hvordan disse ressourcer leveres til klienten. Det handler om f\u00f8lgende:<\/p>\n