- WP Rocket (paid)<\/a> + an image optimization plugin<\/a>, or:<\/li>
- Autoptimize<\/a> + a cache plugin<\/a><\/li><\/ul>\n\n\n\n
Drupal<\/strong><\/p>\n\n\n\n
- AdvAgg<\/a> + an image optimization module<\/a><\/li><\/ul>\n\n\n\n
Now, back to business. Here\u2019s everything I\u2019m going to cover:<\/p>\n\n\n\n
- What is Page Speed?<\/a><\/li>
- Why You Should Care About Page Speed<\/a><\/li>
- How Fast Should My Page Load?<\/a><\/li>
- How A Page Is Built<\/a><\/li>
- Page Speed Testing And Tools<\/a><\/li>
- Estimating Impact of Changes<\/a><\/li><\/ul>\n\n\n\n
<\/a><\/p>\n\n\n\n
What is Page Speed?<\/h2>\n\n\n\n
Page speed is the amount of time it takes for a web page to load. It is difficult to assign a single number to page speed because many metrics capture elements of the page load in different ways, for different purposes, and with different test conditions.<\/a><\/p>\n\n\n\n
Why You Should Care About Page Speed<\/h2>\n\n\n\n
There\u2019s been a renewed focus on page speed from Google recently with mobile speed becoming a ranking factor<\/a>, a Speed Report<\/a> in Google Search Console, and Chrome announcing they may flag sites that are slow<\/a>, but did you know that page speed has been a ranking factor for Google since 2010<\/a>?<\/p>\n\n\n\n
Here are the reasons you should care:<\/p>\n\n\n\n
- Impacts User Experience<\/strong>. You want visitors to have a fast and smooth experience. Any delay or lag on their actions is noticeable.<\/li>
- Impacts Analytics<\/strong>. Generally speaking, a faster site will record more visitors because the analytics tag will load sooner. If a person leaves before the tag is fired, they won\u2019t be recorded in the analytics system.<\/li>
- SEO<\/strong>? The Speed Update only impacts the slowest sites according to the official announcement<\/a>.<\/li><\/ul>\n\n\n\n
There are lots of studies showing that if you increase page speed, you\u2019ll see increases in things like organic traffic, click to visit ratio on ads, more visitors in general, and many other benefits. WPO Stats<\/a> has many example studies on page speed improvements.<\/p>\n\n\n\n
However, I will caution that many of these studies may be a bit misleading. Unless you were extremely slow before, Google says that improving page speed should not impact your rankings.<\/p>\n\n\n\n
So why might you see more visitors?<\/p>\n\n\n\n
The answer is that the analytics tag probably fired sooner than before, and was able to record more people before they leave a page.<\/a><\/p>\n\n\n\n
How Fast Should My Page Load?<\/h2>\n\n\n\n
There\u2019s no official threshold<\/a>. One of the common recommendations is that your site should load in less than three seconds. That likely comes from a Google study<\/a> saying that 53% of mobile visitors leave a page that takes longer than three seconds to load.<\/p>\n\n\n\n
This recommendation is also most likely based on the Speed Index metric, which we\u2019ll talk about later, but that\u2019s just my speculation based on what was a popular measure at the time of the study. I don\u2019t believe that Google has ever mentioned a particular metric when giving a number for page speed. Usually, the recommendations from Google representatives are generic like \u201cmake sites fast for users\u201d or \u201cmake sites as fast as possible.\u201d<\/a><\/p>\n\n\n\n
How A Page Is Built<\/h2>\n\n\n\n
To understand how to improve your page speed, you need to know how a browser constructs a page. For this, we\u2019re mainly going to be looking at Waterfall charts to see what resources are loading. You can also see this in your browser by using \u201cright-click\u201d > Inspect > and bringing up the Network tab when loading a page.SIDENOTE. I\u2019m going to be using https:\/\/www.webpagetest.org\/<\/a> for a lot of the images, and I\u2019ll link to the tests and list the settings where applicable.<\/p>\n\n\n\n
Establishing Connections<\/h3>\n\n\n\n
The green, orange, and purple below represent the time it takes to establish a connection to the website. I\u2019ll go over each color below and what it represents.
![\"1](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/1-establishing-connections-3.png\")
<\/p>\n\n\n\nWaterfall chart for the TwentyTwenty WordPress theme page from WebPageTest.org (view it here<\/a>). Location: Dulles, VA. Device: Moto G4. Browser: Chrome. Speed: 3GSlow.<\/p>\n\n\n\n
DNS (Green)<\/h4>\n\n\n\n
Domain Name System (DNS) is considered the phone book of the web. You give your browser a website name, and it checks with a DNS server to get an IP address (a location label) telling it where the website is hosted. It\u2019s just like storing a contact on your phone so you only have to know the name and not the phone number.<\/p>\n\n\n\n
Most of the time, your DNS is going to be with your domain registrar (where you bought the domain) or with your Content Delivery Network (CDN).<\/p>\n\n\n\n
Importantly, not all DNS providers are created equal. If every millisecond matters to you, you might want to consider using a different DNS provider. According to DNSPerf<\/a>, Cloudflare has an average query speed of 12.6 ms, whereas others like GoDaddy (46.04 ms) and Rackspace (90.38 ms) are slower on average. However, these numbers are not a completely accurate representation as the DNS can be cached (stored temporarily) in the browser when you\u2019ve already visited a website. The amount of time it\u2019s cached is referred to as the TTL (Time to Live). While the cache is still active, the browser won\u2019t have to connect to the DNS server to know where to go to access the website.<\/p>\n\n\n\n
Connect (Orange)<\/h4>\n\n\n\n
This is where the browser is establishing a connection with the hosting server. Transmission Control Protocol \/ Internet Protocol (TCP\/IP) is complicated, but just think about how you get to work. It\u2019s likely not a straight line; you have to make turns, and there will be areas with higher traffic. You may even re-route or make some wrong turns. That\u2019s sort of how this works; it\u2019s routing from your browser to the server and back.<\/p>\n\n\n\n
If the time to connect is long, it could be one of many issues. On unstable connections, packet loss might occur and will have to be re-sent. This is akin to missing your turn on a roundabout and having to go around again. The problem could also be with the routing of the request through the network. How many hops it has to take, how far it has to go, how much other traffic is on the network are similar to how many turns you need to take, how far from work you are, and how many other cars are on the road that might slow you down. There\u2019s also rate-limiting and connection capacity on the server, which would be similar to a tunnel that only allows so many cars though it at a time.<\/p>\n\n\n\n
A lot of these issues are solved by making the distance to the server shorter and using more intelligent routing\u2014which many CDNs can do. With a network of servers around the world, visitors can usually connect to a close one. Some CDN providers also manage large amounts of internet requests and can see in real-time where there may be bottlenecks (traffic). If they see a faster option, they can reroute the traffic\u2014just like how a GPS would reroute you around a traffic jam.<\/p>\n\n\n\n
Secure Sockets Layer (SSL) (Purple)<\/h4>\n\n\n\n
For sites establishing a secure connection (HTTPS<\/a>), this is where the browser and server are agreeing on the TLS (Transport Layer Security) protocol version, the ciphersuite (level of security), and verifying the certificate (to make sure the site is the one it says it is).<\/p>\n\n\n\n
You might be thinking that you can make your website faster by just not using HTTPS. That\u2019s partially true\u2014at least for the connection part. But there are other benefits to being on HTTPS like the fact that browsers don\u2019t let you use HTTP\/2 (H2) without HTTPS. H2 has some advantages like persistent connections, so it doesn\u2019t have to keep opening a new connection for files on the same server. The headers within those requests are also smaller than in HTTP\/1.1, and multiple files can be transferred simultaneously. In most cases, sites using HTTPS and H2 will be faster than sites on HTTP.<\/p>\n\n\n\n
Generally, the most significant gains you\u2019ll get here come from upgrading your protocol (TLS 1.3 is faster than TLS 1.2, for instance) and implementing HTTP Strict Transport Security (HSTS), which tells the browser always to use a secure connection. The browser changes the requests from HTTP to HTTPS without having to contact the server and do a redirect. In the image below, the redirect from HTTP to HTTPS and the time that took would be eliminated by using HSTS.<\/p>\n\n\n\n
![\"2](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/2-secure-sockets-layer-3.png\")
<\/figure>\n\n\n\nYou may even want to look into using HTTP\/3<\/a> for even faster connections. However, support for this protocol is still in the early stages, and\u2014at least at the time of writing\u2014is probably not yet a viable option.IMPORTANT: DEVICE, LOCATION, AND NETWORK MATTER<\/p>\n\n\n\n
Consider this, connecting to a website on a mid-grade smartphone with a slow 3G connection takes ~2 seconds. On the same phone with an LTE connection, it\u2019s cut down to ~0.41 seconds. On a desktop computer with normal speeds, it\u2019s less than 0.1 seconds to make that connection.<\/p>\n\n\n\n
Keep that in mind if you see longer connection times as it may be due to limited bandwidth or processing power of the test device. These factors\u2014along with caching\u2014are important. They can help you explain to someone who might pull out their latest smartphone, connected to WiFi, with all the files needed to load the page already cached on their device (we\u2019ll talk about this in another section) that the way they are experiencing the site is under ideal conditions and not how most people will experience it.<\/p>\n\n\n\n
Downloading And Processing HTML<\/h3>\n\n\n\n
The HTML code of a page is what is initially downloaded by a browser. This is the information you see when you right-click on a website and go to \u201cView Page Source.\u201d Once a connection has been established, and the browser gets the first bit of information back from the server, we reach the Time To First Byte (TTFB), which is the typical measure for the initial response time. As represented by the orange lines below, this is the time from the start of the HTML request (light blue) to the time when the HTML starts to download (dark blue).<\/p>\n\n\n\n
![\"3](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/3-downloading-html-3.png\")
<\/figure>\n\n\n\nIf there\u2019s a delay for TTFB, it could be due to database queries, server resources, waiting for a Server Side Render (SSR) to complete, or other things typically involved with creating dynamic content. The download time will depend on things like the connection and file size.<\/p>\n\n\n\n
This is also where the browser also starts to construct a page. When the HTML is downloaded, the browser parses it into the Document Object Model (DOM), which is how a computer understands the structure of the content. That parsing process uses the browser\u2019s main thread to process user actions and paint the page, run JavaScript, and perform layouting, reflows, and garbage collection. For now, just know that this main thread exists and handles a lot of different tasks. We\u2019ll cover this a bit more later.<\/p>\n\n\n\n
If you see a gap between HTML and the next request, the most likely cause is that the CPU is busy processing the HTML to build the DOM. Since it\u2019s the CPU, this is again dependent on the device being used, so you can test with a more powerful device to see if that gap still exists.<\/p>\n\n\n\n
For the HTML and other file types like CSS and JavaScript, you can cut the time down by using less code, minification to remove unnecessary characters like comments and white space from the code, and compression to reduce the size of the files. The point is to make the file download smaller so this part of the load would be faster. However, there isn\u2019t only one way to do minification and compression. In many instances, this is handled by the CDN or the server (Apache or Nginx are common servers), or by a plugin\/module\/package. You can find more information on implementing compression here<\/a> and minification here<\/a>.<\/p>\n\n\n\n
Handling Additional Connections<\/h3>\n\n\n\n
When the HTML has been downloaded, references to other files and other servers will be processed, and new connections will start. This is typically where other files like JavaScript, CSS, Images, and Fonts are added to the mix. Things can get crazy here as some files reference other files, and we start chaining connections and file downloads. Take a look at the Request Map below for Forbes.com. Each point is an individual file request, and each line is where one file is referencing another file that has to be downloaded. Overall it\u2019s 363 requests across 128 connections.
![\"requestmap](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/requestmap_https___www.forbes.com_-3.png\")
<\/p>\n\n\n\nSource: RequestMap<\/a><\/p>\n\n\n\n
Use the Same Server for Requests When Possible<\/h4>\n\n\n\n
It used to be a best practice to host resources on cookieless domains that were not the same as the main domain, and sometimes there\u2019d be a benefit to using multiple domains (a process called domain sharding) because of connection request limits set by the browser.<\/p>\n\n\n\n
Since HTTP\/2, that has not been a best practice. You should use the same server for requests, if possible.<\/p>\n\n\n\n
For example, take cdn.ahrefs.com<\/em> in the waterfall chart below.<\/p>\n\n\n\n
![\"4](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/4-same-server-3.png\")
<\/figure>\n\n\n\nIf that file were hosted on ahrefs.com, then it wouldn\u2019t even have to make the connection. It\u2019s being delayed by the time to make the DNS connection, to connect, and to negotiate the security handshake. Without the extra hoops to jump through, we would have the file earlier, which means the page would load even faster.<\/p>\n\n\n\n
However, while self-hosting many files like fonts can lead to gains, there may be other trade-offs like caching (storing a copy of a file) where browsers may sometimes have common resources cached. For example, if I visited one website that called a font from Google Fonts and then went to another website using the same font, I might have that file cached locally already and not have to download it again.<\/p>\n\n\n\n
Use Preconnect or DNS-Prefetch (If You Use Another Server)<\/h4>\n\n\n\n
If you\u2019re going to use a different server, Preconnect to servers that contain files needed early in the page load. This is going to make the connection to another server earlier than it would ordinarily happen. See below how one of the connections for Amazon starts before the HTML is even finished processing.
![\"5](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/5-preconnect-dns-prefetch-3.png\")
<\/p>\n\n\n\nCode example:<\/strong>
<link rel=\"preconnect\" href=\"https:\/\/site.com\"><\/code><\/p>\n\n\n\nThere\u2019s also DNS-prefetch if you just want to handle that part of the connection early. The green (DNS) part would connect early, but the rest of the connection will happen later. DNS-prefetch has better support<\/a> than preconnect<\/a>, but if you look at current usage statistics, the difference would be negligible. Preconnect is generally better if you know something from that server needs to be loaded early for the page to function. However, because preconnect requires more work for routing and security (the orange and purple), it\u2019s also going to be a bit more resource-intensive early on.<\/p>\n\n\n\n
Code example:<\/strong>
<link rel=\"dns-prefetch\" href=\"\/\/asset1.com\"><\/code><\/p>\n\n\n\nHow Browsers Render A Page<\/h3>\n\n\n\n
Before we continue and discuss options for optimization, I think it\u2019s best to understand a bit about how a browser renders a page. We have other files coming in now like CSS, JavaScript, Images, and Fonts, and the browser has to turn them, along with the HTML, into something useful. This is a dynamic process with new files being introduced, downloaded, parsed, and things being rearranged constantly to build the page. This process is commonly called the Critical Rendering Path and it looks like this:<\/p>\n\n\n\n
- HTML is processed into the DOM tree we mentioned earlier<\/li>
- CSS is parsed into the CSS Object Model (CSSOM), which tells the browser how everything is styled, padded, colored, sized, etc.<\/li>
- The CSSOM + DOM together make what is called the Render Tree<\/a>.
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-61.png\")
<\/li>- Layouting happens, which is processing where each element will be within the browser viewport based on what\u2019s in the Render Tree.
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-58.png\")
<\/li>- Pixels get painted on the screen so instead of a white screen, you see colors, shapes, text, and images.<\/li><\/ol>\n\n\n\n
SIDENOTE. A fun fact revealed by Martin Splitt<\/a> of Google is that Googlebot saves time and resources by not actually painting the pixels of a page. They have the information they need after layouting.<\/p>\n\n\n\n
The goal should be to get the required elements as early as possible to build the initial view as fast as we can. The visible load time is people\u2019s perceived view of a page\u2019s speed, i.e., how soon the content appears on the screen for them. What impacts this the most is how resources are loaded. It\u2019s usually the responsibility of the CMS or JavaScript Framework to help the browser prioritize when\/what\/how resources to load in what order to make the site appear faster. More on that in a bit.<\/p>\n\n\n\n
You also want to keep things simple and avoid complex calculations and lots of changes during the layout phase. Google has a more developer-focused guide for that here<\/a>, and another on simplifying the painting process<\/a>.<\/p>\n\n\n\n
Visual Load Metrics:<\/h4>\n\n\n\n
- First Paint (FP)<\/strong> \u2014 browser renders anything for the first time.<\/li>
- First Contentful Paint (FCP) <\/strong>– browser renders something from the DOM (Document Object Model), which could be text, an image, etc.<\/li>
- First Meaningful Paint (FMP)<\/strong> \u2014 most important elements visually loaded.<\/li>
- Largest Contentful Paint (LCP)<\/strong> \u2014 largest element above the fold loaded.<\/li>
- Visually Complete<\/strong> \u2014 page is visually loaded.<\/li>
- Speed Index <\/strong>– a calculated score for the visual load that takes into account multiple points in time.<\/li>
- Cumulative Layout Shift (CLS)<\/strong> \u2014 Measures how much elements move around in the viewport during the load, or how stable the layout is. There\u2019s a nice guide to the causes of CLS here<\/a>.<\/li><\/ul>\n\n\n\n
\nhttps:\/\/platform.twitter.com\/embed\/index.html?creatorScreenName=patrickstox&dnt=false&embedId=twitter-widget-0&frame=false&hideCard=false&hideThread=false&id=1223191694788702208&lang=en&origin=https%3A%2F%2Fahrefs.com%2Fblog%2Fadvanced-pagespeed-guide%2F&siteScreenName=ahrefs&theme=light&widgetsVersion=219d021%3A1598982042171&width=550px\n<\/div><\/figure>\n\n\n\nSeeing The Visual Load Along With The Waterfall Chart<\/h4>\n\n\n\n
On the Summary section in WebPageTest<\/a>, if you enabled recording then you should have a Video column in the main table with \u201cFilmstrip View.\u201d In this view, the red line at the top with the visual snapshots is at the same point as the red line at the bottom in the waterfall.<\/p>\n\n\n\n
![\"6](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/6-visual-load-waterfall-3.png\")
<\/figure>\n\n\n\nBy moving the red line around to different points in the visual load, you should be able to look at what was just loaded in the waterfall that may have allowed different elements to display visually. This can help you determine what files you may need to prioritize.<\/p>\n\n\n\n
For example, if you see that most of your page is loaded except the text, but right after that a font is loaded and the text appears, then that\u2019s a good indication that font was required to show the text. You\u2019ll also be able to tell what images may be needed earlier with different viewports by simply looking at the generated screenshots.<\/p>\n\n\n\n
At the bottom of this chart is additional information such as CPU Utilization, Bandwidth, activity on the Browser Main Thread, and Interactivity. All of these charts again depend on the device and connection type. The information can be used to help troubleshoot different issues. For example, maybe there\u2019s simply too much being downloaded, which keeps the Bandwidth at the highest point. Or maybe there\u2019s a script using all of the CPU for a certain device, which can cause delays.<\/p>\n\n\n\n
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-65.png\")
<\/figure>\n\n\n\nFiletype CSS<\/h3>\n\n\n\n
Where page speed gets complicated is that in many cases, there\u2019s no one right way to do things. Most methods have tradeoffs, and some are more complex to implement and maintain. You have to decide what\u2019s easiest, fastest, and best for you in your circumstances.<\/p>\n\n\n\n
Looking at CSS files, they\u2019re render-blocking by default, meaning that they need to be downloaded and processed before a page displays content to the user. If you cache (store a copy of the file, covered later in the article), then that file can be re-used for subsequent page loads. That means it won\u2019t have to be downloaded again, and the next views should be faster.<\/p>\n\n\n\n
Most of the speed tools test with the first view, so a lot of what you see in a tool like PageSpeed Insights<\/a> is representative of a first time user who only views one page and not someone who visits multiple pages or comes back to your website often. Your goal should be to both optimize that first view and subsequent views for users.<\/p>\n\n\n\n
Loading CSS Asynchronously<\/h4>\n\n\n\n
You want to load important code as soon as possible, and we\u2019ll talk about a few options for that in a second, but the other part of this is you want the CSS not to block the render. To do this, we want to load the stylesheets needed later in the loading process as a different media type, which then gets applied to all types. It\u2019s tricking the browser by abusing how they handle the loading of specific link element attributes. What it\u2019s going to do is load the CSS without blocking rendering (because in this case, we\u2019re telling the browser this stylesheet is for print and not really for this version of the page), and then apply to all media types (things that aren\u2019t print) after it\u2019s loaded.<\/p>\n\n\n\n
For example, this:<\/p>\n\n\n\n
<link rel=\"stylesheet\" href=\"\/my.css\"><\/code><\/p>\n\n\n\nBecomes this:<\/p>\n\n\n\n
<link rel=\"stylesheet\" href=\"\/my.css\" media=\"print\" onload=\"this.media='all'\"><\/code><\/p>\n\n\n\nYou can use this with all your CSS references. The tradeoff is that users may experience some flashing\/re-styling as some page elements may be painted before the CSS is applied. So when the CSS is applied, the screen may change where and how things are displayed.<\/p>\n\n\n\n
Inline<\/h4>\n\n\n\n
Inline takes code needed to render content above the fold and delivers it with the HTML response instead of a separate file. This is typically going to be the fastest way to shorten the time it takes to render the initial view.<\/p>\n\n\n\n
The easiest way to think about this is you\u2019re taking critical parts of the CSS and JS files and putting it directly into the HTML. The initial HTML takes a little longer to download and parse, but the render of the page can now happen before all the other files are even downloaded.<\/p>\n\n\n\n
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-59.png\")
<\/figure>\n\n\n\nInlining is probably going to get you the fastest render on the initial page load, but the tradeoff has traditionally been with caching. The code loaded in the HTML couldn\u2019t be re-used from the cache, so you would typically be loading some of the code twice: once with the HTML and again in the normal file that was typically cached. But if you inlined code for every page, that also meant subsequent pages would have extra code as well. This is advanced and involves the use of service workers<\/a>, but you can have both inlining and caching<\/a>. Combined with making the rest of the CSS asynchronous as we mentioned above, this is pretty much an ideal state.<\/p>\n\n\n\n
Remember that you can minify inline CSS code. As mentioned in the HTML section above, this removes some of the unnecessary spacing and extra characters to make the code smaller and faster to download.<\/p>\n\n\n\n
You probably don\u2019t want to inline all content from all the files. Be considerate and inline critical content only. You can technically inline all CSS and JS and even fonts and images, but you\u2019re going to end up with a giant HTML download where a lot of the code isn\u2019t used. That actually makes your website slower. If you have some smaller files of just a few KB and want to inline the whole thing for those, it\u2019s probably fine to do so.<\/p>\n\n\n\n
Inline Critical CSS at scale:<\/h5>\n\n\n\n
You\u2019re going to want an automated system rather than doing this for every page. It might make sense to inline just the CSS for the homepage on WordPress themes since that typically has a different stylesheet than other pages. There\u2019s usually going to be some plugin\/module\/package or a version of Critical or Critical CSS. These packages exist for any taskrunner or packaging you may be using like Grunt, Gulp, Webpack, or Framework like React, Angular, Vue, and you can even find tutorials specific to WordPress or Drupal or even hand-coded pages. They\u2019re going to send a headless browser to the page to determine what CSS is actually critical for the page load at different sizes, and either give you the code or split the code into critical and non-critical elements so you can load them appropriately. A few examples:<\/p>\n\n\n\n
Grunt:<\/strong>
https:\/\/github.com\/filamentgroup\/grunt-criticalcss<\/a>
https:\/\/www.npmjs.com\/package\/grunt-critical-css<\/a>
https:\/\/github.com\/bezoerb\/grunt-critical<\/a><\/p>\n\n\n\nGulp:<\/strong>
https:\/\/github.com\/addyosmani\/critical<\/a>
https:\/\/www.npmjs.com\/package\/gulp-critical-css<\/a><\/p>\n\n\n\nWebpack:<\/strong>
https:\/\/github.com\/anthonygore\/html-critical-webpack-plugin<\/a>
https:\/\/github.com\/GoogleChromeLabs\/critters<\/a>
https:\/\/github.com\/anthonygore\/html-critical-webpack-plugin<\/a>
https:\/\/www.npmjs.com\/package\/critical-css-webpack-plugin<\/a><\/p>\n\n\n\nReact:<\/strong>
https:\/\/www.npmjs.com\/package\/react-critical-css<\/a>
https:\/\/github.com\/addyosmani\/critical-path-css-tools<\/a>
https:\/\/github.com\/sergei-zelinsky\/react-critical-css<\/a> <\/p>\n\n\n\nAngular:<\/strong>
https:\/\/github.com\/addyosmani\/critical-path-angular-demo<\/a> <\/p>\n\n\n\nVue:<\/strong>
https:\/\/github.com\/anthonygore\/vue-cli-plugin-critical<\/a>
https:\/\/vuejsdevelopers.com\/2017\/07\/24\/critical-css-webpack\/<\/a> <\/p>\n\n\n\nDrupal:<\/strong>
https:\/\/www.fourkitchens.com\/blog\/article\/use-gulp-automate-your-critical-path-css\/<\/a> <\/p>\n\n\n\nWordPress:<\/strong>
https:\/\/joe-watkins.io\/javascript\/inline-critical-css-with-wordpress\/<\/a>
https:\/\/wordpress.org\/plugins\/wp-criticalcss\/<\/a><\/p>\n\n\n\nHand-coded:<\/strong>
https:\/\/www.sitelocity.com\/critical-path-css-generator<\/a>
https:\/\/jonassebastianohlsson.com\/criticalpathcssgenerator\/<\/a> <\/p>\n\n\n\nPreload<\/h4>\n\n\n\n
If you\u2019re not going to inline the critical CSS, the next best option is arguably using Preload. Preload fetches requests earlier in the load, getting essential resources needed to display the page faster than usual. Preload sets the browser priority for preloaded assets as high and loads them asynchronously, so they don\u2019t block rendering. It also works across domains.<\/p>\n\n\n\n
The browser gives each request for a file a priority. The idea is to get files needed to display above the fold content earlier (at a higher priority) and defer those not required until later in the process. You can see the priority given to files in the Network tab in Chrome Dev Tools. Just right-click on the bar, select Priority, and add it as a column.<\/p>\n\n\n\n
![\"7](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/7-preload-priority-3.png\")
<\/figure>\n\n\n\nWhat it\u2019ll do is take a file that may have started downloading later, and download it as soon as possible. Again, the other benefit is that where the preloaded file would have been render-blocking before, that will no longer be the case.https:\/\/platform.twitter.com\/embed\/index.html?creatorScreenName=patrickstox&dnt=false&embedId=twitter-widget-1&frame=false&hideCard=false&hideThread=false&id=846491532177768448&lang=en&origin=https%3A%2F%2Fahrefs.com%2Fblog%2Fadvanced-pagespeed-guide%2F&siteScreenName=ahrefs&theme=light&widgetsVersion=219d021%3A1598982042171&width=550px<\/p>\n\n\n\n
Combined with what we mentioned above for making CSS async, preload just adds another line that is meant to get the file faster by setting the browser priority higher than normal. This will also work for browsers where preload is not supported<\/a>.<\/p>\n\n\n\n
Code examples:<\/strong><\/p>\n\n\n\n
<link rel=\"preload\" href=\"\/my.css\" as=\"style\"><\/code><link rel=\"stylesheet\" href=\"\/my.css\" media=\"print\" onload=\"this.media='all'\"><\/code><\/p>\n\n\n\nChoosing Which Files To Preload<\/h5>\n\n\n\n
Usually, you\u2019re going to have the main theme file that contains a lot of the CSS for the website. Devs will often name this after the theme, or call it \u201cstyle,\u201d or sometimes name it after the website itself. If you have trouble identifying this file or believe that other files may need to be preloaded as well, then the easiest way to check is by using the request blocking feature within Chrome Dev Tools. Open the Network tab and load a page to see the files requested. You can right-click on these to add them to the block list. When you reload a page, if the page still looks normal, then you probably didn\u2019t block a file needed for the above the fold content. When you get one of these that breaks how the page looks, that\u2019s an indication it\u2019s needed to render the content above the fold and is a file you want to preload.
![\"8](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/8-block-request-url-3.png\")
<\/p>\n\n\n\nThings To Know About Preload<\/h5>\n\n\n\n
- You need crossorigin on fonts or you\u2019ll get a double load of the file.<\/li>
- You still need the normal file calls for JS + CSS, so don\u2019t delete those.<\/li>
- You can preload a font even if it\u2019s called in another file like a CSS file.<\/li>
- Be careful how much you preload. You can run into issues trying to preload too many files.<\/li><\/ol>\n\n\n\n
Server Push<\/h4>\n\n\n\n
This was part of the HTTP\/2 (H2) specification. It allows a server to deliver a file without it being requested. So instead of a chain that might be HTML > CSS > Font, this allows a site to say I\u2019m going to need that font, just send it.<\/p>\n\n\n\n
Server Push is problematic, and I typically recommend against it, but if you are a great developer or have access to one, you can give it a shot. It requests files from the server on the same connection as the page request. Server push can load assets twice. There\u2019s a workaround using cookies and checking if you\u2019ve already pushed assets to users, but it\u2019s a complex implementation. There\u2019s another problem involving connection issues that can cause files not to load at all. With all of the extra work, you still may not see significant gains over preload because browsers check the page cache (where preload is) before the push cache.<\/p>\n\n\n\n
Filetype JavaScript<\/h3>\n\n\n\n
JavaScript can also be complex, with a lot of options and a lot of considerations. Sometimes it is used to provide functionality, sometimes it\u2019s used to pull in the main content, and sometimes it\u2019s even used to make changes to the CSS. Furthermore, certain code may need other code to run properly. These are known as dependencies, and changing how JavaScript is loaded may end up breaking some functionality of the page.<\/p>\n\n\n\n
If JavaScript plays a critical role in content or the styling of the page, or if it\u2019s the core system\u2014as is the case with many JavaScript frameworks\u2014then many of the same rules as CSS apply as far as inlining and preloading. However, you also have the option of Server Side Rendering (SSR)<\/a>. This processes the code and renders a snapshot. For instance, if JavaScript is used to populate items on the page or for the menu, you may want this information earlier in the load or reduce some of the burden of the client\u2019s browser, you may want to use an SSR solution.<\/p>\n\n\n\n
The easiest way to see if JavaScript is needed on the page is to click the padlock in Chrome and open up Site settings. You\u2019ll see a list of Permissions with one being JavaScript where you can either Allow it or Block it. Blocking JavaScript, reloading the page, and comparing the site with and without JavaScript should show you if any elements are missing from the page or not. If something is missing, re-enable JavaScript and go through the same blocking process as we went through with CSS above to find out which files are critical to the rendered content.<\/p>\n\n\n\n
Move to Footer<\/h4>\n\n\n\n
For inline scripts, you may consider moving them to the footer. Remember that JavaScript is parser blocking, which means it\u2019s blocking the HTML from being read. Moving these scripts to the footer ensures that much of the data can be processed before any blocking occurs. You have other options for script references that are probably better, such as defer and async.<\/p>\n\n\n\n
Defer\/Async<\/h4>\n\n\n\n
Defer and Async are attributes that can be added to a script tag. Usually, a script being downloaded blocks the parser while downloading and executing. Async will let the parsing and download occur at the same time but still blocks during script execution. Defer does not block parsing during download and only executes after the HTML has finished parsing.
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-60.png\")
<\/p>\n\n\n\nSource: https:\/\/www.growingwiththeweb.com\/2014\/02\/async-vs-defer-attributes.html<\/a>.<\/p>\n\n\n\n
Defer\/Async code samples<\/h5>\n\n\n\n
Normal:<\/strong>
<script src=\"https:\/\/www.domain.com\/file.js\"><\/script><\/code><\/p>\n\n\n\nAsync:<\/strong>
<script src=\"https:\/\/www.domain.com\/file.js\" async><\/script><\/code><\/p>\n\n\n\nDefer:<\/strong>
<script src=\"https:\/\/www.domain.com\/file.js\" defer><\/script><\/code><\/p>\n\n\n\nAddy Osmani has a nice breakdown of blocking, async, defer, and preload and how it impacts browser priorities.https:\/\/platform.twitter.com\/embed\/index.html?creatorScreenName=patrickstox&dnt=false&embedId=twitter-widget-2&frame=false&hideCard=false&hideThread=false&id=1098122582472212481&lang=en&origin=https%3A%2F%2Fahrefs.com%2Fblog%2Fadvanced-pagespeed-guide%2F&siteScreenName=ahrefs&theme=light&widgetsVersion=219d021%3A1598982042171&width=550px<\/p>\n\n\n\n
Responsiveness<\/h4>\n\n\n\n
Responsiveness is typically measured by First Input Delay (FID), which is the time from when a user interacts with your page until it can respond. Max Potential FID is the worst-case FID your users may experience. Many people typically measure Time To Interactive (TTI), which is how long it takes for a page to become fully interactive.<\/p>\n\n\n\n
Remember the things we mentioned earlier were happening on the main thread? Well, there\u2019s just one main thread, and JavaScript competes for those resources. While the thread is blocked, it can\u2019t respond to user input\u2014so the page feels slow. When a user clicks and the page doesn\u2019t do whatever action they requested promptly, they feel that delay. When this happens, your users may let you know and not in a nice way.
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-66.png\")
<\/p>\n\n\n\nUsers complaining about the slowness of Twitter\u2019s app\u2026 on Twitter.<\/p>\n\n\n\n
What impacts responsiveness is JavaScript. All the JavaScript loaded for all the different things it can accomplish has to run in the same place.<\/p>\n\n\n\n
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-64.png\")
<\/figure>\n\n\n\nThe image above is what the main thread looks like. Those red tick marks in the Performance tab in Chrome Dev Tools indicate where there may be some issues. Usually, tasks taking too much time to run on the main thread are the ones flagged. Each of those is where the page is overloaded with work and can\u2019t respond to user input promptly.
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-62.png\")
<\/p>\n\n\n\nSource: https:\/\/web.dev\/long-tasks-devtools<\/a><\/p>\n\n\n\n
While a task is running, a page can\u2019t respond to user input. This is the delay that is felt. The longer the task, the longer the delay experienced by the user. The breaks between tasks are the opportunities that the page has to switch to the user input task and respond to what they wanted.<\/p>\n\n\n\n
Third-party tags<\/h4>\n\n\n\n
This is another report you can find in PageSpeed Insights. It shows the size and how long third-party scripts were blocking the main thread and impacting interactivity.<\/p>\n\n\n\n
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-67.png\")
<\/figure>\n\n\n\nNote that, especially with tag managers, some things may count toward the tag manager and not the script that\u2019s the problem. It might be part of the script in the container counting for a tag manager and not counted properly towards the third-party script.<\/p>\n\n\n\n
Use the size and main thread time to determine what you may be able to get rid of. Remember that most third-party scripts add some kind of functionality, tracking, or targeting, but rarely are they necessary for a page to function properly. Use your discretion to determine if the data gained is worth the extra load time for these scripts.<\/p>\n\n\n\n
Common Sources of JavaScript Bloat:<\/h4>\n\n\n\n
- Jquery<\/li>
- A\/B testing systems<\/li>
- Heatmap systems<\/li>
- Real User Monitoring (RUM) systems<\/li>
- Live chat systems<\/li><\/ul>\n\n\n\n
Cleanup Options:<\/h4>\n\n\n\n
- Use fewer tracking\/scripts.<\/strong> This can be a hard decision as marketers like data, but sometimes the amount of data being collected is just absurd.<\/li>
- Consolidate systems with similar functionality<\/strong>, like if you are running multiple analytics systems or multiple systems that have user information. Many programs have multiple functions, and sometimes you end up with scripts that have the same or similar functionality to another script when maybe you can do without one of them.<\/li>
- Segmentation<\/strong>. For example, some A\/B testing systems will store and force you to load a list of all tests currently in the system, bloating the size of the download. Many times you can segment by section of the site and create smaller versions of the file.<\/li>
- Server-side tracking instead of client-side.<\/strong> There are tradeoffs with tracking this way I won\u2019t cover here, but you can find a lot of resources on why you might use one over the other.<\/li>
- Use web workers to move processing off the main thread.<\/strong> The downside of doing this is the web worker won\u2019t have access to the DOM. This is also fairly advanced and requires skilled developers.<\/li>
- Service Workers \/ Edge Workers.<\/strong> I\u2019m excited for what the future holds with this technology. It\u2019s basically allowing JS to run at the Edge (or CDN level) instead of on the client browser. So before for an A\/B testing system, it might be that a file is downloaded and then processed and executed on the client browser. Because the test might overwrite parts of the DOM and happen later in the load, you might see visual flashes as things change. Now, you could basically pre-process the changes that were going to be made and deliver them inline with the HTML that\u2019s delivered to bots and users. Some platforms are already taking advantage of this<\/a>.<\/li>
- Simply delay the execution of the load of a file<\/strong> if it\u2019s not needed right away or only initiate the file request based on an action like a click. For example, a live chat system probably isn\u2019t needed in the first five seconds of the page load, so delay it. You can also request the file after someone hovers or clicks on a button so it\u2019s not loaded with the initial page at all. Or use an image with a play button instead of embedding a YouTube video and only load in the YouTube video elements and play the content when a user clicks.<\/li><\/ol>\n\n\n\n
Benefits of JS Frameworks:<\/h4>\n\n\n\n
JavaScript Frameworks like React, Angular, and Vue have some benefits over traditional systems.<\/p>\n\n\n\n
- Tree shaking<\/strong>: Delivering only code used on the page. Any additional files or code not needed are not loaded, so it results in smaller files and smaller pages. It eliminates the code traditionally required for every other page and possibility.<\/li>
- Code splitting<\/strong>: Splitting files into smaller chunks, so there are more opportunities for interactivity. For example, let\u2019s say you have a 1MB JS file that runs as a long task on the main thread and blocks interactivity while it runs. You can split it into 50KB chunks so tasks won\u2019t run as long, and there are more spaces in between at shorter periods where a page could respond to user input.<\/li><\/ul>\n\n\n\n
Filetype Fonts<\/h3>\n\n\n\n
With fonts, you have many of the same options as we mentioned before (e.g., inlining or preloading a needed font). You\u2019ll find some code samples for preloading fonts here<\/a> if you want to go that route. However, with fonts, what I would recommend is using font-display: swap;, which simply uses a default system font until the custom font is ready and then swaps in the custom font. This is relatively easy to do in your stylesheet.<\/p>\n\n\n\n
@font-face {\n font-family: 'Whatever';\n font-display: swap;
}\n<\/pre>\n\n\n\nIf you\u2019re using Google fonts, it\u2019s even easier. All you need to do is add
&display=swap<\/code> as a parameter in the URL.<\/p>\n\n\n\n<link href=\"https:\/\/fonts.googleapis.com\/css?family=Whatever&display=swap\" rel=\"stylesheet\"><\/code><\/p>\n\n\n\nFiletype Images<\/h3>\n\n\n\n
The main concern with images is their size and weight. You want optimized images that are loading the right size for the right device and with the right quality.<\/p>\n\n\n\n
Images are loaded asynchronously, so they\u2019re not blocking the load of the page, but they can add to the weight and overall time to interactive.<\/p>\n\n\n\n
Another potential issue has to do with prioritization, where some images may not be prioritized correctly or prioritized before critical files like CSS and JS. I won\u2019t go into detail on this, but you can find more details and some information on how to troubleshoot here<\/a> and here<\/a>. There can also be conditions where many images load, maxing out resources such as the bandwidth and slowing down the overall page load.<\/p>\n\n\n\n
Many of the things we have talked about, like inline and preload can be used for images but with the same trade-offs like caching or complexity. The number one rule is not to use a lot of images or large images above the fold in your theme. You don\u2019t have to show your giant background images on mobile devices. People can live without them. If you must show the images, what I\u2019d recommend is preload, and this is covered pretty thoroughly by this guide<\/a>.<\/p>\n\n\n\n
There\u2019s a great guide covering image optimization and different formats at https:\/\/images.guide\/<\/a>.
Always do image optimization in a scalable way. There are lots of options to do this at different levels like with the CDN, server, by the CMS, with an API, etc. Here are a few options:<\/p>\n\n\n\nImage optimization CDNs:<\/strong>
Akamai Image Manager<\/a>
imgix<\/a>
Image Engine<\/a>
Cloudinary<\/a>
Uploadcare<\/a><\/p>\n\n\n\nImage optimization APIs:<\/strong>
ShortPixel<\/a>
Fastly Image Optimizer<\/a>
Kraken.io<\/a>
TinyPNG<\/a>
Imagify<\/a> <\/p>\n\n\n\nGUI:<\/strong>
ImageOptim<\/a>
Squoosh<\/a> <\/p>\n\n\n\nCommand Line:<\/strong>
Imagemin<\/a> also has an npm<\/a> module if you\u2019re using webpack, gulp, or grunt<\/p>\n\n\n\nJPEG:<\/strong>
Guetzli<\/a>
MozJPEG<\/a>
PNG:<\/strong>
pngquant<\/a>
Zopfli<\/a><\/p>\n\n\n\nGIF:<\/strong>
Gifsicle<\/a>
SVGO<\/a> <\/p>\n\n\n\nWordPress\/Drupal<\/strong><\/p>\n\n\n\n
I don\u2019t have any particular recommendations. You\u2019ll find a lot of options for WordPress<\/a> and Drupal<\/a>.<\/p>\n\n\n\n
Lazy Load Images<\/h4>\n\n\n\n
If someone tells you they need to \u201cdefer offscreen images,\u201d this is what you need. It is basically delaying the loading of images not above the fold because they\u2019re not needed yet. Once a user starts scrolling, the images will load in.<\/p>\n\n\n\n
I\u2019d say you want a library that uses IntersectionObserver but probably has a polyfill because of browser support. The most popular library for this is lazysizes<\/a>, but you\u2019ll find many options for your setup.<\/p>\n\n\n\n
As of Chrome 76, lazy loading has been brought into the browser. I expect more browsers to do the same soon, but for now, we may want to use this method for Chrome with a polyfill for other browsers. You can find more info here<\/a>. WordPress added lazy loading by default in version 5.4<\/a>.<\/p>\n\n\n\n
Responsive\/Resized Images<\/h4>\n\n\n\n
This is all about serving the right image for the right screen. Loading a large image and then scaling it down just wastes time and resources. There are again a lot of automated solutions for this. For example, many CDNs will handle it, and there are also things like the sharp npm package<\/a>, the ImageMagick CLI tool<\/a>, or various plugins\/modules for different systems.<\/p>\n\n\n\n
Changing Image Formats<\/h4>\n\n\n\n
Different formats like webp can be better but are problematic due to browser support. You either have to do a lot of detection and swapping or use a service that does it for you. There are plenty of guides<\/a>, but it\u2019s not something I\u2019d recommend most people tackle unless you can find an easy, automated way.<\/p>\n\n\n\n
Page Size \/ Weight<\/h3>\n\n\n\n
This is the size of all the resources combined. Smaller pages are faster. We\u2019ve already talked about many of the improvements like minification, compression, and simply getting rid of anything not used. The less a page has to load initially, the faster the page will display.<\/p>\n\n\n\n
The goal should be a minimal amount of data to get the content above the fold loaded as quickly as possible. You can then load the rest of the information needed on the page after, all while keeping everything as small as possible. Problems usually come from unused code, images, and general website bloat related to functionality or tools. The reason I\u2019m giving this its own section is that you should be considerate of the overall amount of data your page is using.<\/p>\n\n\n\n
- Code splitting<\/strong>: Splitting files into smaller chunks, so there are more opportunities for interactivity. For example, let\u2019s say you have a 1MB JS file that runs as a long task on the main thread and blocks interactivity while it runs. You can split it into 50KB chunks so tasks won\u2019t run as long, and there are more spaces in between at shorter periods where a page could respond to user input.<\/li><\/ul>\n\n\n\n
- Consolidate systems with similar functionality<\/strong>, like if you are running multiple analytics systems or multiple systems that have user information. Many programs have multiple functions, and sometimes you end up with scripts that have the same or similar functionality to another script when maybe you can do without one of them.<\/li>
- Use fewer tracking\/scripts.<\/strong> This can be a hard decision as marketers like data, but sometimes the amount of data being collected is just absurd.<\/li>
- First Contentful Paint (FCP) <\/strong>– browser renders something from the DOM (Document Object Model), which could be text, an image, etc.<\/li>
- Layouting happens, which is processing where each element will be within the browser viewport based on what\u2019s in the Render Tree.
- Impacts Analytics<\/strong>. Generally speaking, a faster site will record more visitors because the analytics tag will load sooner. If a person leaves before the tag is fired, they won\u2019t be recorded in the analytics system.<\/li>
- Why You Should Care About Page Speed<\/a><\/li>
- What is Page Speed?<\/a><\/li>
- Autoptimize<\/a> + a cache plugin<\/a><\/li><\/ul>\n\n\n\n
![\"pasted](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/pasted-image-0-63.png\")
<\/figure>\n\n\n\n![\"waterfall.php](\"https:\/\/ahrefs.com\/blog\/wp-content\/uploads\/2020\/03\/waterfall.php_-7.png\")
<\/p>\n\n\n\n