Hidastavatko natiivit widgetit sivustosi? Suorituskyvyn vaikutus mitattuna

Taboolan, Outbrainin, MGID:n ja Revcontentin natiivit widgetit lisäävät mitattavissa olevaa latausaikaa, pääasiassa kolmannen osapuolen JavaScriptin, ylimääräisten mainospalvelimen kierrosten ja näkymän alapuolella latautuvien kuvatiedostojen kautta. Kuinka paljon se haittaa riippuu voimakkaasti toteutuksesta: asynkronisesti ladattu, laiskasti renderöity widget näkymän alapuolella maksaa paljon vähemmän kuin synkroninen skripti, joka estää pääsäikeen yläosassa.

Mistä suorituskyvyn kustannus todella tulee#

Sisältösuosituswidget ei ole yksittäinen pyyntö. Sen asentaminen tyypillisesti laukaisee:

• Julkaisijan oman skriptitagin, joka latautuu asynkronisesti useimmissa moderneissa toteutuksissa, vaikka vanhemmat integraatiot latautuvat joskus vielä synkronisesti ja estävät renderöinnin
• Kutsun verkon mainospalvelimelle noutamaan kyseisen sivun ja käyttäjän suositussarjan
• Lisäksi kysyntäpuolen ja header-bidding -kierrokset jos verkko käyttää programmaattisia huutokauppoja suoramyynnin sijaan, mikä voi ketjuttaa useiden header bidding -kumppanien kautta
• Kuvat tai pikkukuvatiedostot jokaiselle suositellulle kohteelle, tyypillisesti 6–12 per widget-instanssi
• Seurantapikselit renderöinnin ja napsautuksen yhteydessä, sekä verkolle että alaspäin oleville mainostajan seurannoille

Jokainen näistä lisää viivettä, ja ne kasaantuvat. Widget, joka näyttää "yhdeltä skriptitagilta" CMS:ssäsi, voi laukaista tusinan tai enemmän verkkopyyntöjä kun se todella renderöityy.

Mitä tämä tekee Core Web Vitals -mittareille erityisesti#

Mittarit, jotka todennäköisimmin muuttuvat:

CLS on se, joka kaataa useimmat julkaisijat, koska se on myös se, jota Googlen sivukokemussignaalit painottavat näkyvimmin. Jos widgetisi latautuu ilman varattua säilön kokoa, sivu hyppää näkyvästi kun se täyttyy, mikä on juuri sitä mitä CLS rankaisee.

Miksi sama widget toimii eri tavalla eri sivustoilla#

Kaksi julkaisijaa, jotka käyttävät teknisesti samaa Taboola- tai Outbrain-integraatiota, voivat nähdä merkittävästi erilaisia Core Web Vitals -tuloksia, ja ero johtuu lähes aina ympäröivästä sivusta, ei widget-koodista itsestään. Sivu, joka on jo kevyt, minimaaliset kolmannen osapuolen skriptit, optimoidut kuvat, nopea isännöintipino, imee yhden asynkronisen widgetin hyvin pienellä näkyvällä vaikutuksella, koska sivun latausbudjetissa on ylimääräistä kapasiteettia. Sivu, joka kantaa jo useita muita kolmannen osapuolen skriptejä (analytiikka, chat-widgetit, toinen mainosverkko, sosiaaliset upotukset) ylittää kynnyksen, jossa natiivin widgetin pyynnöistä tulee ne, jotka käyttäjät todella huomaavat, vaikka se saattaisi olla pieni osa sivun kokonaispainosta. Jos vianetsit suorituskykyvalitusta widgetin lisäämisen jälkeen, tarkista ensin kaikki muu sivulla pyörivä; widget on usein viimeksi lisätty, näkyvin epäilty, mutta ei välttämättä todellinen pullonkaula.

Kuinka asentaa sellainen ilman, että nopeuspisteesi romahtaa#

Ero widgetin välillä, joka ei maksa mitään mitattavaa, ja sellaisen, joka näkyvästi hidastaa sivustosi, johtuu yleensä toteutusvalinnoista, ei itse verkosta:

1. Lataa skripti asynkronisesti, ei koskaan estävällä synkronisella tagilla sivun yläosassa
2. Varaa säilölle tila kiinteällä korkeudella tai kuvasuhteella CSS:llä ennen widgetin täyttymistä, estääksesi layout-shiftin
3. Lataa laiskasti näkymän alapuolella, jotta widgetin pyynnöt eivät kilpaile ensisijaisen sisällön kanssa kaistanleveydestä alkuperäisen sivulatauksen aikana
4. Sijoita se pääsisällön jälkeen, ei vain lukijakokemuksen vuoksi, vaan koska se luonnollisesti viivästyttää latauksen kunnes LCP:täsi määrittävä sisältö on renderöitynyt
5. Rajoita itsesi yhteen widget-instanssiin per sivu mahdollisuuksien mukaan; useiden suosituswidgetien pinoaminen kertoo pyyntömäärän vähenevällä tuotolla
6. Testaa todellisella laitteen kaistanrajoituksella, ei vain työpöytälaajakaistalla; mobiili 4G -suorituskyvyssä widgetin paino näkyy kivuliaimmin

Onko tuotto nopeuden vaihtokaupan arvoinen?#

Tämä on todellinen päätös, ja se riippuu siitä, mitä sivun nopeus on arvoinen tiettyä sivustoasi varten. Jos luotat voimakkaasti orgaaniseen hakuliikenteeseen ja sivukokemus vaikuttaa merkittävästi rankingeihisi, huonosti toteutettu widget, joka vetää Core Web Vitals -pisteitäsi alas, voi maksaa enemmän hakunäkyvyydessä kuin se tuottaa mainostuloissa. Jos liikenteesi tulee enimmäkseen suorasta, sosiaalisesta tai uutiskirjelähteistä, joissa hakuranking on pienempi tekijä, nopeuden kustannus merkitsee vähemmän suhteessa RPM-kasvuun.

Kummassakin tapauksessa korjaus on harvoin "älä käytä natiiveja widgetejä." Se on lähes aina "korjaa toteutus." Hyvin toteutettu asynkroninen, laiskasti ladattu, oikein mitattu widget Taboolalta, Outbrainilta, MGID:ltä tai Revcontentilta maksaa murto-osan huonosti toteutetusta, samalla tuotolla.

Kuinka OpenAdLibrary auttaa sinua vertailemaan ennen sitoutumista#

Ennen kuin lisäät widgetin verkosta, jota et ole käyttänyt, kannattaa nähdä miltä sen inventaario ja muoto todella näyttävät muilla sivuilla, ei vain myyntipuheesta. OpenAdLibrary antaa selata live-mainoksia Taboolalta, Outbrainilta, MGID:ltä, Revcontentilta ja muilta verkoilta nähdäksesi muodon, kuvatiheyden ja napsautusmekaniikat, jotka todella integroit, mikä on konkreettisempi perusta toteutuspäätökselle kuin pelkkä demotili.

Kuinka mitata vaikutus oikeasti omalla sivullasi#

Älä luota yleisiin vaikutusarvioihin, mukaan lukien tämän artikkelin alueet. Mittaa oma sivusi suoraan:

1. Perustaso ensin. Suorita avainsivusi PageSpeed Insightsin tai WebPageTestin kautta ennen mitään asennusta, ja tallenna LCP, CLS ja INP sivusi kokonaispainon ja pyyntömäärän rinnalla.
2. Asenna widget, ja testaa sitten samat sivut samoissa olosuhteissa. Käytä rajoitettua mobiiliyhteyden profiilia, ei vain rajoittamatonta työpöytää, koska siellä vaikutus näkyy yleensä eniten.
3. Eristä widgetin osuus erityisesti, useimmat testausvälineet antavat suodattaa vesiputken pyynnön alkuperän mukaan, joten voit nähdä tarkalleen kuinka paljon widget itse vastaa kokonaislatausajastasi ja pyyntömäärästäsi verrattuna sivusi perustasoon.
4. Testaa uudelleen toteutuskorjausten jälkeen (asynkroninen lataus, varattu säilön korkeus, laiska lataus) sen sijaan, että olettaisit korjauksen toimineen. Pienet toteutusyksityiskohdat, kuten onko säilön korkeus asetettu kiinteällä pikseliarvolla vs. responsiivisella kuvasuhtelaatikolla, voivat tuottaa merkittävästi erilaisia CLS-tuloksia samalla peruswidgetillä.
5. Toista säännöllisesti, ei vain kerran käynnistyksen yhteydessä. Verkot muuttavat joskus omaa skriptikäyttäytymistään tai mainostiheyttään ajan myötä ilman julkaisijalle suunnattua ilmoitusta, joten asetelma, joka mittasi puhtaasti kuusi kuukautta sitten, kannattaa tarkistaa uudelleen.

Yleiset toteutusvirheet#

Muutama toistuva ongelma vastaa suurimmasta osasta vältettävissä olevaa suorituskyvyn kustannusta:

• Ei varattua säilön korkeutta, joten sivu hyppää näkyvästi kun widget täyttyy, vahingoittaen suoraan CLS:ää
• Widgetin sijoittaminen pääsisällön yläpuolelle tai sisään sen sijaan, että se olisi sen jälkeen, kilpaillen todellisen sisältösi kanssa alkuperäisen latauksen kaistanleveydestä ja prioriteetista
• Useiden widget-instanssien pinoaminen yhdellä sivulla, kertomalla pyyntömäärä rajallisella lisätuotolla
• Vanhemman synkronisen integraatiolohkon käyttö, jonka julkaisija kopioi vuosia sitten eikä koskaan tarkistanut uudelleen, kun verkko on sittemmin julkaissut asynkronisen version
• Ei testata mobiililla erityisesti, missä hitaammat yhteydet ja pienemmät näkymät tekevät sekä latausajan että layout-shift -ongelmista näkyvämpiä kuin ne näyttäisivät työpöytälaajakaistalla

Useimmat näistä ovat kertaluonteisia korjauksia mallipohjakoodissasi, ei jatkuvia ylläpitotaakkoja, mikä tekee niistä arvoisia tehdä kunnolla kerran sen sijaan, että kärsisi jatkuvasta, mitattavasta hidastuksesta jokaisella sivulatauksella.

Bottom line#

Natiivit widgetit lisäävät mitattavaa painoa, ja CLS on yleensä se mittari, jota tulee tarkkailla tarkimmin. Kustannus on suurelta osin toteutuslaadun funktio (asynkroninen lataus, varattu säilötila, laiska lataus näkymän alapuolella) sen sijaan, että se olisi mainosmuodon luontainen ominaisuus. Mittaa oma ennen-ja-jälkeen todellisella laitetestauksella sen sijaan, että olettaisit vaikutuksen maineen perusteella, ja korjaa toteutusongelmat ennen kuin päättelet, että muoto itsessään ei ole sen arvoinen.