Share
Wat je gaat creërenGoogle PageSpeed is een gratis tool die de prestaties en bruikbaarheid van uw website voor mobiele en desktop-platforms beoordeelt. Het is extra belangrijk omdat Google het gebruikt bij het bepalen van de belangrijkste elementen van onze SEO-ranking, d.w.z. hoe hoog we worden weergegeven in hun zoekresultaten.
Als u meer achtergrondinformatie wilt over de voordelen van een hogere sitesnelheid, lees dan Moz's waarom optimalisatie van de locatiesnelheid onderdeel zou moeten uitmaken van uw SEO-strategie, waarin wordt benadrukt: "... uit verschillende casestudy's is gebleken dat sneller laden van pagina's sterk samenhangt met hogere inkomsten."
In deze zelfstudie laat ik u door enkele technische benaderingen gaan om de paginasnelheid van uw WordPress-website te optimaliseren. Hoewel basisveranderingen vrij eenvoudig en gemakkelijk kunnen zijn, kunnen uitgebreidere updates zelfs behoorlijk uitdagend zijn.
Interessant is dat aangepaste websites gemakkelijker te optimaliseren zijn dan WordPress-sites - vanwege het uitgebreide gebruik van thema's en plug-ins van derden door het framework. Het is ook gebaseerd op een architectuur die vóór zijn populariteit is ontworpen en vertrouwt op een imperfecte architectuur voor achterwaartse compatibiliteit.
Voordat we van start gaan, onthoud alsjeblieft dat ik probeer deel te nemen aan de onderstaande discussies. Als je een vraag of een suggestie voor een onderwerp hebt, plaats dan een reactie hieronder of neem contact met mij op via Twitter @reifman. Ik ben geïnteresseerd in je ervaring met WordPress en PageSpeed.
Voor deze tutorial ga ik me richten op het verbeteren van mijn persoonlijke website, JeffReifman.com.
Een tijdje geleden was mijn PageSpeed Mobile 65 en Desktop 64 - niet zo geweldig:
Opmerking: hier is het artikel om te lezen als je nieuwsgierig bent naar de grappige mobiele screenshot met Russell Wilson.
Voordat we beginnen met het maken van optimalisaties, laten we het hebben over enkele van de elementaire WordPress-prestatiefactoren.
Er zijn een paar belangrijke manieren om te beginnen met het optimaliseren van uw WordPress-site voor prestaties en een verhoogde PageSpeed.
De PageSpeed van verschillende thema's wordt sterk beïnvloed door het aantal en de grootte van JavaScript-bestanden en CSS die ze gebruiken, het aantal gebruikte afbeeldingen en hun grootte, en de benadering van hun mobiele implementatie, d.w.z. meestal responsief tegenwoordig.
Als u op de markt bent voor een nieuw WordPress-thema en PageSpeed wilt evalueren, zult u misschien verbaasd zijn dat de scores voor bekende thema's vaak in de jaren 60 en 70 maar ook tot in de jaren 90 worden gebruikt. Hier zijn een aantal artikelen waarin thema's worden beoordeeld en PageSpeed via ColorLib en WPMU. Ik verwachtte in elk geval hoger.
Ik heb het thema Construct van My Site My Way meerdere jaren gebruikt. Interessant is dat de ondersteuningssite van het bedrijf onlangs stil is gebleven en dat er geen uitleg is voor gebruikers.
Omdat het thema echter niet meer wordt bijgewerkt, wordt het voor mij een beetje eenvoudiger om een aantal radicale wijzigingen in de uitvoering ervan aan te brengen zonder rekening te hoeven houden met toekomstige code-updates van het bedrijf. Ik kom hier binnenkort op terug.
Het gebruik van dedicated servers zal hoogstwaarschijnlijk beter presteren dan steeds vaker voorkomende en beter betaalbare gedeelde virtuele servers. In het verleden heb ik geschreven over het installeren van WordPress bij gedeelde providers zoals Digital Ocean. Er is ook een tussenstation van services zoals WP Engine, die aandacht besteden aan ontwikkelaars en zowel gedeelde als dedicated servers.
De kwaliteit van de host zal er ook toe doen. Veel onbeschaamde WordPress-providers kunnen inconsistente prestaties leveren.
Ik gebruik bijvoorbeeld het KnowHow-thema op zowel Publishing with WordPress gehost bij een virtuele virtual Ocean-server als Flee the Jungle gehost bij WP Engine. De sites zijn redelijk vergelijkbaar wat betreft het gewicht van de inhoud, b.v. tekst- en beeldgebruik. De PageSpeed for Publishing met Paginasnelheid van WordPress is Mobile 73 en Desktop 88, terwijl Flee the Jungle bij WP Engine een beetje sneller was (Mobile 78 en Desktop 91); De managed hosting van WP Engine is iets sneller dan mijn self-hosting met een gedeelde server.
Ik heb ook slechte prestaties gezien met Amazon's low-end AWS-hosting. Je krijgt waar je voor betaalt.
WordPress-caching is essentieel voor de prestaties en ik heb regelmatig geschreven over mijn favorieten: W3TC en Varnish Cache, bijvoorbeeld WordPress optimaliseren met Varnish en W3 Total Cache.
Een andere dienst die van cruciaal belang is, is een netwerk voor de levering van inhoud. Eerder schreef ik over Accelerate Your Content Delivery met KeyCDN voor Envato Tuts + en besloot toen om over te schakelen naar hen.
Het regelmatig en kritisch uitvoeren van de afmetingen en bestandsgrootte van afbeeldingen in WordPress is vaak tijdrovend.
Ik gebruik Acorn regelmatig als een lichtgewicht hulpmiddel om snel afbeeldingen naar het web te verkleinen. Ik lachte toen iemand onlangs twitterde dat ze net Photoshop hadden geopend en dat het een tijdje beschikbaar zou zijn voor telefoongesprekken terwijl het werd geladen - Acorn is klein en snel. Dat Adobe-abonnementsmodel is zo traag om te laden - sorry, abonnees.
Er zijn ook geautomatiseerde plug-ins voor beeldoptimalisatie, zoals WP-Smush. Ik ben onlangs begonnen met het experimenteren met KeyCDN's nieuwe Optimus. Hier is ook de samenvatting van WPMU van de 10 beste beeldoptimalisatieplugins om uw WordPress-site te versnellen.
Steeds vaker krijg ik ook toegang tot beelden op mijn post extern van Flickr. Toen mijn bericht over Seattle's door Amazon gestuurde buurtgroei bijvoorbeeld op Slashdot viral verliep, waren er geen prestatieproblemen of bandbreedtekosten voor alle foto's, omdat Flickr het behandelde.
U kunt Google PageSpeed's Handleiding voor het optimaliseren van afbeeldingen lezen, maar ik heb steeds vaker ondervonden dat de hulp van Google overdreven onderzoeksgericht is (wat prettig is om als hulpmiddel te hebben), maar niet erg handig om problemen zelf op te lossen. Er kunnen daar te veel doctoraten zijn en een te weinig feitelijke gebruikers.
Hoewel ik altijd W3TC en Varnish heb gehad, heb ik met KeyCDN en Optimus mijn PageSpeed to Mobile 72 en Desktop 82 verbeterd, een goede verbetering ten opzichte van 65 en 64:
Interessant is dat Google's klachten over caching in afbeeldingen lijken alsof ze voor onbepaalde tijd kunnen doorgaan, ongeacht wat je verbetert. Voor deze zelfstudie heb ik geëxperimenteerd met het optimaliseren van enkele geïdentificeerde overgebleven overtreders om te zien wat er zou gebeuren. Het resultaat was interessant en ik zal je er binnenkort meer over vertellen.
Als je alle belangrijke basisbegrippen hierboven hebt gedaan, is het verbeteren van je PageSpeed met WordPress een aanzienlijke inspanning en kan het behoorlijk tijdrovend zijn.
Een statische site heeft meestal één bestand met CSS en JS bevat dat gemakkelijk kan worden verkleind en gecombineerd. WordPress is een stuk ingewikkelder.
Zoveel wordt dynamisch gecreëerd door WordPress-ahem-minder dan perfecte architectuur. Het kan enige tijd duren om te vinden waar bestanden worden gemaakt, of ze zich nu in de thema's of plug-ins bevinden en hoe deze problemen kunnen worden aangepakt. Het blijkt dat wanneer je zeven plug-ins hebt, waaronder JavaScript-bestanden, je ze wilt minimaliseren en combineren in een inclusief terwijl je gewone plug-in-upgrades toestaat, het is best een uitdaging.
Het bijwerken van mijn W3TC HTML-instellingen voor het verkleinen heeft snel de klacht van PageSpeed daarover opgelost.
Voor CSS moest ik afzonderlijk de bestanden toevoegen die PageSpeed me waarschuwde voor het CSS-bestandsbeheer van W3TC. W3TC begon vervolgens met het verkleinen van mijn CSS en het combineren van de genoemde bestanden in een enkel bestand om op te nemen.
Hiermee is de CSS-verkleiningsvereiste van PageSpeed opgelost.
Het verminderde ook het aantal CSS-bestanden dat wordt gerapporteerd voor render-blokkering van zeven tot vier themagerelateerde bestanden (die als eerste onder Optimize CSS Delivery worden vermeld):
De drie resterende bestanden waren afkomstig van plug-in mappen buiten mijn thema (die we later zullen bekijken):
Ik hoop dat dit je een idee geeft van het gat van het konijn dat WordPress PageSpeed-optimalisatie snel wordt.
Het verkleinen en samenvoegen van CSS is over het algemeen vrij eenvoudig, maar JavaScript heeft vaak de neiging om te falen wanneer je dit probeert te doen, waardoor grote, site-breaking bugs ontstaan.
Interessant is dat PageSpeed nu volledige gecomprimeerde downloads van de gecomprimeerde versies van uw bestanden aanbiedt, die hij niet leuk vindt.
Het vermeldde tien van mijn JS-bestanden die ik wilde repareren:
Ter referentie vindt u hier meer informatie over de paginabepalingsbronnen van Google PageSpeed voor HTML, CSS en JS. Ik maakte ook gebruik van Refresh SF, dat eenvoudige webtoegang biedt tot verschillende compressietools.
Het comprimeren en combineren van JavaScript kan zeker fouten veroorzaken, dus ik moest de dingen stap voor stap doen. Met behulp van het JS-bestandsbeheer van W3TC heb ik de zeven JS-bestanden in het thema Construct geminificeerd en gecombineerd:
Hierdoor kon ik de JS-bestanden van mijn plug-ins of problemen die ik zag niet aan met een mysterieus niet-ontvankelijk extern gehost basisbestand .js. Laten we verder gaan met het blokkeren van problemen en daarna terugkeren naar JS-minificatie.
Als u een grote verscheidenheid aan bestanden hebt die in stijl (CSS) moeten worden geladen en de functionaliteit van uw webpagina moeten activeren (JS), zullen de meeste browsers vertragen nadat vier bronnen tegelijkertijd zijn aangevraagd.
Hier is een voorbeeld van de CSS-blokkering van CSS-weergave in Paginasnelheid:
Hoewel W3TC veel van hen in zijn include.c46b63.css had gecombineerd, waren de volgende drie hierboven afkomstig van mijn plug-ins.
Blogger Justin Tadlock bood enige aanwijzingen voor het vragen hoe WordPress de CSS-bestanden die mijn plug-ins hadden uitgezet voor het laden, niet kon laden. Het antwoord is om ze te de-registreren en vervolgens een gecombineerd bestand in je eentje te laden.
Hier is mijn plug-in met de inhoudsopgave die zijn JS- en CSS-bestanden in de wacht sleept:
Accentsconagua
/ ** * Registreer en laad CSS- en javascript-bestanden voor frontend. * / function wp_enqueue_scripts () $ js_vars = array (); // registreer onze CSS en scripts 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); // wacht hen op! if (! $ this-> options ['exclude_css']) wp_enqueue_style ("toc-screen"); if ($ this-> options ['smooth_scroll']) $ js_vars ['smooth_scroll'] = true; wp_enqueue_script ('toc-front');Naar aanleiding van de suggestie van Tadlock heb ik mijn registratie afgemeld, inclusief in de functies van mijn thema.php, eerst de CSS-je moet de referenties vinden die door de ontwikkelaar van plug-ins worden gebruikt:
add_action ('wp_print_styles', 'my_deregister_styles', 100); function my_deregister_styles () wp_deregister_style ('toc-screen'); wp_deregister_style ('blogsynthesis_jss_css'); wp_deregister_style ('edd-styles'); Ik heb handmatig een gecombineerde CSS-bestanden gemaakt met die drie plugin-stylesheets. Vervolgens vroeg ik W3TC om dat bestand te verkleinen en te combineren in zijn eigen mega-stylesheet:
Er is hier een groot probleem omdat ik bij het bijwerken van mijn plug-ins dit gecombineerde CSS-bestand en de bijbehorende JS-bestanden moet bijwerken.
Hier is een blogpost met enkele andere benaderingen die u kunt gebruiken voor deze uitdagingen.
Gebruikmakend van de aanpak van Tadlock, hier is hoe de blokkering van PageSpeed-weergave achteraf eruit zag:
Ik volgde dezelfde stappen voor JS-bestanden, alleen een beetje zorgvuldiger. Gaandeweg werd de JS-klacht van mijn paginaSpeed voor mijn site vrij onbeduidend:
Zoals u hieronder kunt zien, klaagde het echter ook over problemen met browsercaching met JS-bestanden die ik niet kon vinden in mijn codebase, zoals ad_status.js van Doubleclick.
Een verouderde YouTube-speler verwijderen
Uiteindelijk kwam ik erachter dat zowel het probleem van de JS-minificatie als dit cacheprobleem verband hielden met mijn gebruik van een externe YouTube-videospeler.
Hoewel ik benieuwd was naar een kleine oplossing die hier wordt voorgesteld om te voorkomen dat video wordt geladen zonder actie van de gebruiker, besloot ik de video gewoon van de diavoorstelling op de homepage te verwijderen..
Het is waarschijnlijk dat de manier waarop mijn in Construct-thema ingesloten YouTube-bestanden een verouderde oplossing was. De HTML5-ondersteuning van YouTube werkt mogelijk nu veel beter. Toch is het nogal grappig hoe een Google-service invloed heeft op prestatiescores van een andere Google-service.
Het verwijderen van de enige functie op mijn startpagina met een YouTube-video loste een paar problemen op:
Omdat ik niet wil dat je mijn betere helft mist voordat ik werd beschadigd door WordPress, zal ik de video hier opnemen. Ik was een aardige vent.
Dit is wat er gebeurde:
Nadat de eerdere JS-wijzigingen zijn aangebracht en de video is verwijderd, is het JavaScript-minificatieprobleem voor mijn PageSpeed-master opgelost:
De browsercachefout met DoubleClick hieronder is ook verdwenen.
Nu moest ik alleen nog gpt.js en ga.js cachen, nog twee extern gehoste Google-services:
Dit bleek een vrij groot obstakel te zijn en vereiste veel complexiteit om deze problemen volledig op te lossen. De beste oplossing is om lokaal een kopie van Google-scripts voor Analytics en DFP te hosten en cron-scripts te gebruiken om ze regelmatig op uw server bij te werken. Alice begon zich met me te vervelen - ik hoop dat je nog steeds meegaat.
Ik heb gekeken naar andere thema's die ik gebruik met de Google Analytics-plug-in (Construct heeft instellingen voor Analytics) en zij hebben dit ook niet aangepakt.
Dus maakte ik lokale kopieën van de scripts voor Google Analytics en Google DFP, en kort daarna werd mijn browsercaching in Paginasnelheid opgelost:
Hier is meer informatie van Google over Browser Caching, opnieuw een zeer diep technische bron zonder veel begeleiding voor WordPress-beheerders.
Google kan algemene groepen van zijn populaire JavaScript-bestanden verkleinen en combineren om Pagelsnelheid van uitgevers beter te ondersteunen. Het zou ook helpen als ze hun bestanden niet individueel en obscuur in scripts laden.
Laten we kort teruggaan naar de paginagrootte klachten van PageSpeed voordat het wordt ingepakt.
De afbeeldingsuggesties van Google PageSpeed kunnen de bruikbaarheid van uw site zelfs verzwakken. Hier is een voorbeeld, een uitgelichte afbeelding die ik op mijn startpagina heb gehost.
Om mijn berichten op Facebook te plaatsen met een miniatuurafbeelding, heeft het sociale netwerk minimale dimensies van 200 pixels nodig aan de kortste zijde. Mijn versie is 281 x 200 (hier weergegeven enigszins aangepast voor Tuts + vereisten):
En hier is de versie die wordt geleverd door PageSpeed in de gecomprimeerde download:
Je kunt zien dat de kwaliteit nog erger is, maar belangrijker is dat PageSpeed wil dat ik de afbeelding verkleind tot een dimensie die Facebook niet zou accepteren om te laten zien in zijn berichten.
Uiteindelijk heb ik ervoor gekozen om mijn site te verlaten met een handvol PageSpeed-optimalisatieklachten, waardoor mijn scores lager werden.
Na al dit werk, waar kwam mijn site terecht?
De uiteindelijke scores van PageSpeed omvatten Mobile 70, met enkele van de resterende klachten hieronder:
Hier blijven de optimalisaties van afbeeldingen:
En hier is een samenvatting van alle doorgegeven regels:
Ook hier zijn de uiteindelijke UX-scores. De meeste sites hebben hier geen grote problemen mee, dus heb ik ze vandaag niet aangepakt:
De uiteindelijke Desktop-score was 86, niet slecht:
JavaScript is kieskeurig. Ik kon die laatste twee bestanden nooit met succes verkleinen en combineren in de eerste. Zelfs als ze ongecomprimeerd werden achtergelaten, werkte het nooit. Werken met thema's en plug-ins is moeilijk. Het zou een aantal dagen toegewijd werk gekost hebben om dit op te lossen.
Hier zijn de klachten over de bestandsgrootte van afbeeldingen:
Uiteindelijk kostte het optimaliseren van mijn PageSpeed veel tijd en moeite en liet ik mijn site kwetsbaar voor toekomstige plugin- en Google-scriptupdates. Veel van dit werk is behoorlijk confronterend, gedetailleerd en tijdrovend. Het is ook een beetje gekmakend en geestdodend. Bedankt Google.
PageSpeed is niet alles. Inhoud is ook belangrijk. Hier zijn een paar bekende sites en hun PageSpeed. De resultaten zullen je verrassen.
Daring Fireball (DF) is een van de snelst op inhoud gerichte blogs. Het promoot adverteerders op een minimale manier. De pagina's worden licht en snel weergegeven. Gruber's CMS is een aangepaste versie van Movable Type. De scores zijn net iets beter dan mijn site. DF genereert ook een hoop inkomsten met minimale reclame.
Uiteraard een belangrijke nieuwsorganisatie, ze hebben verschrikkelijke PageSpeed scores:
Verbazingwekkend genoeg is onze lokale vod met zijn vreselijke advertentie en abonnement-bounce-model veel erger:
Een populaire e-commercesite, B & H Photo, heeft een vreselijke mobiele score en een desktopscore net onder de mijne:
Je hebt misschien gehoord van dit bedrijf in mijn recente essay How to Make WordPress Sites Different by Geography-ze verkopen veel online. Mijn PageSpeed-scores zijn aanzienlijk hoger dan die van hen:
In de toekomst zal ik kijken naar een paar extra verbeteringen om de paginasnelheid van mijn site te verbeteren:
Als ik thema's niet snel migreer, moet ik dat cron-script implementeren om mijn door Google gehoste zelf-gehoste Google-scripts voor Analytics en DFP te synchroniseren en uitzoeken hoe ik plug-insupdates voor JS- en CSS-wijzigingen kan monitoren. Misschien moet ik deze specifieke PageSpeed-voordelen op eerlijke wijze terugdraaien.
Als u vragen hebt, kunt u ze hieronder plaatsen. Of u kunt contact met mij opnemen op Twitter @reifman. Bekijk mijn Envato Tuts + instructor-pagina voor andere tutorials die ik heb geschreven, zoals mijn opstartreeks (Building Your Startup With PHP).
