Share
Hva du skal skapeGoogle PageSpeed er et gratis verktøy som vurderer ytelsen og brukervennligheten til nettstedet ditt for mobile og stasjonære plattformer. Det er ekstra viktig fordi Google bruker det til å bestemme viktige elementer i SEO-rangeringen, dvs. hvor høyt vi ser i søkeresultatene.
Hvis du vil ha mer bakgrunn om fordelene med økt sidens hastighet, les Mozos Hvorfor Site Speed Optimization bør være en del av SEO-strategien din, som fremhever, "... flere casestudier har vist raskere lasting av sidene sterkt korrelerer med høyere inntekter."
I denne opplæringen skal jeg gå gjennom noen tekniske tilnærminger for å optimalisere WordPress nettstedets PageSpeed. Mens grunnleggende endringer kan være ganske enkle og enkle, kan mer omfattende oppdateringer faktisk være ganske utfordrende.
Interessant kan egendefinerte nettsteder være enklere å optimalisere enn WordPress-nettsteder, det er på grunn av rammets omfattende bruk av tredjeparts temaer og plugins. Det er også basert på en arkitektur som ble designet før dens popularitet, og bygger på en ufullkommen arkitektur for bakoverkompatibilitet.
Før vi begynner, vær så snill og husk, jeg prøver å delta i diskusjonene nedenfor. Hvis du har et spørsmål eller et emneforslag, vennligst legg inn en kommentar nedenfor eller kontakt meg på Twitter @ reifman. Jeg er interessert i din erfaring med WordPress og PageSpeed.
For denne opplæringen skal jeg fokusere på å forbedre mitt personlige nettsted, JeffReifman.com.
En stund tilbake, min PageSpeed var Mobile 65 og Desktop 64 - ikke så bra:
Merk: her er artikkelen å lese om du er nysgjerrig på morsomt mobil skjermbilde med Russell Wilson.
Før vi begynner å gjøre optimaliseringer, la oss snakke om noen av de grunnleggende WordPress-ytelsesfaktorene.
Det er noen viktige måter å begynne å optimalisere ditt WordPress-nettsted for ytelse og økt PageSpeed.
PageSpeed av ulike temaer er sterkt påvirket av antall og størrelse på JavaScript-filer og CSS de bruker, antall bilder som brukes og deres størrelse, og tilnærmingen til mobilimplementasjonen, det vil si typisk lydhør i dag.
Hvis du er i markedet for et nytt WordPress-tema og vil evaluere PageSpeed, kan du bli overrasket over at poengene for kjente temaer ofte kjører på 60- og 70-tallet, men også opp til 90-tallet. Her er et par artikler som vurderer temaer og PageSpeed via ColorLib og WPMU. I hvert fall forventet jeg høyere.
Jeg har brukt My Site My Way's Construct-tema i flere år. Interessant, selskapets støtteside gikk stille sist, og de har ikke etterlatt noen forklaring for brukerne.
Men fordi det ikke blir noen oppdateringer på temaet, gjør det det litt enklere for meg å gjøre noen radikale endringer i resultatene for denne opplæringen uten å måtte håndtere fremtidige kodeoppdateringer fra firmaet. Jeg kommer snart til dette.
Bruke dedikerte servere vil mest sannsynlig utføre bedre enn stadig mer vanlige og rimeligere delte virtuelle servere. Tidligere har jeg skrevet om hvordan du installerer WordPress på delte tilbydere som Digital Ocean. Det er også mellomliggende tjenester som WP Engine, som gir en oppmerksomhet til utviklere og både delte og dedikerte servere.
Kvaliteten til verten vil også ha betydning. Mange delte WordPress-leverandører med bare-bein kan gi inkonsekvent ytelse.
For eksempel bruker jeg KnowHow-temaet både i Publishing med WordPress, som er hostet på en virtuell digital virtuell server og Flee the Jungle som er vert for WP Engine. Nettstedene er ganske like i innholdsvikt, f.eks. tekst og bildebruk. PageSpeed for Publishing med WordPress SideSpeed er Mobile 73 og Desktop 88, mens Flee the Jungle på WP Engine var litt raskere (Mobile 78 og Desktop 91); WP Engine's managed hosting er litt raskere enn min self-hosting med en delt server.
Jeg har også sett dårlig ytelse med Amazons low-end AWS hosting. Du får det du betaler for.
WordPress-caching er kritisk for ytelse, og jeg har regelmessig skrevet om mine favoritter: W3TC og Larn Cache, f.eks. Optimalisering av WordPress med Larn og W3 Total Cache.
En annen tjeneste som er kritisk, er et innholdsleveringsnettverk. Tidligere skrev jeg om å akselerere innholdsleveransen med KeyCDN for Envato Tuts + og bestemte deg for å bytte til dem.
Regelmessig å redusere dimensjonene og filstørrelsen på bildene på tvers av WordPress er tidkrevende, men likevel kritisk.
Jeg bruker regelmessig Acorn som et lettvektsverktøy for å raskt nedskalere bilder på nettet. Jeg lo da noen tweeted nylig at de nettopp hadde åpnet Photoshop og ville være tilgjengelig for telefonsamtaler for en stund mens den lastet - Acorn er liten og rask. At Adobe-abonnementsmodellen er så treg å laste-beklager, abonnenter.
Det finnes også automatiserte bildeoptimeringsprogrammer som WP-Smush. Jeg begynte nylig å eksperimentere med KeyCDNs nye Optimus. Også, her er WPMUs sammendrag av de 10 beste bildeoptimeringsverktøyene for å øke hastigheten på WordPress-siden din.
I økende grad får jeg også tilgang til bilder på mitt innlegg eksternt fra Flickr. For eksempel, da innlegget mitt om Seattles Amazon-drevne nabolagsvekst gikk viral på Slashdot, var det ingen ytelsesproblemer eller båndbreddekostnader for alle bildene, fordi Flickr håndterte det.
Du kan lese Google PageSpeeds Image Optimization Guide, men jeg har i økende grad funnet at Google-hjelp er altfor forskningsorientert (som er hyggelig å ha som ressurs), men ikke veldig nyttig for å løse problemer selv. Det kan være en for mange PhD'er der og en for få faktiske brukere.
Mens jeg alltid har hatt W3TC og Larn, økte KeyCDN og Optimus min PageSpeed to Mobile 72 og Desktop 82, en god forbedring fra 65 og 64:
Interessant nok, ser Google's bildebufringsklager ut som om de kan fortsette på ubestemt tid, uansett hva du forbedrer. For denne opplæringen eksperimenterte jeg med å optimalisere noen av de identifiserte gjenværende lovbryterne for å se hva som ville skje. Resultatet var interessant, og jeg forteller deg mer om det snart.
Hvis du har gjort alle de store grunnleggende over, viser det seg å kreve betydelig innsats for å forbedre PageSpeed med WordPress, og det kan være ganske tidkrevende..
Et statisk nettsted har vanligvis en fil med CSS og JS inkluderer som enkelt kan minifiseres og kombineres. WordPress er mye mer komplisert.
Så mye er opprettet dynamisk gjennom WordPress-ahem-mindre enn perfekt arkitektur. Det kan ta tid å finne hvor filer blir opprettet, enten de er i temaene eller pluginene, og hvordan du kan løse disse problemene. Det viser seg at når du har syv plugins, inkludert JavaScript-filer, og du vil minimere og kombinere dem til en, samtidig som du tillater vanlig pluginoppgraderinger, er det en ganske utfordring.
Oppdatering av W3TC HTML minifiser innstillinger raskt løst PageSpeeds klage om det.
For CSS måtte jeg enkelt legge til filene PageSpeed varslet meg om å W3TCs CSS File Management. W3TC begynte deretter å minifisere min CSS og kombinere de navngitte filene til en enkelt fil for å inkludere.
Dette løste PageSpeeds CSS-mineringskrav.
Det har også redusert antall CSS-filer som rapporteres for gjengeblokking fra syv til fire temarelaterte filer (oppført først under Optimaliser CSS-levering):
De tre gjenværende filene var fra plugin kataloger utenfor mitt tema (som vi vil utforske senere):
Jeg håper dette gir deg en følelse av kaninens hull som WordPress PageSpeed optimalisering blir raskt.
Selv om det er ganske enkelt å redusere og slå sammen CSS, har JavaScript en tendens til å mislykkes mye når du prøver å gjøre dette, og skaper store, nettstedbruddende feil.
Interessant, tilbyr PageSpeed nå komplette zip-nedlastninger av komprimerte versjoner av filene dine, som det ikke liker.
Det opplistet ti av mine JS-filer som jeg ønsket at jeg skulle fikse:
Til referanse er her flere Google PageSpeeds minimeringsressurser for HTML, CSS og JS. Jeg har også gjort bruk av Refresh SF, som gir enkel tilgang til ulike komprimeringsverktøy.
Komprimering og kombinering av JavaScript kan definitivt lage bugs, så jeg måtte ta ting trinnvis. Ved å bruke W3TCs JS File Management, minifiserte jeg og kombinerte de syv JS-filene i Construct-temaet:
Dette tillot meg ikke å adressere mine plugins JS-filer eller problemer jeg så med en mystisk, ukjennelig eksternt hosted base.js-fil. La oss gå videre til Render Blocking-problemer og deretter gå tilbake til JS-minifisering etter.
Hvis du har et stort utvalg av filer som må lastes inn i stil (CSS) og aktivere (JS) funksjonaliteten til websiden din, vil de fleste nettlesere avta etter at fire ressurser er forespurt parallelt.
Her er et eksempel på at CSS gjør blokkeringsklager i PageSpeed:
Mens W3TC hadde kombinert mange av dem til sin include.c46b63.css, var de neste tre over fra mine plugins.
Blogger Justin Tadlock tilbød noen veiledning som forklarer hvordan man spør WordPress for ikke å laste CSS-filene som pluginene mine hadde krevd for lasting. Svaret er å avregistrere dem og deretter laste en kombinert fil på egen hånd.
Her er Innholdsfortegnelsen plugin enqueuing sine JS og CSS-filer:
Accentsconagua
/ ** * Registrer og last CSS og javascript filer for frontend. * / funksjon wp_enqueue_scripts () $ js_vars = array (); // registrer våre CSS og skript wp_register_style ('toc-screen', $ this-> path. '/screen.min.css', array (), TOC_VERSION); wp_register_script ('toc-front', $ this-> path. '/front.min.js', array ('jquery'), TOC_VERSION, true); // enqueue dem! hvis (! $ this-> alternativer ['exclude_css']) wp_enqueue_style ("toc-screen"); hvis ($ this-> alternativer ['smooth_scroll']) $ js_vars ['smooth_scroll'] = true; wp_enqueue_script ('toc-front');Etter Tadlocks forslag, har jeg avregistrert pluginet mitt i temaets funksjoner.php, først CSS-du må finne referansene som brukes av plugin-utvikleren:
add_action ('wp_print_styles', 'my_deregister_styles', 100); fungere my_deregister_styles () wp_deregister_style ('toc-screen'); wp_deregister_style ('blogsynthesis_jss_css'); wp_deregister_style ('edd-stiler'); Jeg opprettet manuelt en kombinert CSS-fil med de tre plugin-stilarkene. Deretter spurte jeg W3TC om å redusere og kombinere den filen til sitt eget mega-stilark:
Det er et stort problem her ved at når jeg oppdaterer mine plugins, må jeg kanskje oppdatere denne kombinerte CSS-filen og tilhørende JS-filer.
Her er et blogginnlegg med noen andre tilnærminger du kan bruke til disse utfordringene.
Ved hjelp av Tadlocks tilnærming, er det det som SideSpeed gjengir blokkering så ut som etterpå:
Jeg fulgte de samme trinnene for JS-filer, bare litt mer nøye. Etter hvert ble min PageSpeeds JS-klage for nettstedet mitt ganske liten:
Som du ser nedenfor, klarte det imidlertid også å klage på problemer med nettleservisning med JS-filer jeg ikke kunne finne koblinger til i kodebase som ad_status.js fra Doubleclick.
Fjerne en legendarisk YouTube-spiller Embed
Til slutt fant jeg ut at både JS-minifiseringsproblemet og dette caching-problemet var relatert til bruken av en ekstern YouTube videospiller.
Mens jeg var nysgjerrig på å prøve en liten løsning som ble foreslått her for å hindre at videoen lastes ut uten brukers handling, bestemte jeg meg for å bare fjerne videoen fra min startside lysbildefremvisning.
Det er sannsynlig at måten min Construct-tema innebygde YouTube-filer var en eldre løsning. YouTubes HTML5-støtte kan fungere mye bedre nå. Likevel er det litt morsomt hvordan en Google-tjeneste påvirker ytelsesscore av en annen Google-tjeneste.
Hvis du fjerner den ene funksjonen på min hjemmeside som innebygde en YouTube-video, løst noen problemer:
Siden jeg ikke vil at du skal gå glipp av å se min bedre halvdel før jeg ble ødelagt av WordPress, vil jeg inkludere videoen her. Jeg pleide å være en fin fyr.
Her er det som skjedde:
Når de tidligere JS-endringene ble gjort, og videoen ble fjernet, løste JavaScript-minifiseringsproblemet meg for min PageSpeed-mester:
Feilsøkingsfeilen for nettleseren med Doubleclick vist nedenfor forsvant også.
Nå behøvde jeg faktisk bare å cache gpt.js og ga.js, to ytterligere vert Google-tjenester:
Dette viste seg å være ganske stort hinder og krevde mye kompleksitet for å løse disse problemene fullt ut. Den beste løsningen er å være vert for en kopi av Googles skript for Analytics og DFP, og bruk cron-skript for å regelmessig oppdatere dem på serveren din. Alice begynte å bli kjedelig med meg - håper du fortsatt følger med.
Jeg så på andre temaer jeg bruker med Google Analytics-plugin-modulen (Construct har innstillinger for Analytics), og de adresserte heller ikke dette.
Så jeg lagde lokale kopier av skriptene til Google Analytics og Google DFP, og kort tid etter ble hurtigkoblingen min løst i PageSpeed:
Her er mer informasjon fra Google på Browser Caching, igjen en veldig dyp teknisk ressurs uten mye veiledning for WordPress-administratorer.
Google kan gi felles grupperinger av de populære JavaScript-filene som er omarbeidet og kombinert for å bedre støtte utgiveres PageSpeed. Det ville også hjelpe hvis de ikke lastet filene sine individuelt og uklart i skript.
La oss kort gå tilbake til SideSpeed-bildekvalitetsklager før du pakker inn.
Google PageSpeeds bildeforslag kan faktisk svekke bruken av nettstedet ditt. Her er et eksempel, et kjennetegnet bilde jeg vert på på min hjemmeside.
For at mine innlegg skal vises på Facebook med et miniatyrbilde, krever det sosiale nettverket minimum dimensjoner på 200 piksler på korteste side. Min versjon er 281 x 200 (vist her litt justert for Tuts + krav):
Og her er versjonen fra PageSpeed i sin zippede nedlasting:
Du kan se at kvaliteten er enda verre, men viktigere, PageSpeed vil at jeg skal krympe bildet til en dimensjon som Facebook ikke ville akseptere for å vise i innleggene sine.
Til slutt valgte jeg å forlate nettstedet mitt med en håndfull SideSpeed-bildeoptimaliseringsklager, og sank min score.
Etter alt dette arbeidet, hvor endte nettstedet mitt?
De endelige PageSpeed-scoreene inkluderte Mobile 70, som viser noen av de resterende klagerne nedenfor:
Her er bildet optimaliseringer igjen:
Og her er et sammendrag av alle de bestått reglene:
Også her er de endelige UX-poengene. De fleste nettsteder har ikke store problemer med disse, så jeg ikke adresserte dem i dag:
Den endelige Desktop-poengsummen var 86, ikke dårlig:
JavaScript er finicky. Jeg var aldri i stand til å minimere og kombinere de to siste filene i den første. Selv forlater dem ukomprimerte jobbet aldri. Arbeide med temaer og plugins er vanskelig. Det ville ha krevd flere dager med dedikert arbeid for å løse dette.
Her er klager på bildefilstørrelsen:
Til slutt tok optimalisering av min PageSpeed mye tid og krefter, og la nettstedet mitt være sårbart for fremtidig plugin og Google-skriptoppdateringer. Mye av dette arbeidet er ganske forvirrende, detaljorientert og tidkrevende. Det er også litt galskap og åndsdyktig. Takk google.
PageSpeed er ikke alt. Innholdet er også viktig. Her er noen få kjente sider og deres PageSpeed. Resultatene vil overraske deg.
Daring Fireball (DF) er en av de raskeste innholdsfokuserte bloggene. Det fremmer annonsører på en minimal måte. Sidene løper lett og fort. Gruber's CMS er en tilpasset versjon av Movable Type. Resultatene er bare litt tøffere enn nettstedet mitt. DF genererer også mange inntekter med minimal annonsering.
Åpenbart en stor nyhetsorganisasjon, de har forferdelige PageSpeed-poeng:
Forresten, vår lokale klut med sin forferdelige reklame og abonnementstoppmodell er mye verre:
Et populært e-handelsnettsted, B & H Photo, har en forferdelig mobil score og en desktop score like under min:
Du har kanskje hørt om dette selskapet i mitt siste essay Hvordan lage WordPress-områder forskjellig etter geografi-de selger mange ting online. Mine PageSpeed-poeng er vesentlig høyere enn deres:
I fremtiden vil jeg se på noen få forbedringer for å forbedre sidens sidehastighet på siden min:
Hvis jeg ikke migrerer temaer kort, må jeg implementere det cron-skriptet for å synkronisere mine autoserverte Google-skript for Analytics og DFP, og finne ut hvordan du overvåker pluginoppdateringer for JS- og CSS-endringer. Jeg må kanskje returnere disse spesifikke PageSpeed gevinster, ærlig.
Hvis du har spørsmål, vennligst legg inn dem nedenfor. Eller du kan kontakte meg på Twitter @ reifman. Vennligst sjekk ut min Envato Tuts + instruktørside for å se andre opplæringsprogrammer jeg har skrevet, for eksempel min oppstartsserie (Bygg opp oppstart med PHP).
