Välkommen till del två i vår serie på Google PageSpeed. I det första avsnittet optimerade jag PageSpeed på min webbplats sedan temaet MySiteMyWay's Construct. Jag lyckades nå 70 Mobile och 86 Desktop.
Men med MySite stängning valde jag ett nytt tema och nådde en 100 PageSpeed för mobil och skrivbord. Det tog mig ungefär 12 timmar extra ansträngning för att uppnå detta. Nu är min webbplats prestanda ett av de snabbaste WordPress-sidorna jag har sett på länge, kolla in det. Browsing är nästan ögonblicklig.
I denna handledning går jag igenom hur jag uppnått detta och vad jag lärde mig om WordPress och Google PageSpeed. För mycket av dagen arbetade jag på det, jag trodde att jag skulle kunna tappa ut på 90-talet. Jag blev förvånad lite när det hoppade plötsligt till 100 för skrivbordet - och det fanns bara några detaljer kvar för att maximera mobilen.
För de som inte vet är Google PageSpeed ett gratis verktyg som bedömer prestandan och användbarheten för din webbplats för mobila och stationära plattformar. Det är extra viktigt eftersom Google använder det för att bestämma viktiga delar av vår SEO-rankning, dvs hur hög vi visas i sökresultaten.
Om du vill ha mer bakgrund om fördelarna med ökad webbplatshastighet, läs Mozarts varför webbplatshastighetsoptimering borde vara en del av din SEO-strategi. Det framhävs, "... flera fallstudier har visat snabbare lastning av sidor starkt i samband med högre intäkter."
I slutändan tog optimering av min PageSpeed mycket tid och ansträngning och lämnade min webbplats sårbar för framtida plugin och Google-skriptuppdateringar. Många av detta arbete är ganska förvirrande, detaljorienterat och tidskrävande. Det är också lite galet och sinnessjuk. Tack, Google.
En statisk webbplats har vanligtvis en fil med CSS och JS innehåller som enkelt kan miniföras och kombineras. WordPress är mycket mer komplex. Så mycket skapas dynamiskt genom WordPress's-ahem-less än perfekt arkitektur.
Det kan ta tid att hitta var filer skapas, oavsett om de finns i teman eller pluginprogrammet och hur man hanterar dessa problem. Det visar sig att när du har sju plugins inklusive JavaScript-filer och du vill minimera och kombinera dem till en, inkludera samtidigt som du tillåter vanliga pluginuppgraderingar, är det en ganska utmaning i WordPress-världen att ständigt ändra teman och plugins.
Detta gör många utvecklare ledsna:
Bildkredit: Mitt foto från Picasso Museo i Paris. Kan nu kallas "Sad Developer Confronting PageSpeed of Mobile 55 / Desktop 62"
Med det sagt, låt mig uppmuntra dig genom att visa hur jag gjorde det (du har inget nytt att göra idag, gör du?). Tänk på att webbplatsens behov kan skilja sig lite från min.
Innan vi börjar, kom ihåg, jag försöker delta i diskussionerna nedan. Om du har en fråga eller ett ämnesförslag, vänligen skriv en kommentar nedan eller kontakta mig på Twitter @ reifman. Jag är intresserad av din erfarenhet av WordPress och PageSpeed.
Om du är på marknaden för ett nytt WordPress-tema och vill utvärdera PageSpeed, kan du bli förvånad över att poängen för kända teman ofta löper på 60- och 70-talen men också upp till 90-talet. Här är några artiklar som utvärderar teman och PageSpeed via ColorLib och WPMU. I alla fall förväntat jag mig högre.
Precis som ett exempel på industrins förväntningar, visar The New York Times-webbplatsen 53/55 för mig, långt under 100.
PageSpeed av olika teman påverkas starkt av antalet och storleken på JavaScript-filer och CSS de använder, antalet bilder som används och deras storlek, och tillvägagångssättet för deras mobilimplementering, det vill säga typiskt lyhörd nuförtiden. Vissa skapare verkar inte se på deras PageSpeeds när de bygger.
För denna handledning kommer jag att fokusera på att förbättra min personliga webbplats, JeffReifman.com. Jag valde Medium by Array Themes av några anledningar.
Den första var dess baslinjehastighet. Medellång värdering Mobile 74 och Desktop 89 för att starta från deras demoserver. Även om detta redan var lite bättre än jag hade maximerat Konstruera till, var det ett mer modernt tema och det fanns många återstående optimeringssteg jag kunde försöka. Jag hoppades att PageSpeed skulle komma in i 80-talet eller 90-talet.
Också, med tanke på tillväxten av mobilläsare, ville jag flytta ifrån att förlita mig på sidofält - särskilt för reklamplacering (Jag hoppas kunna skriva om mina nya intäkter i vårt pågående Google DFP-serien). Medium-temat gör ett bra jobb att lägga i vänster sidofält i en lyhörd meny och dölja dess högra sidofält.
Här var den ursprungliga PageSpeed för demo av Medium (demo hosting är aldrig tätt optimerad). Det var faktiskt uppmuntrande att se att det hade många oadresserade problem eftersom det visade att det var bättre än min optimerade Construct innan extra ansträngning tillämpades och liknande uppgifter som jag visste för att utföra för att maximera poängen:
Här är fler av frågorna:
Och mer:
Och användaren upplever utmaningar, som var mer lokaliserade:
Slutligen, här är dess demo Desktop poäng:
Uppmuntrat av grundresultatet köpte jag och installerade Medium-temat på min server och kom till jobbet.
Tänk på att förändrade teman kan vara ganska komplicerade. För mig, ersättning, eliminering och uppdatering av inbyggda kortkoder från Construct-temat tog mest tid, och jag är inte helt klar, t.ex. dropcaps, pullquote-variationer, knappar, flikar och sidbaserade navigeringsmenyer. Min driva för 100 drev mig för att tråka framåt oavsett. Hur man utför masssökning och ersätt i WordPress erbjuder några bra lösningar för att hitta och ersätta kortnummer.
Medan denna handledning inte leder dig genom exakta steg för att höja sidans PageSpeed till 100, kommer den att vägleda dig genom många möjliga lösningar och identifiera vanliga väglås. Det finns en annan stor generaliserad resurs som jag delar i slutet.
Jag kontaktade ArrayThemes lite om sub-100 demo-prestanda för Medium-temat. De skickade ett utmärkt svar:
PageSpeed optimeringstestet ska tas med ett saltkorn ... vår demo är dinged för att inte cache, men vi behöver inte faktiskt cachning på våra demos ... PageSpeed-förslag är inte helt exakta eller exemplifierande av prestanda för ett tema. Det beror helt och hållet på din installation, server, caching och andra optimeringar du bestämmer dig för att göra.
Detta gör en perfekt startpunkt för att granska de gemensamma grundelementen för WordPress-prestanda. Alla områden av prestanda nedan adresserar underliggande PageSpeed poäng, inte helt men grunderna.
WordPress-caching är kritisk för prestanda, och jag har regelbundet skrivit om mina favoriter: W3TC och Larn Cache, t.ex. Optimera WordPress med Larn och W3 Total Cache.
Det visar sig att det finns en handfull plugins som är utformade för att hjälpa dig att ta utmaningen till effektiv caching. Här är två av de bästa jag försökte:
Bildkredit: WordPress Tavern
Båda var hjälpsamma, men inte heller helt borttagna hinder för mig relaterade till PageSpeed, som att bädda in CSS inom mina tagg för att ta bort PageSpeed-problem med andra ord kommer det här pluginet sannolikt inte dig hela vägen till 100 PageSpeed. Jag hittade Dependency Minification att vara effektiv och hjälpsam, men den bristande flexibiliteten gjorde att jag gick bort.
I slutändan skulle jag återkommande återvända till W3 Total Cache och hitta nya kraftfullare sätt att trycka på det för prestanda. Det är inte perfekt och definitivt har några UX-fel, det fungerade bra på tillräckligt sätt för att jag skulle hitta min väg med andra tillvägagångssätt för PageSpeed 100.
Till slut valde jag bara ett nytt plugin som gjorde det enkelt att ta bort PageSpeed-problem med Disqus-jag kommer att granska det här nedan.
En annan tjänst som är kritisk är ett innehållsleveransnät. Tidigare skrev jag om Accelerate Your Content Delivery med KeyCDN på Envato Tuts + och bestämde mig sedan för att byta till dem som kund.
I slutändan finns det en mängd olika CDN-skivor du kan välja bland, till exempel CloudFlare och RackSpace för att nämna några.
Nyligen började jag experimentera med KeyCDNs nya Optimus-bildoptimeringstjänst och WordPress-plugin. Det finns en liten möjlighet att drivas av robotar byggda med gamla Apple Lisas och Mac:
Det fungerar bra, men ett annat populärt alternativ är WP-Smush, ett äldre plugin med mer än 300.000 användare.
Om du har ett stort antal filer som behöver laddas till stil (CSS) och aktivera (JS) funktionaliteten för din webbsida, kommer de flesta webbläsare att sakta ner när fyra resurser begärs parallellt.
Här är ett exempel på att CSS gör blockeringsklagom i PageSpeed:
Detta kan vara ett svårt WordPress-objekt att eliminera tack vare temat och plugin-arkitekturen. Vi kommer tillbaka till det.
Om du har gjort alla de viktigaste grunderna ovan visar sig att förbättra din PageSpeed med WordPress att kräva betydande ansträngningar och kan vara ganska tidskrävande.
Låt oss gå steg för steg genom de identifierade problemområdena och hur jag löste dem. I själva verket gjorde jag en stor mängd experiment med olika verktyg och metoder. Jag släppte regelbundet ett tillvägagångssätt och återvände till en annan. Min lösning visade sig vara en ganska välskött patchwork av lösningar. Banan var inte direkt Yoda.
Det här är till exempel hur du minimerar HTML inom W3 Total Cache:
På samma sätt är det enkelt att minimera JavaScript i W3 Total Cache. Notera nedan att jag instruerar W3TC att bädda in den komprimerade filen inte i men istället precis innan
. Fördröjning av JavaScript kan förbättra din PageSpeed-poäng.
Eftersom både teman och plugins använder JavaScript och CSS, tar det lite arbete för att minimera dem tillsammans och kombinera dem i en enda fil (och det är inte ens nog för PageSpeed som jag kommer att diskutera längre fram nedan).
För att blockera plugins från att ladda egna CSS och instruera W3TC för att ladda komprimerade och kombinerade versioner, måste du hitta pluginhandtaget för CSS-filen (skillnad från filnamn) och lägga till kod i ditt tema för att avbryta plugin-laddningsinstruktionerna. Ange sedan sökvägen till varje CSS-fil i dialogrutan W3TC ovan för att läsas in med de andra.
Blogger Justin Tadlock erbjöd lite vägledning för att förklara hur man frågar WordPress om att inte ladda CSS-filerna som mina plugins hade kalkylerat för laddning. Svaret är att avregistrera dem och ladda sedan en kombinerad fil på egen hand.
Här är min Innehållsförteckning plugin enqueuing dess JS och CSS-filer:
/ ** * Registrera och ladda CSS och javascript-filer för frontend. * / funktion wp_enqueue_scripts () $ js_vars = array (); // registrera vår CSS och 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! om (! $ this-> options ['exclude_css']) wp_enqueue_style ("toc-screen"); om ($ this-> options ['smooth_scroll']) $ js_vars ['smooth_scroll'] = true; wp_enqueue_script ('toc-front');
Efter Tadlocks förslag, avregistrerade jag mitt plugin ingår i mitt temas funktioner.php, som börjar med CSS-du måste hitta referenser som används av pluginutvecklaren:
add_action ('wp_print_styles', 'my_deregister_styles', 100); funktion my_deregister_styles () wp_deregister_style ('toc-screen');
Jag skapade manuellt en kombinerad CSS-fil med de tre plugin stylesheetsna. Sedan frågade jag W3TC att minifiera och kombinera den filen i sin egen mega-stil som ovan.
W3TC kan kombinera alla mitt tema och plugin-filer, men PageSpeed tycker fortfarande inte om att se även en CSS inkluderar (så mycket för bra HTML-utvecklingsmetoder):
Jag lade till slut nio CSS-filer (endast sju som visas nedan). För det första måste du hitta pluginhandtag för CSS och avregistrera dem i ditt tema som beskrivits ovan. Då måste du peka dem alla på W3TC.
Medan det finns flera sätt att få en minifierad version av alla dessa, tog jag faktiskt bara W3TCs komprimerade fil. Jag tog bort alla argument för caching-frågan, t.ex.. ?cbe3w2
, med sökning och ersätt i TextEditor. Jag är fortfarande en lojal TextMate-användare, men det hade faktiskt stora förseningar och hänger när jag försökte navigera i en minifierad CSS-fil. Så TextEditor hjälpte mig att redigera dessa filer individuellt. Apologies till purister, jag har inte flyttat till Sublime än.
Medan det fungerade för mig att klistra in mina minifierade CSS i min rubrik, behövde jag senare ändra den för att dynamiskt få innehållet i CSS-filer och eko dem på plats.
När jag lagt till en annan plugin för social delning, klistrade inte längre arbetade och jag var tvungen att separera filerna med ovanstående mekanism. Detta ger också mer flexibilitet för framtiden. Google PageSpeed ser aldrig detta, och min Larn-cache döljer någon avmattning av att inkludera två filer.
I slutändan konfigurerade jag alla mina CSS-filer i W3TC, gjorde kopior av de komprimerade filerna och släckte sedan den här funktionen:
En brist på W3TC är att det upprepade gånger visar irriterande felmeddelanden trots att du medvetet använder den på ett ovanligt sätt.
När du flyttar CSS-filer ur plugin-kataloger, se till att du anger korrekta sökvägar till bilder och så vidare för att fungera från webbplatsens rotkatalog. Jag hade många situationer där bilder inte skulle laddas tills jag hittade var man ska lösa dessa saker. Jag delar ett exempel i Felsökning avsnitt nedan.
Amusingly klagar Googles PageSpeed om du laddar sina JavaScript-bibliotek externt. Jag fick avgränsningar för externa skript relaterade till Flickr, Disqus och Google Analytics:
Det visade sig vara ett ganska stort hinder och kräver mycket tid och komplexitet för att helt lösa dessa problem.
Först hade jag nyligen återvänt från en resa till Indien och satt enskilda blogginlägg med Flickr-inbäddade bilder på hemsidan. Mitt mellantema rullar snabbt igenom ett antal inlägg, så PageSpeed klagade över dem alla.
Efter att ha observerat att PageSpeed klagade både om Flickr-värdinställda inbäddade bildstorlekar (vid olika pixeltal) och att se dessa externa JavaScript-demeriter, återvände jag till optimerade bilder på min webbplats. De länkar fortfarande till Flickr för mitt pågående Indien-album.
Detta är ett bra exempel på hur du försöker använda en kraftfull tredjepartstjänst med det enkla syftet med att bädda in bilder dödar din PageSpeed-poäng. Flickr har inte gjort ett optimalt jobb för att hjälpa WordPress-användare att lösa detta. Precis som ett exempel skulle de behöva:
Med mina återstående Google-filer var den bästa lösningen att lokalt vara värd för en kopia av skript för Analytics och DFP och använd cron-skript för att regelbundet uppdatera dem på en server.
Först slutade jag använda mitt Google Analytics-plugin och manuellt tillagd ändrad kod till mitt temarubrik:
// ...
Observera att jag ändrade banorna till mina lokala kopior av skripten. Sedan gjorde jag lokala kopior av skript för Google Analytics och Google DFP, och kort efter att min webbläsare blivit löst i PageSpeed förutom Disqus.
Jag är inte säker exakt om det gäller säkerhet eller stöd för flera plattformar eller ren "smart", men Disqus och andra leverantörer som Flickr verkar dölja själva filerna som de laddar med andra filer. Detta gör det mycket svårare och ofta olösligt att optimera PageSpeed.
Givetvis spenderade jag två till tre timmar på olika sätt att optimera Disqus-plugin-ingenting fungerade för mig.
I slutändan avinstallerade jag Disqus-plugin och installerade Disqus Conditional Load:
Medan det är tänkt att göra många saker, gör det också möjligt att optimera PageSpeed med installationen.
Plötsligt var PageSpeed's hävstångsinställningar för webbläsaravbrott borta. Kudos till DCL!
PageSpeed klagar ofta på länkar som är för nära avstånd i mobila enheter. Jag experimenterade med några tillvägagångssätt och slutade slutligen att visa taggar på mobila enheter.
Om jag spenderar mer tid kan jag förmodligen förbättra sina UX och skicka med PageSpeed.
ArrayToolkit Plugin, som visar följer ikoner i det högra sidofältet, slutade fungera för mig. Det tog mig ett tag att avgöra vilka vägar som behövs för att kodas med absoluta vägar för att få det att fungera.
I slutändan hittade och ersatte jag dessa vägar med korrigerade relativa sökvägar till den ursprungliga plugin katalogen:
// Måste ställa in sökvägen 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 '); typsnitt: normal; typsnittstyp: normal;
Jag har fortfarande ett problem som jag behöver lösa. Min nya flikpluggar (Construct hade inbyggda flikar) slutade fungera längs vägen. Jag behöver bara spendera tid att felsöka det, men det borde vara ganska lätt att sortera ut.
Jag experimenterade med YUI Compressor med W3TC för att komprimera mina JavaScript och CSS-filer. I stället för att leda till ökad hastighet, bröt allt slags.
Om du är intresserad av att ta reda på vad jag gjorde fel kan du installera Java och YUICompressor så här:
#good 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
Vänligen posta i kommentarerna om du vet hur man gör det bra med WordPress.
Efter den andra omgången av arbetet med det nya temat fungerade allt bättre än jag hade hoppats. Jag var aldrig säker på att jag skulle nå mitt optimala mål.
Jag gjorde 100 PageSpeed för både mobil och skrivbord. Ännu mer märkbart, min webbplats körde super-snabbare än jag någonsin haft en bloggrulle innan. Jag är väldigt nyfiken på hur inkommande söktrafik och läsaraktivitet reagerar på snabbare resultat och prestanda under de närmaste månaderna.
Här är mina sista PageSpeed-poäng, först Mobil:
Och nu skrivbordet:
Skrivbordet nådde 100 först, och jag var tvungen att gå tillbaka och avsluta några justeringar (adressering av mål) för att få mobil där.
Och igen gör webbplatsens hastighet det värt ett snabbt besök. Om du känner till andra kommersiella webbplatser som körs vid 100 PageSpeed, dela dem i kommentarerna. Jag skulle gärna se dem.
Precis som ett exempel på SEO-förändringar hoppade min populära uppsats om dating till tredje rangordnade på mobila resultat under "Seattle dating"(inte på skrivbordet ännu.) Detta berättar att kanske berättelser på viktiga webbplatser slår det har dåliga mobila sidhastigheter, för det är inte lätt.
För att maximera sidans sidaSpeed måste jag göra ett antal anpassningar till mitt tema, vilket nu kommer att skapa beroenden vid ändringar i externa skript och uppdateringar av temat och plugin. Nu när jag är klar med mitt kortsiktiga mål har jag jobb att göra för att organisera mina system för att hantera det här lättare.
Snart måste jag implementera det cron-skriptet för att synkronisera mina självhävdas Google-skript för Analytics och DFP.
Här är ett företag som ger ett enklare tillvägagångssätt för att använda Analytics utan att PageSpeed straffas och fastställer den sista punkten på Google PageSpeed Insights. Jag skulle hellre inte förlita mig på andra tredje parter.
Jag måste också bättre följa medias teman uppdateringar och integrera förändringar. Att bygga ett barntema från mina ändringar kan också underlätta denna process. För det mesta letar jag efter ändringar som överskrider min, uppdaterade (eller ytterligare) JavaScript och CSS-filer.
På samma sätt, när plugins uppdateras, måste jag titta på samma slags uppdateringar. Det kan hjälpa mig att bättre organisera min användning av GitHub med WordPress plugins. Jag använder det redan för mitt tema.
Jag kanske vill spendera lite tid på att skriva skript för att spåra vilka JavaScript och CSS-filer som används med det uppdaterade temat och plugin, ladda ner dem till min server och minimera och paketera lämpliga filer för att länka eller inkludera.
Slutligen är en av mina förvånningar att SSL inte krävs för att uppnå en PageSpeed på 100. Det här är något men menar att en mängd olika komponenter kan påverka din Google-sökrankning. Jag ska skriva om att implementera Låt oss krypteras gratis SSL med WordPress snart.
Om du har haft det här men vill läsa en mer generell handledning som inte går så djupt in i specifika saker som kan eller kanske inte gäller för dig, är KeyCDNs Google PageSpeed Scoring 100/100 med WordPress ett utmärkt komplementärt stycke. Jag har också skrivit ett sponsrat stycke om deras CDN på Envato Tuts + (Accelerate Your Content Delivery med KeyCDN) och fortsatte att fortsätta med dem som kund.
Under tiden, om du letar efter andra verktyg för att hjälpa dig att bygga upp din växande uppsättning verktyg för WordPress eller för att koden ska studera och bli mer välbevandrad i WordPress, glöm inte att se vad vi har tillgängliga i Envato Marknadsföra.I framtiden tittar jag på några fler förbättringar för att förbättra min webbplatss övergripande prestanda. Dessa inkluderar:
Om du har frågor, vänligen posta dem nedan. Eller du kan kontakta mig på Twitter @ reifman. Kolla in min Envato Tuts + instruktörssida för att se andra handledning som jag har skrivit, till exempel Kloning WordPress på Linux (på 90 sekunder).