"“““““““““““““ A brief history of Google’s mission to make the web faster In 2009, by issuing a call..."

““““““““““““““

A brief history of Google’s mission to make the web faster

In 2009, by issuing a call to arms to “make the web faster”, Google set out on a mission to try and persuade website owners to make their sites load more quickly.

In order to entice website owners into actually caring about this, in 2010 Google announced that site speed would become a factor in its desktop (non-mobile) search engine ranking algorithms. This meant that sites that loaded quickly would have an SEO advantage over other websites.

Six years later, in 2015, Google announced that the number of searches performed on mobile exceeded those performed on desktop computers. That percentage continues to increase. The latest published statistic says that, as of 2019, 61% of searches performed on Google were from mobile devices.

Mobile’s now-dominant role in search led Google to develop its “Accelerated Mobile Pages” (AMP) project. This initiative is aimed at encouraging website owners to create what is essentially another mobile theme, on top of their responsive mobile theme, that complies with a very strict set of development and performance guidelines.

Although many site owners and SEOs complain about having to tend to page speed and AMP on top of the other 200+ ranking factors that already give them headaches, page speed is indeed a worthy effort for site owners to focus on. In 2017, Google conducted a study where the results very much justified their focus on making the web faster. They found that “As page load time goes from one second to 10 seconds, the probability of a mobile site visitor bouncing increases 123%.”

In July of 2018, page speed became a ranking factor for mobile searches, and today Google will incorporate even more speed-related factors (called Core Web Vitals) in its ranking algorithms.

With the average human attention span decreasing all the time, and our reliance on our mobile devices growing consistently, there’s no question that page speed is, and will continue to be, an incredibly important thing for website owners to tend to.

How to optimize a website for speed

Think like a race car driver

Winning the page speed race requires the same things as winning a car race. To win a race in a car, you make sure that your vehicle is as lightweight as possible, as powerful as possible, and you navigate the racetrack as efficiently as possible.

I’ll use this analogy to try to make page speed optimization techniques a bit more understandable.

Make it lightweight

These days, websites are more beautiful and functional than ever before — but that also means they are bigger than ever. Most modern websites are the equivalent of a party bus or a limo. They’re super fancy, loaded with all sorts of amenities, and therefore HEAVY and SLOW. In the search engine “racetrack,” you will not win with a party bus or a limo. You’ll look cool, but you’ll lose.

Image source: A GTMetrix test results page

To win the page speed race, you need a proper racing vehicle, which is lightweight. Race cars don’t have radios, cupholders, glove boxes, or really anything at all that isn’t absolutely necessary. Similarly, your website shouldn’t be loaded up with elaborate animations, video backgrounds, enormous images, fancy widgets, excessive plugins, or anything else at all that isn’t absolutely necessary.

In addition to decluttering your site of unnecessary fanciness and excessive plugins, you can also shed website weight by:

• Reducing the number of third-party scripts (code snippets that send or receive data from other websites)

• Switching to a lighter-weight (less code-heavy) theme and reducing the number of fonts used

• Implementing AMP

• Optimizing images

• Compressing and minifying code

• Performing regular database optimizations

On an open-source content management system like WordPress, speed plugins are available that can make a lot of these tasks much easier. WP Rocket and Imagify are two WordPress plugins that can be used together to significantly lighten your website’s weight via image optimization, compression, minification, and a variety of other page speed best practices.

Give it more power

You wouldn’t put a golf cart engine in a race car, so why would you put your website on a dirt-cheap, shared hosting plan? You may find it painful to pay more than a few dollars per month on hosting if you’ve been on one of those plans for a long time, but again, golf cart versus race car engine: do you want to win this race or not?

Traditional shared hosting plans cram tens of thousands of websites onto a single server. This leaves each individual site starved for computing power.

If you want to race in the big leagues, it’s time to get a grown-up hosting plan. For WordPress sites, managed hosting companies such as WP Engine and Flywheel utilize servers that are powerful and specifically tuned to serve up WordPress sites faster.

If managed WordPress hosting isn’t your thing, or if you don’t have a WordPress site, upgrading to a VPS (Virtual Private Server) will result in your website having way more computing resources available to it. You’ll also have more control over your own hosting environment, allowing you to “tune-up your engine” with things like the latest versions of PHP, MySQL, Varnish caching, and other modern web server technologies. You’ll no longer be at the mercy of your shared hosting company’s greed as they stuff more and more websites onto your already-taxed server.

In short, putting your website on a well-tuned hosting environment can be like putting a supercharger on your race car.

Drive it better

Last, but certainly not least, a lightweight and powerful race car can only go so fast without a trained driver who knows how to navigate the course efficiently.

The “navigate the course” part of this analogy refers to the process of a web browser loading a webpage. Each element of a website is another twist or turn for the browser to navigate as it travels through the code and processes the output of the page.

I’ll switch analogies momentarily to try to explain this more clearly. When remodeling a house, you paint the rooms first before redoing the floors. If you redid the floors first and then painted the rooms, the new floors would get paint on them and you’d have to go back and tend to the floors again later.

When a browser loads a webpage, it goes through a process called (coincidentally) “painting.” Each page is “painted” as the browser receives bits of data from the webpage’s source code. This painting process can either be executed efficiently (i.e. painting walls before refinishing floors), or it can be done in a more chaotic out-of-order fashion that requires several trips back to the beginning of the process to redo or fix or add something that could’ve/should’ve been done earlier in the process.

Image source: WebPageTest.org Test Result (Filmstrip View)

Here’s where things can get technical, but it’s important to do whatever you can to help your site drive the “track” more efficiently.

Caching is a concept that every website should have in place to make loading a webpage easier on the browser. It already takes long enough for a browser to process all of a page’s source code and paint it out visually to the user, so you might as well have that source code ready to go on the server. By default, without caching, that’s not the case.

Without caching, the website’s CMS and the server can still be working on generating the webpage’s source code while the browser is waiting to paint the page. This can cause the browser to have to pause and wait for more code to come from the server. With caching, the source code of a page is pre-compiled on the server so that it’s totally ready to be sent to the browser in full in one shot. Think of it like a photocopier having plenty of copies of a document already produced and ready to be handed out, instead of making a copy on demand each time someone asks for one.

Various types and levels of caching can be achieved through plugins, your hosting company, and/or via a CDN (Content Delivery Network). CDNs not only provide caching, but they also host copies of the pre-generated website code on a variety of servers across the world, reducing the impact of physical distance between the server and the user on the load time. (And yes, the internet is actually made up of physical servers that have to talk to each other over physical distances. The web is not actually a “cloud” in that sense.)

Getting back to our race car analogy, utilizing caching and a CDN equals a much faster trip around the racetrack.

Those are two of the basic building blocks of efficient page painting, but there are even more techniques that can be employed as well. On WordPress, the following can be implemented via a plugin or plugins (again, WP Rocket and Imagify are a particularly good combo for achieving a lot of this):

• Asynchronous and/or deferred loading of scripts. This is basically a fancy way of referring to loading multiple things at the same time or waiting until later to load things that aren’t needed right away.

• Preloading and prefetching. Basically, retrieving data about links in advance instead of waiting for the user to click on them.

• Lazy loading. Ironic term being that this concept exists for page speed purposes, but by default, most browsers load ALL images on a page, even those that are out of sight until a user scrolls down to them. Implementing lazy loading means telling the browser to be lazy and wait on loading those out-of-sight images until the user actually scrolls there.

• Serving images in next-gen formats. New image formats such as WebP can be loaded much faster by browsers than the old-fashioned JPEG and PNG formats. But it’s important to note that not all browsers can support these new formats just yet — so be sure to use a plugin that can serve up the next-gen versions to browsers that support them, but provide the old versions to browsers that don’t. WP Rocket, when paired with Imagify, can achieve this.

Image source: WP Rocket plugin settings

Optimize for Core Web Vitals

Lastly, optimizing for the new Core Web Vital metrics (Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift) can make for a much more efficient trip around the racetrack as well.

Image source

These are pretty technical concepts, but here’s a quick overview to get you familiar with what they mean:

• Largest Contentful Paint (LCP) refers to the painting of the largest element on the page. Google’s PageSpeed Insights tool will tell you which element is considered to be the LCP element of a page. A lot of times this is a hero image or large slider area, but it varies from page to page, so run the tool to identify the LCP in your page and then think about what you can do to make that particular element load faster.
  

• First Input Delay (FID) is the delay between the user’s first action and the browser’s ability to respond to it. An example of an FID issue would be a button that is visible to a user sooner than it becomes clickable. The delay would be caused by the click functionality loading notably later than the button itself.

• Cumulative Layout Shift (CLS) is a set of three big words that refer to one simple concept. You know when you’re loading up a webpage on your phone and you go to click on something or read something but then it hops up or down because something else loaded above it or below it? That movement is CLS, it’s majorly annoying, and it’s a byproduct of inefficient page painting.

In conclusion, race car > golf cart

Page speed optimization is certainly complex and confusing, but it’s an essential component to achieve better rankings. As a website owner, you’re in this race whether you like it or not — so you might as well do what you can to make your website a race car instead of a golf cart!

”

- http://monleyhomes.blogspot.com/2021/09/winning-page-speed-race-how-to-turn.html
from Tumblr https://monleyhomes.tumblr.com/post/661774629083529216”

- http://monleyhomes.blogspot.com/2021/09/a-brief-history-of-googles-mission-to.html
from Tumblr https://monleyhomes.tumblr.com/post/661777905962139648”

- http://monleyhomes.blogspot.com/2021/09/brief-history-of-googles-mission-to.html
from Tumblr https://monleyhomes.tumblr.com/post/661793008872833024”

- http://monleyhomes.blogspot.com/2021/09/a-brief-history-of-googles-mission-to_8.html
from Tumblr https://monleyhomes.tumblr.com/post/661808105283289088”

- http://monleyhomes.blogspot.com/2021/09/brief-history-of-googles-mission-to_8.html
from Tumblr https://monleyhomes.tumblr.com/post/661823234780643328”

- http://monleyhomes.blogspot.com/2021/09/a-brief-history-of-googles-mission-to_9.html
from Tumblr https://monleyhomes.tumblr.com/post/661842151535198208”

- http://monleyhomes.blogspot.com/2021/09/brief-history-of-googles-mission-to_9.html
from Tumblr https://monleyhomes.tumblr.com/post/661857153325367296”

- http://monleyhomes.blogspot.com/2021/09/a-brief-history-of-googles-mission-to_49.html
from Tumblr https://monleyhomes.tumblr.com/post/661872279372906496”

- http://monleyhomes.blogspot.com/2021/09/brief-history-of-googles-mission-to_17.html
from Tumblr https://monleyhomes.tumblr.com/post/661887350313533440”

- http://monleyhomes.blogspot.com/2021/09/a-brief-history-of-googles-mission-to_95.html
from Tumblr https://monleyhomes.tumblr.com/post/661906201353797632”

- http://monleyhomes.blogspot.com/2021/09/brief-history-of-googles-mission-to_10.html
from Tumblr https://monleyhomes.tumblr.com/post/661921328173056000”

- http://monleyhomes.blogspot.com/2021/09/a-brief-history-of-googles-mission-to_10.html
from Tumblr https://monleyhomes.tumblr.com/post/661936455102414848”

- http://monleyhomes.blogspot.com/2021/09/brief-history-of-googles-mission-to_85.html
from Tumblr https://monleyhomes.tumblr.com/post/661955417997557760”

- http://monleyhomes.blogspot.com/2021/09/a-brief-history-of-googles-mission-to_41.html
from Tumblr https://monleyhomes.tumblr.com/post/661966670643003392