Front-End-Checklist
🗂 The perfect Front-End Checklist for modern websites and meticulous developers
Top Related Projects
A simple guide to HTML <head> elements
A list of helpful front-end related questions you can use to interview potential candidates, test yourself or completely ignore.
⚡️ Front End interview preparation materials for busy engineers
Interactive roadmaps, guides and other educational content to help developers grow in their careers.
Manually curated collection of resources for frontend web developers.
Quick Overview
The Front-End Checklist is a comprehensive guide for modern web development, providing an exhaustive list of elements to check before launching a website. It covers various aspects of front-end development, including HTML, CSS, JavaScript, performance, accessibility, and SEO, making it an invaluable resource for developers of all skill levels.
Pros
- Comprehensive and well-organized, covering all major aspects of front-end development
- Regularly updated to reflect current best practices and technologies
- Available in multiple languages, making it accessible to a global audience
- Includes priority levels for each item, helping developers focus on the most critical aspects first
Cons
- Can be overwhelming for beginners due to the extensive list of items
- Some items may not be applicable to all projects, requiring developers to carefully consider which checks are relevant
- Lacks in-depth explanations for some items, potentially requiring additional research
Getting Started
To use the Front-End Checklist:
- Visit the GitHub repository: https://github.com/thedaviddias/Front-End-Checklist
- Browse the README.md file for an overview of the project
- Access the full checklist at: https://frontendchecklist.io/
- Use the interactive web app to track your progress and generate a report
- Consider integrating the checklist into your development workflow by referencing it during the development and testing phases of your projects
Competitor Comparisons
A simple guide to HTML <head> elements
Pros of HEAD
- Focused specifically on
<head>
elements, providing comprehensive coverage - Includes explanations and use cases for each element
- Regularly updated with modern web standards and best practices
Cons of HEAD
- Limited scope compared to Front-End-Checklist's broader coverage
- Lacks interactive features like checkboxes for tracking progress
- Doesn't provide as much context on overall front-end development practices
Code Comparison
HEAD:
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Page Title</title>
Front-End-Checklist:
<!-- ESSENTIAL -->
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
<title>Page Title</title>
Both repositories provide valuable resources for front-end developers, but they serve different purposes. HEAD focuses exclusively on <head>
elements, offering in-depth information and best practices for this specific aspect of HTML documents. Front-End-Checklist, on the other hand, covers a broader range of front-end development topics, including HTML, CSS, JavaScript, performance, and more.
While HEAD excels in its specialized area, Front-End-Checklist provides a more comprehensive guide for overall front-end development. Developers may find it beneficial to use both resources in conjunction, leveraging HEAD for detailed <head>
element guidance and Front-End-Checklist for a broader development perspective.
A list of helpful front-end related questions you can use to interview potential candidates, test yourself or completely ignore.
Pros of Front-end-Developer-Interview-Questions
- Focuses on interview preparation, helping developers understand what to expect in technical interviews
- Covers a wide range of topics, including HTML, CSS, JS, and general web development concepts
- Regularly updated with community contributions, keeping the content current
Cons of Front-end-Developer-Interview-Questions
- Lacks practical implementation guidance or best practices for actual development
- May not be as comprehensive for day-to-day front-end development tasks
- Doesn't provide a structured checklist format for project implementation
Code Comparison
Front-End-Checklist provides practical examples and guidelines:
<!-- Recommended minimum HTML -->
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
Front-end-Developer-Interview-Questions focuses on conceptual questions:
Q: What's the difference between a variable that is: null, undefined or undeclared?
Q: What is a closure, and how/why would you use one?
Q: Explain the difference between: function Person(){}, var person = Person(), and var person = new Person()?
Both repositories serve different purposes: Front-End-Checklist is a comprehensive guide for implementing best practices in front-end projects, while Front-end-Developer-Interview-Questions is tailored for interview preparation and conceptual understanding of front-end development topics.
⚡️ Front End interview preparation materials for busy engineers
Pros of Front-End Interview Handbook
- Focuses specifically on interview preparation, providing targeted content for job seekers
- Includes detailed explanations and examples for common front-end interview questions
- Covers a wide range of topics, including JavaScript, CSS, and system design
Cons of Front-End Interview Handbook
- Less comprehensive for general front-end development best practices
- May not be as useful for day-to-day development tasks
- Lacks the structured checklist format found in Front-End Checklist
Code Comparison
Front-End Interview Handbook example (JavaScript):
function debounce(func, wait) {
let timeout;
return function executedFunction(...args) {
const later = () => {
clearTimeout(timeout);
func(...args);
};
clearTimeout(timeout);
timeout = setTimeout(later, wait);
};
}
Front-End Checklist example (HTML):
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="Description of the page">
<title>Page Title</title>
<link rel="canonical" href="https://example.com/page">
The code examples highlight the different focus areas of each repository. Front-End Interview Handbook provides JavaScript function implementations, while Front-End Checklist offers HTML best practices and structure.
Interactive roadmaps, guides and other educational content to help developers grow in their careers.
Pros of developer-roadmap
- Covers a broader range of topics, including backend, DevOps, and more
- Provides visual roadmaps for different career paths in software development
- Regularly updated with new technologies and industry trends
Cons of developer-roadmap
- Less detailed information on specific front-end topics
- May be overwhelming for beginners due to the vast amount of information
- Lacks practical checklists for immediate implementation
Code Comparison
While both repositories focus on educational content rather than code, Front-End-Checklist provides some HTML examples:
Front-End-Checklist:
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
developer-roadmap doesn't typically include code snippets, as it focuses on visual roadmaps and conceptual guidance.
Summary
Front-End-Checklist is more focused and practical for front-end developers, offering a comprehensive checklist for project implementation. developer-roadmap provides a broader overview of various tech career paths and technologies, making it suitable for those exploring different areas of software development or planning their learning journey. While Front-End-Checklist is more immediately actionable, developer-roadmap offers a wider perspective on the tech landscape.
Manually curated collection of resources for frontend web developers.
Pros of frontend-dev-bookmarks
- More comprehensive collection of resources covering a wider range of front-end development topics
- Better organized into categories and subcategories for easier navigation
- Includes more advanced and specialized topics for experienced developers
Cons of frontend-dev-bookmarks
- Less focused on practical implementation and best practices
- May be overwhelming for beginners due to the sheer volume of resources
- Not as regularly updated as Front-End-Checklist
Code comparison
While both repositories primarily focus on curating resources rather than providing code examples, Front-End-Checklist does include some code snippets for best practices. For example:
Front-End-Checklist:
<!-- Recommended minimum -->
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
frontend-dev-bookmarks doesn't typically include code snippets, instead focusing on linking to external resources.
Summary
Front-End-Checklist is more suitable for developers looking for a practical, actionable checklist of best practices, while frontend-dev-bookmarks serves as a comprehensive resource library for front-end developers at all levels. The choice between the two depends on whether you need a focused guide for project implementation or a broad reference for learning and exploration.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
 Front-End Checklist
Â
ð¨ Currently working on new version of frontendchecklist.io,
feel free to discuss any feature you would like to see. Thanks for your support!
The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your website / HTML page to production.
                    Â
 How To Use ⢠Contributing ⢠Website ⢠Product Hunt
Other Checklists:
 ð® Front-End Performance Checklist ⢠ð Front-End Design Checklist
It is based on Front-End developer's years of experience, with the additions coming from some other open-source checklists.
How to use?
All items in the Front-End Checklist are required for the majority of the projects, but some elements can be omitted or are not essential (in the case of an administration web app, you may not need RSS feed for example). We choose to use 3 levels of flexibility:
indicates that the item is recommended but can be omitted in certain situations. indicates that the item is highly recommended but can potentially be omitted in very specific cases. However, omitting these elements can negatively impact performance or SEO. indicates that the item cannot be omitted under any circumstances. Removing these elements may result in page malfunctions or cause accessibility and SEO issues. Testing should prioritize these elements first.
Some resources possess an emoticon to help you understand which type of content / help you may find on the checklist:
- ð: documentation or article
- ð : online tool / testing tool
- ð¹: media or video content
You can contribute to the Front-End Checklist App reading the CONTRIBUTING.md file which explains everything about the project.
Head
Notes: You can find a list of everything that could be found in the
<head>
of an HTML document.
Meta tag
- Doctype: The Doctype is HTML5 and is at the top of all your HTML pages.
<!doctype html> <!-- HTML5 -->
The next 2 meta tags (Charset and Viewport) need to come first in the head.
- Charset: The charset (UTF-8) is declared correctly.
<!-- Set character encoding for the document -->
<meta charset="utf-8">
- Viewport: The viewport is declared correctly.
<!-- Viewport for responsive web design -->
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
- Title: A title is used on all pages (SEO: Google calculates the pixel width of the characters used in the title, and it cuts off between 472 and 482 pixels. The average character limit would be around 55-characters).
<!-- Document Title -->
<title>Page Title less than 55 characters</title>
- ð Title - HTML - MDN
- ð SERP Snippet Generator
- Description: A meta description is provided, it is unique and doesn't possess more than 150 characters.
<!-- Meta Description -->
<meta name="description" content="Description of the page less than 150 characters">
- Favicons: Each favicon has been created and displays correctly. If you have only a
favicon.ico
, put it at the root of your site. Normally you won't need to use any markup. However, it's still good practice to link to it using the example below. Today, PNG format is recommended over.ico
format (dimensions: 32x32px).
<!-- Standard favicon -->
<link rel="icon" type="image/x-icon" href="https://example.com/favicon.ico">
<!-- Recommended favicon format -->
<link rel="icon" type="image/png" href="https://example.com/favicon.png">
<!-- Recommended modern favicon format (not recommended for legacy browsers) -->
<link rel="icon" type="image/svg+xml" href="https://example.com/favicon.svg">
- Apple Web App Meta: Apple meta-tags are present.
<!-- Apple Touch Icon (at least 200x200px) -->
<link rel="apple-touch-icon" href="/custom-icon.png">
<!-- To run the web application in full-screen -->
<meta name="apple-mobile-web-app-capable" content="yes">
<!-- Status Bar Style (see Supported Meta Tags below for available values) -->
<!-- Has no effect unless you have the previous meta tag -->
<meta name="apple-mobile-web-app-status-bar-style" content="black">
- Windows Tiles: Windows tiles are present and linked.
<!-- Microsoft Tiles -->
<meta name="msapplication-config" content="browserconfig.xml" />
Minimum required xml markup for the browserconfig.xml
file is as follows:
<?xml version="1.0" encoding="utf-8"?>
<browserconfig>
<msapplication>
<tile>
<square70x70logo src="small.png"/>
<square150x150logo src="medium.png"/>
<wide310x150logo src="wide.png"/>
<square310x310logo src="large.png"/>
</tile>
</msapplication>
</browserconfig>
- Canonical: Use
rel="canonical"
to avoid duplicate content.
<!-- Helps prevent duplicate content issues -->
<link rel="canonical" href="http://example.com/2017/09/a-new-article-to-read.html">
HTML tags
- Language attribute: The
lang
attribute of your website is specified and related to the language of the current page.
<html lang="en">
- Direction attribute: The direction of lecture is specified on the html tag (It can be used on another HTML tag).
<html dir="rtl">
- ð dir - HTML - MDN
- Alternate language: The language tag of your website is specified and related to the language of the current page.
<link rel="alternate" href="https://es.example.com/" hreflang="es">
- x-default: The language tag of your website for international landing pages.
<link rel="alternate" href="https://example.com/" hreflang="x-default" />
- ð x-default - Google
- Conditional comments: Conditional comments are present for IE if needed.
-
RSS feed: If your project is a blog or has articles, an RSS link was provided.
-
CSS Critical: The CSS critical (or "above the fold") collects all the CSS used to render the visible portion of the page. It is embedded before your principal CSS call and between
<style></style>
in a single line (minified).
- ð Critical by Addy Osmani on GitHub automates this.
- CSS order: All CSS files are loaded before any JavaScript files in the
<head>
. (Except the case where sometimes JS files are loaded asynchronously on top of your page).
Social meta
Visualize and generate automatically our social meta tags with Meta Tags
Facebook OG and Twitter Cards are, for any website, highly recommended. The other social media tags can be considered if you target a particular presence on those and want to ensure the display.
- Facebook Open Graph: All Facebook Open Graph (OG) are tested and no one is missing or with false information. Images need to be at least 600 x 315 pixels, although 1200 x 630 pixels is recommended.
Notes: Using
og:image:width
andog:image:height
will specify the image dimensions to the crawler so that it can render the image immediately without having to asynchronously download and process it.
<meta property="og:type" content="website">
<meta property="og:url" content="https://example.com/page.html">
<meta property="og:title" content="Content Title">
<meta property="og:image" content="https://example.com/image.jpg">
<meta property="og:description" content="Description Here">
<meta property="og:site_name" content="Site Name">
<meta property="og:locale" content="en_US">
<!-- Next tags are optional but recommended -->
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
- ð A Guide to Sharing for Webmasters
- ð Best Practices - Sharing
- ð Test your page with the Facebook OG testing
- Twitter Card:
<meta name="twitter:card" content="summary">
<meta name="twitter:site" content="@site_account">
<meta name="twitter:creator" content="@individual_account">
<meta name="twitter:url" content="https://example.com/page.html">
<meta name="twitter:title" content="Content Title">
<meta name="twitter:description" content="Content description less than 200 characters">
<meta name="twitter:image" content="https://example.com/image.jpg">
- ð Getting started with cards â Twitter Developers
- ð Test your page with the Twitter card validator
HTML
Best practices
- HTML5 Semantic Elements: HTML5 Semantic Elements are used appropriately (header, section, footer, main...).
- ð HTML Reference
-
Error pages: Error 404 page and 5xx exist. Remember that the 5xx error pages need to have their CSS integrated (no external call on the current server).
-
Noopener: In case you are using external links with
target="_blank"
, your link should have arel="noopener"
attribute to prevent tab nabbing. If you need to support older versions of Firefox, userel="noopener noreferrer"
.
- ð About rel=noopener
- Clean up comments: Unnecessary code needs to be removed before sending the page to production.
HTML testing
- W3C compliant: All pages need to be tested with the W3C validator to identify possible issues in the HTML code.
- ð W3C validator
- HTML Lint: I use tools to help me analyze any issues I could have on my HTML code.
- ð Dirty markup
- ð webhint
- Link checker: There are no broken links in my page, verify that you don't have any 404 error.
- ð W3C Link Checker
- Adblockers test: Your website shows your content correctly with adblockers enabled (You can provide a message encouraging people to disable their adblocker).
Webfonts
Notes: Using web fonts may cause Flash Of Unstyled Text/Flash Of Invisible Text - consider having fallback fonts and/or utilizing web font loaders to control behavior.
- Webfont format: WOFF, WOFF2 and TTF are supported by all modern browsers.
-
Webfont size: Webfont sizes don't exceed 2 MB (all variants included).
-
Webfont loader: Control loading behavior with a webfont loader
CSS
Notes: Take a look at CSS guidelines and Sass Guidelines followed by most Front-End developers. If you have a doubt about CSS properties, you can visit CSS Reference. There is also a short Code Guide for consistency.
- Responsive Web Design: The website is using responsive web design.
- CSS Print: A print stylesheet is provided and is correct on each page.
- Preprocessors: Your project is using a CSS preprocessor (e.g Sass, Less, Stylus).
- Unique ID: If IDs are used, they are unique to a page.
- Reset CSS: A CSS reset (reset, normalize or reboot) is used and up to date. (If you are using a CSS Framework like Bootstrap or Foundation, a Normalize is already included into it.)
- ð Reset.css
- ð Normalize.css
- ð Reboot
- JS prefix: All classes (or id- used in JavaScript files) begin with js- and are not styled into the CSS files.
<div id="js-slider" class="my-slider">
<!-- Or -->
<div id="id-used-by-cms" class="js-slider my-slider">
- embedded or inline CSS: Avoid at all cost embedding CSS in
<style>
tags or using inline CSS: only use for valid reasons (e.g. background-image for slider, critical CSS). - Vendor prefixes: CSS vendor prefixes are used and are generated accordingly with your browser support compatibility.
Performance
- Concatenation: CSS files are concatenated in a single file (Not for HTTP/2).
- Minification: All CSS files are minified.
- Non-blocking: CSS files need to be non-blocking to prevent the DOM from taking time to load.
- Unused CSS: Remove unused CSS.
- ð UnCSS Online
- ð PurifyCSS
- ð PurgeCSS
- ð Chrome DevTools Coverage
CSS testing
- Stylelint: All CSS or SCSS files are without any errors.
- ð stylelint, a CSS linter
- ð Sass guidelines
- Responsive web design: All pages were tested at the following breakpoints: 320px, 768px, 1024px (can be more / different according to your analytics). Responsive Checker -
- ð Am I Responsive?
- ð Mobile Friendly Test
- ð Responsive Website Design Tester
- ð Responsinator
- ð XRespond
- CSS Validator: The CSS was tested and pertinent errors were corrected.
- ð CSS Validator
-
Desktop Browsers: All pages were tested on all current desktop browsers (Safari, Firefox, Chrome, Internet Explorer, EDGE...).
-
Mobile Browsers: All pages were tested on all current mobile browsers (Native browser, Chrome, Safari...).
-
OS: All pages were tested on all current OS (Windows, Android, iOS, Mac...).
-
Design fidelity: Depending on the project and the quality of the creatives, you may be asked to be close to the design. You can use some tools to compare creatives with your code implementation and ensure consistency.
- Reading direction: All pages need to be tested for LTR and RTL languages if they need to be supported.
Images
Notes: For a complete understanding of image optimization, check the free ebook Essential Image Optimization from Addy Osmani.
Best practices
- Optimization: All images are optimized to be rendered in the browser. WebP format could be used for critical pages (like Homepage).
- ð Imagemin
- ð Use ImageOptim to optimise your images for free.
- ð Use KeyCDN Image Processing for image optimization in real time.
- ð Use Kraken.io awesome alternative for both png and jpg optimization. Up to 1mb per files on free plan.
- ð TinyPNG optimises png, apng (animated png) and jpg images with very small loss in quality. Free and paid version available.
- ð ZorroSVG jpg-like compression for transparent images using svg masking.
- ð SVGO a Nodejs-based tool for optimizing SVG vector graphics files.
- ð SVGOMG a web-based GUI version of SVGO for optimising your svgs online.
- Picture/Srcset: You use picture/srcset to provide the most appropriate image for the current viewport of the user.
- Retina: You provide layout images 2x or 3x, support retina display.
- Sprite: Small images are in a sprite file (in the case of icons, they can be in an SVG sprite image).
- Width and Height: Set
width
andheight
attributes on<img>
if the final rendered image size is known (can be omitted for CSS sizing). - Alternative text: All
<img>
have an alternative text which describes the image visually.
- Lazy loading: Images are lazyloaded (A noscript fallback is always provided).
JavaScript
Best practices
- JavaScript Inline: You don't have any JavaScript code inline (mixed with your HTML code).
- Concatenation: JavaScript files are concatenated.
- Minification: JavaScript files are minified (you can add the
.min
suffix).
- JavaScript security:
-
noscript
tag: Use<noscript>
tag in the HTML body if a script type on the page is unsupported or if scripting is currently turned off in the browser. This will be helpful in client-side rendering heavy apps such as React.js, see examples.
<noscript>
You need to enable JavaScript to run this app.
</noscript>
- Non-blocking: JavaScript files are loaded asynchronously using
async
or deferred usingdefer
attribute.
- Optimized and updated JS libraries: All JavaScript libraries used in your project are necessary (prefer Vanilla Javascript for simple functionalities), updated to their latest version and don't overwhelm your JavaScript with unnecessary methods.
- Modernizr: If you need to target some specific features you can use a custom Modernizr to add classes in your
<html>
tag.
JavaScript testing
- ESLint: No errors are flagged by ESLint (based on your configuration or standards rules).
Security
Scan and check your web site
Best practices
- HTTPS: HTTPS is used on every page and for all external content (plugins, images...).
- HTTP Strict Transport Security (HSTS): The HTTP header is set to 'Strict-Transport-Security'.
- Cross Site Request Forgery (CSRF): You ensure that requests made to your server-side are legitimate and originate from your website / app to prevent CSRF attacks.
- Cross Site Scripting (XSS): Your page or website is free from XSS possible issues.
- Content Type Options: Prevents Google Chrome and Internet Explorer from trying to mime-sniff the content-type of a response away from the one being declared by the server.
- X-Frame-Options (XFO): Protects your visitors against clickjacking attacks.
- Content Security Policy: Defines how content is loaded on your site and from where it is permitted to be loaded. Can also be used to protect against clickjacking attacks.
Performance
Best practices
- Goals to achieve: Your pages should reach these goals:
- First Meaningful Paint under 1 second
- Time To Interactive under 5 seconds for the "average" configuration (a $200 Android on a slow 3G network with 400ms RTT and 400kbps transfer speed) and under 2 seconds for repeat visits
- Critical file size under 170Kb gzipped
-
Minified HTML: Your HTML is minified.
-
Lazy loading: Images, scripts and CSS need to be lazy loaded to improve the response time of the current page (See details in their respective sections).
-
Cookie size: If you are using cookies be sure each cookie doesn't exceed 4096 bytes and your domain name doesn't have more than 20 cookies.
- ð Cookie specification: RFC 6265
- ð Cookies
- ð Browser Cookie Limits
- Third party components: Third party iframes or components relying on external JS (like sharing buttons) are replaced by static components when possible, thus limiting calls to external APIs and keeping your user's activity private.
Preparing upcoming requests
- DNS resolution: DNS of third-party services that may be needed are resolved in advance during idle time using
dns-prefetch
.
<link rel="dns-prefetch" href="https://example.com">
- Preconnection: DNS lookup, TCP handshake and TLS negotiation with services that will be needed soon is done in advance during idle time using
preconnect
.
<link rel="preconnect" href="https://example.com">
- Prefetching: Resources that will be needed soon (e.g. lazy loaded images) are requested in advance during idle time using
prefetch
.
<link rel="prefetch" href="image.png">
- Preloading: Resources needed in the current page (e.g. scripts placed at the end of
<body>
) in advance usingpreload
.
<link rel="preload" href="app.js">
Performance testing
- Google PageSpeed: All your pages were tested (not only the homepage) and have a score of at least 90/100.
Accessibility
Notes: You can watch the playlist A11ycasts with Rob Dodson ð¹
Best practices
- Progressive enhancement: Major functionality like main navigation and search should work without JavaScript enabled.
- Color contrast: Color contrast should at least pass WCAG AA (AAA for mobile).
- ð Contrast ratio
Headings
- H1: All pages have an H1 which is not the title of the website.
- Headings: Headings should be used properly and in the right order (H1 to H6).
Semantics
- Specific HTML5 input types are used: This is especially important for mobile devices that show customized keypads and widgets for different types.
- ð Mobile Input Types
Form
- Label: A label is associated with each input form element. In case a label can't be displayed, use
aria-label
instead.
Accessibility testing
- Accessibility standards testing: Use the WAVE tool to test if your page respects the accessibility standards.
- ð Wave testing
- Keyboard navigation: Test your website using only your keyboard in a previsible order. All interactive elements are reachable and usable.
- Screen-reader: All pages were tested in a screen-reader (VoiceOver, ChromeVox, NVDA or Lynx).
- Focus style: If the focus is disabled, it is replaced by visible state in CSS.
SEO
- Google Analytics: Google Analytics is installed and correctly configured.
- Search Console: Search Console is installed and correctly configured. It is a free service offered by Google that helps you monitor, maintain, and troubleshoot your site's presence in Google Search results.
- ð Search Console
- Headings logic: Heading text helps to understand the content in the current page.
- sitemap.xml: A sitemap.xml exists and was submitted to Google Search Console (previously Google Webmaster Tools).
- robots.txt: The robots.txt is not blocking webpages.
- ð The robots.txt file
- ð Test your robots.txt with Google Robots Testing Tool
- Structured Data: Pages using structured data are tested and are without errors. Structured data helps crawlers understand the content in the current page.
- ð Introduction to Structured Data - Search - Google Developers
- ð JSON-LD
- ð Microdata
- ð Test your page with the Rich Results Test
- ð Complete list of vocabularies that can be used as structured data. Schema.org Full Hierarchy
- Sitemap HTML: An HTML sitemap is provided and is accessible via a link in the footer of your website.
Translations
The Front-End Checklist is also available in other languages. Thanks for all translators and their awesome work!
- ð¯ðµ Japanese: miya0001/Front-End-Checklist
- ðªð¸ Spanish: eoasakura/Front-End-Checklist-ES
- ð¨ð³ Chinese: JohnsenZhou/Front-End-Checklist
- ð°ð· Korean: kesuskim/Front-End-Checklist
- ð§ð· Portuguese: jcezarms/Front-End-Checklist
- ð»ð³ Vietnamese: euclid1990/Front-End-Checklist
- ð¹ð¼ Traditional Chinese: EngineLin/Front-End-Checklist
- ð«ð· French: ynizon/Front-End-Checklist
- ð·ðº Russian: ungear/Front-End-Checklist
- ð¹ð· Turkish: eraycetinay/Front-End-Checklist
- ð©ðª German: xfuture603/Front-End-Checklist
- ðµð± Polish: mbiesiad/Front-End-Checklist
- ð®ð© Indonesian: nniinnoo/Front-End-Checklist
Front-End Checklist Badge
If you want to show you are following the rules of the Front-End Checklist, put this badge on your README file!
[![FrontâEnd_Checklist followed](https://img.shields.io/badge/FrontâEnd_Checklist-followed-brightgreen.svg)](https://github.com/thedaviddias/Front-End-Checklist/)
Contributing
Open an issue or a pull request to suggest changes or additions.
Guide
The Front-End Checklist repository consists of two branches:
1. master
This branch consists of the README.md
file that is automatically reflected on the Front-End Checklist website.
2. develop
This branch will be used to make some significant changes to the structure, content if needed. It is preferable to use the master branch to fix small errors or add a new item.
Support
If you have any question or suggestion, don't hesitate to use Gitter or Twitter:
Author
Contributors
This project exists thanks to all the people who contribute. [Contribute].
Backers
Thank you to all our backers! ð [Become a backer]
Sponsors
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]
License
Top Related Projects
A simple guide to HTML <head> elements
A list of helpful front-end related questions you can use to interview potential candidates, test yourself or completely ignore.
⚡️ Front End interview preparation materials for busy engineers
Interactive roadmaps, guides and other educational content to help developers grow in their careers.
Manually curated collection of resources for frontend web developers.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot