Vahingossa hidas vs tarkoituksella hidas

Teen yleensä eron vahingossa hitaan ja tarkoituksella hitaan välillä. Opi, miten tämä voi auttaa sinua parantamaan Core Web Vitals -tuloksia

Arjen Karel - linkedin

Last update: 2024-07-13

Vahingossa hidas vs tarkoituksella hidas.

Kun palkkaat minut korjaamaan tai puhumaan Core Web Vitals -tuloksista, jossain vaiheessa kuulet minun puhuvan termistä vahingossa hidas vs tarkoituksella hidas. Mielestäni tämä on kriittinen erottelu ja tässä artikkelissa selitän, miten tämä auttaa sinua parantamaan Core Web Vitals -tuloksia.

Table of Contents!

Vahingossa hidas vs tarkoituksella hidas.
Vahingossa hidas
Tarkoituksella hidas
Yhteenveto

Kun joku pyytää minua konsultoimaan ja korjaamaan Core Web Vitals -tuloksia, jokin on aina vialla. Hitaus johtuu aina anti-patterneista. Esimerkiksi 'Lazy Loaded Largest Contentful Paint -kuva', 'Suuret, optimoimattomat kuvat', 'Sliderit', 'estävä JavaScript' ja niin edelleen.

Anti-patternin luomiseen ei tarvita paljon. Joskus riittää, että asennat pluginin tai unohdat parhaat käytännöt hetkeksi.

Luokittelen nämä anti-patternit mieluusti 'vahingossa hitaisiin' ja 'tarkoituksella hitaisiin', koska tapa, jolla lähestyn niiden korjaamista, on täysin päinvastainen.

Vahingossa hidas

Rakastan 'vahingossa hidas' -anti-patterneja. Teit jotain, mikä hidasti sivua. Teit virheen. Et tiennyt, että tämän voi tehdä paljon nopeammin. Ei hätää, voin korjata virheet.

Näiden 'virheiden' luokittelu on siis järkevää. Se antaa minulle listan helposti korjattavista, suuren vaikutuksen parannuksista, jotka voin lähettää kehitystiimillesi (tai korjata itse). Keskustelua tarvitaan yleensä hyvin vähän. Näiden anti-patternien parantaminen on järkevää joka näkökulmasta. Kun ne on korjattu, Core Web Vitals -tulokset paranevat.

Tässä muutamia esimerkkejä anti-patterneista, joihin törmään päivittäin. Kun selitän mitä ja miksi, kuulen yleensä 'aah, en tiennyt, että tämä hidastaisi sivua'.

1. Ei-lazyladatut kuvat

Yleisin anti-pattern on ei-lazyladatut kuvat. Kuvat, joita ei ladata lazysti, asetetaan latausjonoon sivun latauksen alkuvaiheessa. Tämä käyttää verkko- ja CPU-resursseja. Ei ole järkevää kohdentaa arvokkaita resursseja kuviin, jotka eivät ole edes näkyvissä, eikö?

2. Kolmannen osapuolen fontit

Web-fontit ovat loistavia. Ne mukauttavat ja parantavat sivun ulkoasua ja tuntumaa. Valitettavasti kolmannen osapuolen palveluntarjoajan, kuten Google Fontsin, käyttö ei optimoi fontteja juuri sinun tilanteeseesi.

Kolmannen osapuolen fontit vaativat ylimääräisen renderöinnin estävän tyylitiedoston, uuden yhteyden verkkopalvelimeen (vaikka sinulla on jo todella nopea yhteys alkuperäispalvelimeesi) ja todennäköisesti lisäävät selaimeen enemmän fontteja kuin todellisuudessa käytät.

Olisi järkevämpää isännöidä fontteja itse, esiladata ne ja määrittää mukautettu optimointistrategia jokaiselle fonttitiedostolle. Siinä on taas yksi nopea voitto!

3. Kolmannen osapuolen skriptit

Vaikka kolmannen osapuolen skripteissä ei sinänsä ole mitään vikaa, ne aiheuttavat paljon ongelmia niiden sivuille lisäämistavan vuoksi. Törmään epätärkeisiin kolmannen osapuolen skripteihin (kuten Facebookin seurantapikselit, sosiaalisen median painikkeet, arviointi-widgetit jne.) jotka todellisuudessa estävät koko sivun lataamisen.

On suhteellisen helppoa ja järkevää viivästyttää ja ajoittaa nämä skriptit, kunnes selain on tehnyt tärkeämmän työn. Loppujen lopuksi en oikeasti muuttanut mitään kriittistä sivustolla, se näyttää edelleen samalta ja latautuu paljon nopeammin. Muutin vain järjestyksen, jossa asiat tehdään.

4. Taustakuvat

Core Web Vitals -näkökulmasta taustakuvat eivät ole järkeviä. Taustakuvia ei voi ladata lazysti, ne eivät ole responsiivisia ja niiden ajoitusta ja prioriteettia on vaikea hallita.

Muutamalla helpolla korjauksella voimme muuttaa nämä taustakuvat normaaleiksi kuviksi, jotka voimme ladata lazysti, tehdä responsiivisiksi ja säätää niiden prioriteettia. Tämä parantaa varmasti Largest Contentful Paint -tulosta.

5. Suuret tyylitiedostot

Tyylitiedostot estävät renderöinnin. Tämä tarkoittaa, että selain lataa tyylitiedostoja sivun pysyessä tyhjänä. Tämän korjaamiseen on monia keinoja. Voit esimerkiksi poistaa käyttämättömät tyylit, jakaa tyylitiedoston osiin, parantaa selaimen välimuistia tai lisätä Critical CSS:n.

Kun olemme parantaneet tyylitiedostot, Largest Contentful Paint ja First Contentful Paint paranevat dramaattisesti!

Tarkoituksella hidas

Tarkoituksella hidas on se osa, josta sinun pitäisi olla huolissaan. Teit rakenteellisia valintoja, jotka hidastivat sivua. Ne liittyvät yleensä UX-suunnitteluvalintoihin tai JavaScript-koodiin, joka muokkaa sivun näkyvää osaa siinä määrin, ettei hyviä kiertoteitä ole.

Ongelma 'tarkoituksella hitaan' kanssa on, ettei sitä voi korjata välittömästi pienillä muutoksilla. Se vaatii enemmän suunnittelua ja joidenkin sivuston ydintoimintojen uudelleenkirjoittamista.

Ensimmäinen asia, joka minun täytyy selvittää, on tarkoitus: Miksi teit näin? Mitkä olivat harkitut seikat ja mitä tarkalleen halusit saavuttaa? Ja sitten näiden parametrien puitteissa löytää parempi vaihtoehto!

Tässä joitain esimerkkejä yleisimmistä 'tarkoituksella hidas' -virheistä.

1. Sliderit

Sliderit toimivat yleensä näin: Kun sivu renderöityy, JavaScript injektoi sliderin sivulle. Ilman tätä JavaScriptiä sivu näyttäisi täysin erilaiselta. Tämä aiheuttaa pidemmän Largest Contentful Paint -ajan, todennäköisesti Cumulative Layout Shift -ongelman ja hyvin todennäköisesti ongelmia First Input Delayn kanssa.

Nopeaa korjausta ei ole. JavaScriptin viivästäminen parantaa paint-metriikoita mutta viivästyttää slideria ja aiheuttaa layout shiftin. Sliderin skriptin tekeminen kriittiseksi korjaa Cumulative Layout Shift -ongelman mutta hidastaa paint-metriikoita.

Ratkaisu on progressiivisesti parantaa sivua. Varmista ensin, että slideri renderöityy ilman JavaScriptiä, ja sitten paranna sivua ja muunna jo läsnä oleva sliderikuva täydeksi slideriksi.

Hauska juttu on: 9 kertaa 10:stä kun selitän tämän, sivuston omistaja ehdottaa heti sliderin poistamista. Siksi on tärkeää kysyä sliderien tarkoituksista ja harkituista seikoista. Yleensä ne 'olivat vain siellä'.

2. Tuotezoomaus

Tuotezoomaus toimii näin: tavallisessa verkkokaupassa vie hiiri tuotekuvan päälle ja voit zoomata tuotteen yksityiskohtiin. 'Tuotezoomauksilla' on yleensä sama ongelma kuin slidereilla. JavaScript-koodi ottaa kuvasi, piilottaa ne ja kirjoittaa ne uudelleen sivulle zoomattavina kuvina. Tämä aiheuttaa pidemmän Largest Contentful Paint -ajan, todennäköisesti Cumulative Layout Shift -ongelman ja hyvin todennäköisesti ongelmia First Input Delayn kanssa.

Ero slideriin on, ettei yksikään tuoteomistaja koskaan sano: "poista vain tämä toiminnallisuus". Se on tärkeä ja lisää konversiota.

Ratkaisu on sama kuin sliderin korjaus. Zoomausskriptin ei pitäisi piilottaa alkuperäisiä kuvia vaan laajentaa tuotekuvan toiminnallisuutta. Valitettavasti zoomaus-toiminnallisuutta ei yleensä ole helppo korjata ja se vaatii jonkin verran työtä, jotta se saadaan toimimaan oikein.

3. Inline jQuery / inline JavaScript -riippuvuudet

Inline jQuery on ongelma, joka alkoi 'vahingossa hitaana' mutta paheni ajan myötä. Noin 50 % sivustoista, joita tarkastelen, kärsii tästä ongelmasta. Koska inline-skriptit riippuvat aiemmasta skriptistä (yleensä jQuery), et voi enää viivästyttää jQueryä. Tämä viivästyttää kaikkia paint-metriikoita.

Korjaus on yksinkertainen: Siirrä nämä skriptit ulkoiseen skriptitiedostoon. Nyt voit viivästyttää sekä jQueryä että mukautettua skriptiä.

Miksi sitten sijoitin tämän 'tarkoituksella hidas' -kategoriaan? Kun kysyn tarkoituksesta ja harkituista seikoista, kuulen yleensä 'en tiedä'. Ja se on todellinen ongelma. JavaScriptin toiminnasta on puutteellinen ymmärrys. Voin olla melko varma, että tämä virhe toistetaan tulevaisuudessa. Tämä tarkoittaa, ettei ratkaisu ole sama kuin korjaus. Minun täytyy kouluttaa kehitystiimiä JavaScript-riippuvuuksista ja ajoituksesta.

4. Suuret (hero-)kuvat

Toinen tarkoituksella hidas -ongelma on suuret kuvat. Jotkut sivustot haluavat yksinkertaisesti 'häikäistä yleisön' suurilla täysikokoisilla kuvilla. Kuvittele, että myyt julisteita. Haluaisit todennäköisesti tarjota kävijöillesi korkealaatuisia, suuria kuvia. Nämä kuvat, riippumatta siitä kuinka paljon niitä optimoit, latautuvat aina hitaammin kuin pienemmät kuvat.

Tässä vaiheessa (olettaen, että kuvat on kaikki optimoitu) ainoa asia, jonka voin tehdä, on katsoa, onko liikkumavaraa. Tarvitsemmeko todella 4K-kuvia vai riittäisikö Full HD?

5. Interaktiiviset kartat

Toinen ongelma, johon törmään usein, on interaktiiviset kartat. Kun sivulla on interaktiivinen kartta, koko sivun tarkoitus on saada kävijä vuorovaikuttamaan kartan kanssa. On selvää, että kartan lataaminen kestää jonkin aikaa.

Tätä ei voi kiertää. Meidän on hyväksyttävä jonkin verran hitautta. Mutta voimme tehdä asioita. Voimme varmistaa, että kartat ladataan korkeimmalla prioriteetilla. Yleensä näitä sivuja ei ole optimoitu aikaiseen JavaScript-suoritukseen. Tässä tapauksessa se oli väärä valinta. Tarvitsemme skriptin latautuvan ja suoriutuvan mahdollisimman aikaisin!

6. Hitaat API:t

Tarkoituksella hidas -ongelmat, jotka johtuvat hitaista API:sta, löytyvät yleensä SPA-sivustoilta kuten REACT NextJS tai Angular. Hitaat API:t aiheuttavat yleensä suuria Cumulative Layout Shift -ongelmia, koska komponentit renderöityvät liian myöhään käyttäjän vuorovaikutuksen jälkeen. Tällaiset ongelmat vaativat yleensä monialaista lähestymistapaa

Yhteenveto

Voi olla hyödyllistä erottaa vahingossa hidas ja tarkoituksella hidas toisistaan Core Web Vitals -kontekstissa. Vahingossa hidas on yleensä helposti korjattavissa, kun taas tarkoituksella hidas vaatii perusteellisempaa, moniulotteista lähestymistapaa.