Page speed is related to site optimization such as "site speed", which refers to the average loading time of more than one page on a site. Many factors determine page speed; including server quality, file size, image compression, and more.
Sec1. Relationship between page load speed and rank
Web page loading speed has a certain causal relationship with search rankings in search engines. As for the relationship between page loading speed and rank, I think that it is correct to take the following way of thinking at present.
- By improving page loading speed, user behavior changes positively, and as a result, it works positively for ranking
- It is not an algorithm that the faster the loading speed, the higher the evaluation
- Extremely slow loading speed page rank down
This time, we will summarize the index and measurement method of the page loading speed, and measures to improve page speed from the SEO point of view.
After clarifying all elements related to web page loading speed, I intend to cover tips on optimizing each element from the viewpoint of loading speed, so it is a reference for site operators who are trying to improve page loading speed. I would appreciate it if you could be.
In addition, this note does not deal with AMP.
Sec2. Page load speed index and measurement method
1. Page load speed metrics
a. First Contentful Paint (FCP)
- First paint of meaningful content
- Time taken for the main content of the page to become visible
b. Time to Interactive (TTI)
- Time until it becomes interactive
- Time until the page becomes completely interactive
c. First Input Delay (FID)
- Estimated waiting time for input
- Time to respond to user input
2. Measuring page load speed metrics
a. Lighthouse
- FCP, TTI can be measured
- Fast: 90-100, Average: 50-89, Slow: 0-49
- About Lighthouse: " Web app audit by Lighthouse "
- Lighthouse's Google Chrome extension
b. PageSpeed Insight
- FCP, TTI, FID can be measured
- PageSpeed Insight
c. Chrome User Experience Report
- FCP, FID can be measured
- About Chrome User Experience Report
d. Webperf API
- FCP. FID can be measured
Sec3. Size of rendering resources
The resources with a large amount of rendering data per page on average on the mobile web are in the following order.
1. Images (approximately 500KB)
2. JavaScript (approximately 380KB)
3. Fonts (approximately 80KB)
4. CSS
5. HTML
6. Other resources
Sec4. Page load speed optimization
I will explain for each resource how to improve the page loading speed by dealing with each of the upper elements of the rendering resource.
1. Appropriate image format
a. WebP
- WebP: An image format developed by Google that can be highly compressed while maintaining quality (currently available to 72% of users globally)
- Chrome, MS Edge are supported, Firefox is planned to be supported, Safari is unknown
- JPEG , the size is 25-35% smaller than PNG
- HTML example that properly delivers images to both browsers that support WebP and browsers that do not support WebP only)
<picture>
<source type=“image/webp” srcset=“example.webp”>
<source type=“image/jpeg” srcset=“example.jpg”>
<img src=“example.jpg">
</picture>
b. Animated GIF
- Use MPEG-4 (MP4) because animated GIFs are large in size.・Using ffmeg (https://www.ffmpeg.org/), you can convert animated GIF to MP4 on the command line ($ ffmeg -i dog.gif)
- After conversion, change the HTML tag from <img> to < Change to video> tag
- Add “autoplay loop muted plyasinline” to auto play, loop play, mute, and inline play MP4 videos like animated GIF (example below)
<video autoplay loop muted plyasinline>
<source src=“example.mp4” type=“video/mp4”>
</video>
c. Video
- AV1 is recommended in the future
- Compression is about 30% better than VP9 (WebM)
- Compression is 45-50% better than x264 (MPEG-4) –
2. Image compression
a. Type of image compression
- Lossless: No data loss
- Lossy : Data is lost but higher compression is possible
- Lossless compression is the minimum required.
For compression, you can set the compression rate on a scale of 0 to 100 (the closer to 0, the higher the compression, but the lower the image quality).
For most images, lossy compression at 80 to 85 reduces the file size by 30 to 40%. Minimize quality deterioration
b. Compression tool
- Imagemin is common
- Imagemin: Can be used from various technologies such as webpack, node.js, gulp (there are plugins for major image formats such as JPG, PNG, GIF)
3. Appropriate image size / density
Distribute image size according to image size and device screen size (cf. MERY) → Reduce data transfer volume and CPU usage・Use npm package Sharp and Jimp as image resizing tools It is possible to deliver images of multiple sizes → By specifying the size of the image with srcset and size, the browser can decide which image to render (use w instead of px) (HTML example below )
<img srcset=“example-small.jpg 480w, example-large.jpg 1080w” size=“50vw” src=“example.jpg”>
4. Lazyload
a. Lazyload overview
- Technology that delays the loading of resources until a certain timing
- Mainly used for images, but can also be used for other resources such as JavaScript
- Main purpose is to improve performance when loading pages
- cf. Spotify uses Lazyload → Loading all images on the page is 18MB, but loading only the image on the screen can be reduced to 1MB
- Generally implemented with JavaScript
- Chrome supports Lazyload as a browser function Become
b. Lazyload and SEO
- Generally, Lazyload is implemented with JavaScript.・Images implemented with Lazyload are not originally crawled or indexed by Google. Recommended implementation of Lazyload
- Google recommends implementation of polyfill and setting of <noscript> tag and structured data when implementing Lazyload (implementation of polyfill is very important for SEO)
1) IntersectionObserver API
Supported from Chrome 51 → Since the current WRS (Web Rendering Service) is equivalent to Chrome 41, Google cannot render images that are lazy loaded with the IntersectionObserver API.
2) Polyfill
- Polyfill: Mechanism for enabling browsers that do not support new technology to use its functions
- Polyfill allows Google/WRS, which does not support the IntersectionObserver API, to recognize images (the user's browser has IntersectionObserver Adapt Lazyload via API and make Googlebot recognize all images from the beginning with a polyfill)
3) <noscript> tag
- How to specify the image with the <noscript> tag so that Googlebot can recognize the image without executing JavaScript
- Google processes the <noscript> tag normally for Lazyload images
- cf. Originally, Googlebot ignores the <noscript> tag (because it was abused by spam), but this does not apply to what is written for Lazyload images
- Alt attribute even when specifying an image with a <noscript> tag should set
4) Structured data
- Describe the URL of the image in the structured data
- Google gets the URL of the structured data and crawls and indexes the image even if the actual image is not displayed
- JSON -Use LD to markup (because microdata marks up the actual image)
- For structured data of a type that has an Image property, just set the URL of the image as it is
- If possible, use more It is good to set many properties
- ImageObject structured data can be used for images (markup example below)
<script type=“application/ld+json”>
{
“@context": “http://schema.org”,
“@type”: “https://example.com/barackobama.jpg”,
“description”: “barack obama photo”
}
</script>
5. JavaScript optimization
a. JavaScript overview
- Median data volume per page of JavaScript: 370 KB for mobile, 420 KB for desktop (Since JavaScript is compressed and transferred, it actually becomes a file of about 1 MB) → Restore, parse, and execute this to improve performance very slow on devices with low
b. Measures to speed up the loading of JavaScript resources
- Code Splitting
- Preload
- Scrutinize unused JavaScript (and CSS)
6. Font optimization
- Web fonts reduce page loading speed
- Flash of Invisible Text (FOIT): A phenomenon in which characters do not appear until the browser loads web fonts → Adoption of Flash of Unstyled Text is recommended for UX
- Flash of Unstyled Text ( FOUT): Technology that displays characters by substituting system fonts until the browser downloads web fonts (replaces system fonts when web fonts are downloaded)
- cf. System fonts: Default on PCs and smartphones Font
- The following is an implementation example of FOUT (the last line is an instruction to change fonts to the browser)
@font-face {
font-family: ‘Pacifico’;
src: url (…pacifico.woff22) format (‘woff2’);
font-display: swap;
}
7. Redirect limit
- Redirects on each page should be limited to once or less.
8. File Compression
- Delete unnecessary data
- If the data cannot be deleted, use tools such as Gzip, Brotli, etc. to compress the content and reduce the file size
9. Keep server response time under 200ms
- Using HTTP/2 can improve site performance
- Enable OCSP stapling to speed up TLS handshake time
10. Setting Cache Policy
Use browser caching to control how and for how long the browser caches responses
Use Etags to streamline revalidation
11. CSS Optimization
a. CSS optimization
- Use only one CSS file for external references → Reduce latency caused by HTTP requests
b. Inlining
- Write CSS specific to the page inline (do not refer to external files)
- Inline small CSS files into HTML
- Do not inline large CSS files or CSS attributes into HTML elements (external files refer to)
12. Optimization above the fold
Above the fold Optimization base
- Above the fold: screen area where users can browse without scrolling (so-called first view)
- Clean HTML markup to prioritize content visualization, Make sure it renders quickly
- Keep first-view content size under 148kB
- Especially important for mobile users
- Google recommends Above the fold content to render in less than 1 second
- cf. reads and displays HTML in order from top to bottom
a. Separate the HTML above the fold and the rest
- Write the HTML for the content above the fold first
- The sidebar code for the part displayed above the fold is also separated from the other sidebar HTML
- Inline the CSS applied to the content above the fold without externally referencing it
b. Remove JavaScript that interferes with first view rendering
- Separate unimportant scripts into third-party JavaScript libraries below after the fold
- If JavaScript exists above the fold, write the <script> tag as a sync and render it do not interfere
c. Delay the loading of JavaScript until the content of above the fold finishes loading
- Delay the loading of low-priority JavaScript (such as JavaScript for social buttons)
- In order to delay the loading of JavaScript, use the closing body tag (< /body>) and write the following code
<script type=“text/javascript”>
function downloadJSAtOnload() {
var element = document.createElement(“script”);
element.src = “The path of the externally referenced JavaScript file in the environment of your site”;
document.body.appendChild(element);
}
if (window.addEventListener)
widow.addEventListener(“load”, downloadJSAtOnload, false);
else if (window.attachEvent)
window.attachEvent(“onload”, downloadJSAtOnload);
else window.onload = downloadJSAtOnload;
</script>
end
Above is a list of measures to improve page loading speed. In the future, I would like to add it as needed when more effective technologies and measures appear. As mentioned at the beginning, the faster the page loading speed, the more positively it affects search rankings.
Pages that load faster should be more comfortable for users, so I think it’s better not to be too conscious of SEO and work on speeding up for the best user experience.