Share
Hva du skal skapeVelkommen til del to av serien vår på Google PageSpeed. I den første episoden optimaliserte jeg PageSpeed av siden min, da temaet MySiteMyWay's Construct. Jeg klarte å komme til 70 Mobile og 86 Desktop.
Men med MySites nedleggelse valgte jeg et nytt tema og nådde en 100 PageSpeed for mobil og skrivebord. Det tok meg ca 12 timer med ekstra innsats for å oppnå dette. Nå er ytelsen til nettstedet mitt et av de raskeste WordPress-nettstedene jeg har sett på lenge, sjekk det ut. Browsing er nesten øyeblikkelig.
I denne opplæringen vil jeg gå gjennom hvordan jeg oppnådde dette og hva jeg lærte om WordPress og Google PageSpeed. For mye av dagen jobbet jeg på det, jeg trodde jeg kunne komme seg ut på 90-tallet. Jeg ble overrasket litt da det hoppet plutselig til 100 for Desktop - og det var bare noen få detaljer igjen for å maksimere Mobile.
For de som ikke vet, er Google PageSpeed 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. Det fremhever, "... flere casestudier har vist raskere lasting av sider sterkt korrelerer med høyere inntekter."
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.
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 vanlige pluginoppgraderinger, er det en ganske utfordring i WordPress-verdenen med stadig skiftende temaer og plugins.
Dette gjør mange utviklere triste:
Bildekreditt: Mitt bilde fra Picasso Museo i Paris. Kan nå bli kalt "Sad Developer Confronting PageSpeed of Mobile 55 / Desktop 62"
Når det er sagt, la meg oppmuntre deg ved å vise hvordan jeg gjorde det (du har ikke noe nytt å gjøre i dag, gjør du?). Husk at nettstedets behov kan avvike fra meg litt.
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.
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.
Akkurat som et eksempel på industriens forventninger, viser The New York Times-nettsiden 53/55 for meg, langt under 100.
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, dvs. typisk responsiv i dag. Noen skapere ser ikke ut til å se på deres PageSpeeds når de bygger.
For denne opplæringen skal jeg fokusere på å forbedre mitt personlige nettsted, JeffReifman.com. Jeg valgte Medium by Array Themes av noen grunner.
Den første var dens baseline hastighet. Medium score Mobile 74 og Desktop 89 for å starte fra demo serveren. Selv om dette allerede var litt bedre enn jeg hadde maksimert Construct to, var det et mer moderne tema, og det var mange gjenværende optimaliseringssteg jeg kunne prøve. Jeg håpet å bringe PageSpeed inn i de høye 80-tallene eller i 90-årene.
Også, gitt veksten av mobillesere, ønsket jeg å bevege meg bort fra å stole på sidebjelker - spesielt for annonsering plassering (Jeg håper å skrive om mine nye inntektsretninger i vår pågående Google DFP-serie). Medium-temaet gjør en god jobb med å legge til venstre sidebjelke i en responsiv meny og skjule den rette sidebjelken.
Her var den første PageSpeed for demo av Medium (demo hosting er aldri tett optimalisert). Det var faktisk oppmuntrende å se at det hadde mange uadresserte problemer fordi det viste at det var bedre enn min optimaliserte Construct før ekstra innsats ble brukt og lignende oppgaver jeg visste å utføre for å maksimere sin score:
Her er flere av problemene:
Og mer:
Og brukeren opplever utfordringer, som var mer lokalisert:
Endelig er her sin demo Desktop score:
Oppmuntret av grunnlagsscore, kjøpte jeg og installerte medium-temaet på serveren min og kom til å jobbe.
Husk at endring av temaer kan være ganske komplisert. For meg erstattet, fjernet og oppdaterte innebygde kortkoder fra Construct-temaet tok mest tid, og jeg er ikke fullstendig ferdig, for eksempel dropcaps, pullquote variasjoner, knapper, faner og sidebaserte navigasjonsmenyer. Min stasjon for 100 presset meg til å trekke frem uansett. Slik utfører du massesøk og erstatt i WordPress tilbyr noen gode løsninger for å finne og erstatte kortkoder.
Mens denne opplæringen ikke veileder deg gjennom nøyaktige trinn for å øke sidens SideSpeed til 100, vil det lede deg gjennom mange mulige løsninger og identifisere vanlige veisperre. Det er en annen stor generell ressurs jeg deler på slutten.
Jeg kontaktet ArrayThemes litt om sub-100-demoytelsen til Medium-temaet. De sendte et utmerket svar:
PageSpeed optimaliseringstest bør tas med saltkorn ... vår demo blir dinged for ikke caching, men vi trenger ikke faktisk caching på våre demoer ... PageSpeed-forslag er ikke helt nøyaktige eller eksemplariske av ytelsen til et tema. Det vil avhenge av oppsett, server, caching og andre optimaliseringer du bestemmer deg for å lage.
Dette gir et perfekt startpunkt for å se på de grunnleggende grunnleggende elementene for WordPress-ytelsen. Alle områdene av ytelse nedenfor adresserer underliggende PageSpeed-poeng, ikke helt, men det grunnleggende.
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.
Det viser seg at det er en håndfull plugin som er laget for å hjelpe deg med å utfordre effektiv caching. Her er to av de beste jeg prøvde:
Bilde kreditt: WordPress Tavern
Begge var hjelpsomme, men heller ikke fjernet hindringer for meg relatert til PageSpeed, for eksempel innebygd CSS i min tag for å fjerne PageSpeed-problemer med andre ord, vil dette pluginet ikke sannsynligvis få deg helt til 100 PageSpeed. Jeg fant Dependency Minification å være effektiv og nyttig, men mangelen på fleksibilitet gjorde meg gå bort.
Til slutt ville jeg gjentatte ganger gå tilbake til W3 Total Cache og finne nye, kraftigere måter å trykke den på for ytelse. Det er ikke perfekt og definitivt har noen UX-feil, det fungerte bra på nok måter for meg å finne veien min med andre tilnærminger til PageSpeed 100.
Til slutt valgte jeg bare ett nytt plugin som gjorde det enkelt å fjerne PageSpeed-problemer med Disqus-jeg vil gjennomgå dette videre nedenfor.
En annen tjeneste som er kritisk, er et innholdsleveringsnettverk. Tidligere skrev jeg om å akselerere innholdsleveransen med KeyCDN på Envato Tuts + og bestemte seg for å bytte til dem som kunde.
Til slutt er det en rekke CDNer du kan velge mellom, for eksempel CloudFlare og RackSpace for å nevne noen få.
Nylig begynte jeg å eksperimentere med KeyCDNs nye Optimus-bildeoptimaliseringstjeneste og WordPress-plugin. Det er en liten mulighet det drives av roboter bygget med gamle Apple Lisas og Mac:
Det fungerer bra, men et annet populært alternativ er WP-Smush, et eldre plugin med mer enn 300.000 brukere.
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:
Dette kan være et hardt WordPress-element for å eliminere på grunn av temaet og pluginarkitekturen. Vi kommer tilbake til det.
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..
La oss gå trinnvis gjennom de identifiserte problemområdene og måtene jeg løst dem på. I sannhet gjorde jeg en stor mengde eksperimentering med forskjellige verktøy og tilnærminger. Jeg dro jevnlig en tilnærming og returnerte til en annen. Min løsning viste seg å være en ganske godt administrert patchwork av løsninger. Stien var ikke direkte Yoda.
For eksempel, hvordan kan du minimere HTML i W3 Total Cache:
På samme måte er det enkelt å minimere JavaScript i W3 Total Cache. Merk under at jeg instruerer W3TC for å legge inn den komprimerte filen ikke i men i stedet like før . Forsinkelse av JavaScript kan forbedre din PageSpeed-poengsum.
Fordi begge temaer og plugins bruker JavaScript og CSS, tar det litt arbeid for å minimere dem sammen og kombinere dem til en enkelt fil (og det er ikke engang nok for PageSpeed, som jeg vil diskutere nærmere nedenfor).
For å blokkere pluginene fra å laste inn sitt eget CSS og instruere W3TC for å laste komprimerte og kombinerte versjoner, må du finne pluginets håndtak for CSS-filen (forskjellig fra filnavn) og legge til kode i temaet ditt for å avbryte plugin-lastningsinstruksjonene. Deretter skriver du banen til hver CSS-fil i W3TC-dialogboksen ovenfor for å bli lastet inn med de andre.
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 mitt temas funksjoner.php, som starter med 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'); Jeg opprettet manuelt en kombinert CSS-fil med de tre plugin-stilarkene. Deretter spurte jeg W3TC om å redusere og kombinere den filen med sin egen mega-stilark som vist ovenfor.
W3TC kan kombinere alle mine tema- og pluginfiler, men PageSpeed liker fortsatt ikke å se enda en CSS inkludere (så mye for gode HTML-utviklingspraksis):
Jeg lastet til slutt ni CSS-filer (bare syv vist nedenfor). For det første må du finne pluginhåndtak for CSS og avregistrere dem i ditt tema som beskrevet ovenfor. Da må du peke dem alle til W3TC.
Mens det er flere måter å få en minifisert versjon av alle disse, tok jeg faktisk bare W3TCs komprimerte fil. Jeg fjernet alle caching-spørringsargumentene, f.eks. ?cbe3w2, med søk og erstatt i TextEditor. Jeg er fortsatt en lojal TextMate-bruker, men det hadde faktisk store forsinkelser og henger når jeg prøvde å navigere i en minifisert CSS-fil. Så TextEditor hjalp meg til å redigere disse filene enkeltvis. Unnskyldninger til purister, jeg har ikke flyttet videre til Sublime ennå.
Mens det virket for meg å lime inn min forminskede CSS i toppteksten, måtte jeg senere endre den for å dynamisk få innholdet i CSS-filer og ekko dem på plass.
Når jeg har lagt til en annen plugin for sosial deling, limte ikke lenger arbeidet, og jeg måtte separere filene med den ovennevnte mekanismen. Dette gir også mer fleksibilitet for fremtiden. Google PageSpeed ser aldri dette, og min Larn-cache skjuler enhver avmatning av å inkludere to filer.
Til slutt konfigurerte jeg alle mine CSS-filer i W3TC, lagde kopier av de komprimerte filene, og slått av denne funksjonen:
En mangel på W3TC er at det gjentatte ganger viser irriterende feilmeldinger, selv om du bevisst bruker den på en uvanlig måte.
Når du flytter CSS-filer ut av plugin-kataloger, må du sørge for at du angir riktige relative baner til bilder og så videre for å operere fra nettstedets rotkatalog. Jeg hadde mange situasjoner der bilder ikke ville lastes før jeg fant hvor å løse disse tingene. Jeg vil dele et eksempel i Feilsøking delen nedenfor.
Amusingly klager Googles SideSpeed om du laster inn JavaScript-bibliotekene eksternt. Jeg mottok demeritter for eksterne skript relatert til Flickr, Disqus og Google Analytics:
Dette viste seg å være ganske stort hinder og krever mye tid og kompleksitet for å løse disse problemene fullt ut.
Først hadde jeg nylig returnert fra en tur til India og satt individuelle blogginnlegg med Flickr-innebygde bilder på hjemmesiden. Mitt middels tema ruller raskt gjennom en rekke innlegg, så PageSpeed klaget over dem alle.
Etter å ha observert at PageSpeed klaget både om Flickr-vert-innebygde bildestørrelser (ved ulike pixeltall) og se disse eksterne JavaScript-demeritter, returnerte jeg til selvbehandlede optimaliserte bilder på nettstedet mitt. De knytter fortsatt til Flickr for mitt pågående India-album.
Dette er et godt eksempel på hvordan du prøver å bruke en kraftig tredjepartstjeneste med det enkle formålet med å legge inn bilder, dræper din PageSpeed-poengsum. Flickr har ikke gjort en optimal jobb for å hjelpe WordPress-brukere med å løse dette. Bare som et eksempel, ville de måtte:
Med mine gjenværende Google-filer var den beste løsningen å være lokalt vert for en kopi av skript for Analytics og DFP, og bruk cron-skript for regelmessig å oppdatere dem på en server.
Først stoppte jeg med å bruke Google Analytics-plugin-modulen min og manuelt lagt til endret kode til temaets overskrift:
// ...
Legg merke til at jeg endret stiene til mine lokale kopier av skriptene. Deretter lagde jeg lokale kopier av skriptene for Google Analytics og Google DFP, og kort tid etter at nettleseren min ble cached ble løst i PageSpeed med unntak av Disqus.
Jeg er ikke sikker på om det er for sikkerhet eller multiplattformstøtte eller ren "klokhet", men Disqus og andre tilbydere som Flickr synes å skjule de faktiske filene de laster med andre filer. Dette gjør optimalisering av PageSpeed mye vanskeligere og ofte uoppløselig.
Admittedly, jeg brukte to til tre timer prøver forskjellige tilnærminger for å optimalisere Disqus plugin-ingenting fungerte for meg.
Til slutt avinstallerte jeg Disqus-pluginet og installerte Disqus Conditional Load:
Mens det er ment å gjøre mange ting, gjør det også mulig å optimalisere PageSpeed med installasjon.
Plutselig var PageSpeeds Utnyttelse Browser Caching-demeritter borte. Kudos til DCL!
PageSpeed klager ofte på koblinger for nært plassert i mobile enheter. Jeg eksperimenterte med noen tilnærminger og til slutt stoppet bare å vise merker på mobile enheter.
Hvis jeg bruker mer tid, kan jeg sannsynligvis forbedre deres UX og passere med PageSpeed.
ArrayToolkit-pluginet, som viser følg ikoner i høyre sidefelt, sluttet å fungere for meg. Det tok meg en stund å finne ut hvilke stier som skulle kodes med absolutte stier for å få det til å fungere.
Til slutt fant jeg og erstattet disse banene med korrigerte relative baner til den opprinnelige plugin katalogen:
// Måtte sette sti i plugin css @ font-face font-family: 'array'; src: url ('./ fontello / array.eot'); src: url ('./ fontello / array.eot # iefix') format ('embedded-opentype'), url ('./ fontello / array.woff') format ('woff'), url ('./ fontello /array.ttf ') format (' truetype '), url (' ./ fontello / array.svg # array ') format (' svg '); font-weight: normal; font-style: normal; Jeg har fortsatt et problem som jeg trenger å løse. Pluginet min nye faner (Konstruksjonen hadde innebygde faner) sluttet å jobbe underveis. Jeg trenger bare å bruke tid på å feilsøke det, men det skal være ganske enkelt å sortere ut.
Jeg eksperimenterte med YUI Compressor med W3TC for å komprimere JavaScript og CSS-filene mine. I stedet for å føre til økt hastighet, brøt alt slags.
Hvis du er interessert i å finne ut hva jeg gjorde galt, kan du installere Java og YUICompressor slik:
#god luck sudo apt-get install openjdk-6-jre cd / usr / local / lib sudo wget https://github.com/yui/yuicompressor/releases/download/v2.4.8/yuicompressor-2.4.8.jar
Vennligst legg inn i kommentarene hvis du vet hvordan du skal gjøre det bra med WordPress.
Etter denne andre arbeidsrunden på det nye temaet virket alt bedre enn jeg hadde håpet. Jeg var aldri sikker på at jeg ville nå mitt optimale mål.
Jeg scoret 100 PageSpeed for både mobil og skrivebord. Enda mer merkbart ble nettstedet mitt kjørt super-raskere enn jeg noensinne har hatt en blogg før. Jeg er veldig nysgjerrig på hvordan innkommende søketrafikk og leseraktivitet reagerer på de raskere resultatene og ytelsen de neste månedene.
Her er mine siste PageSpeed-poeng, først Mobil:
Og nå Desktop:
Desktop nådde 100 først, og jeg måtte gå tilbake og fullføre noen justeringer (adressering av mål) for å få mobil der.
Og igjen, gjør hastigheten på nettstedet det verdt et raskt besøk. Hvis du vet om andre kommersielle nettsteder som kjører på 100 PageSpeed, vennligst del dem i kommentarene. Jeg vil gjerne se dem.
Akkurat som et eksempel på SEO-endringer, hoppet mitt populære essay på dating til tredje rangerte på mobile resultater under "Seattle dating"(ikke på skrivebordet ennå.) Dette forteller meg at kanskje historier på store nettsteder slår det har dårlig mobil PageSpeeds, fordi det ikke er lett.
For å maksimere sidens sidehastighet, måtte jeg gjøre en rekke tilpasninger til temaet mitt, som nå vil skape avhengigheter ved endringer i eksterne skript og oppdateringer til temaet og pluginene. Nå som jeg er ferdig med mitt kortsiktige mål, har jeg jobb å gjøre for å organisere systemene mine for å gjøre det lettere å håndtere dette.
Snart må jeg implementere det cron-skriptet for å synkronisere mine selvbehandlede Google-skript for Analytics og DFP.
Her er et selskap som gir en enklere tilnærming til å bruke Analytics uten at PageSpeed blir straffet, og fastsetter det siste punktet på Google PageSpeed Insights. Jeg vil helst ikke stole på andre tredjeparter.
Jeg må også bedre følge medans temaoppdateringer og integrere endringer. Å bygge et barnemne fra endringene mine kan også lette denne prosessen. For det meste vil jeg lete etter endringer som overskriver min, oppdaterte (eller flere) JavaScript- og CSS-filer.
Tilsvarende, når oppdateringer oppdateres, må jeg se etter de samme oppdateringene. Det kan hjelpe meg å bedre organisere min bruk av GitHub med WordPress plugins. Jeg bruker det allerede for mitt tema.
Jeg vil kanskje bruke litt tid på å skrive skript for å spore hvilke JavaScript- og CSS-filer som er i bruk med det oppdaterte temaet og pluginene, laste dem ned til min server og minimere og pakke de aktuelle filene for å lenke eller inkludere.
Endelig er en av mine overraskelser at SSL ikke er nødvendig for å oppnå en PageSpeed på 100. Dette gir noe fornuft, men fremhever at en rekke forskjellige komponenter kan påvirke Google-søkerangeringen din. Jeg skal skrive om implementering La oss kryptere sin gratis SSL med WordPress snart.
Hvis du har hatt glede av dette, men vil lese en mer generell opplæring som ikke går så dypt inn i detaljer som kan eller ikke gjelder for deg, er KeyCDNs Google PageSpeed Scoring 100/100 med WordPress et utmerket komplementært stykke. Jeg har også skrevet et sponset stykke om deres CDN på Envato Tuts + (Accelerate Content Delivery With KeyCDN) og fortsatte å fortsette med dem som kunde.
I mellomtiden, hvis du leter etter andre verktøy for å hjelpe deg med å bygge ut ditt voksende sett med verktøy for WordPress eller koden for å studere og bli mer kjent med WordPress, ikke glem å se hva vi har tilgjengelig i Envato Marked.I fremtiden vil jeg se på noen få forbedringer for å forbedre nettstedets samlede ytelse. Disse inkluderer:
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 Cloning WordPress i Linux (på 90 sekunder).
