62 things that Web developers should know before they develop a website

Intermediary transaction SEO diagnosis Taobao guest Cloud host technology Hall

Some people ask questions on stack overflow, what do you need to know before you start developing a Web site? He got a lot of answers, not surprisingly. Usually, you need to read all the speeches from beginning to end. However, Stack overflow has a very intimate design that allows you to open a wiki area under the problem, allowing everyone to edit an optimal answer together. So, there is the following article, summed up a total of six aspects of 62 "website development notice."

I have found that this sort of summary question is best suited to the collective wisdom, brainstorming style of answering. It's also the first time I've felt that Stack overflow did what Wikipedia couldn't. (No wonder it has recently squeezed into the top 400 websites of the United States.) In my impression, this comprehensive overview article on Web development is very rare and therefore useful. Let's see, how much did you do in 62 things?

interface and user experience (Interface and experience)

1.1, know the major browser implementation of the Web standards, to ensure that your site in the main browser can be normal operation. You should at least test the following engines: Gecko (for Firefox), Webkit (for Safari, Chrome and some mobile browsers), IE (you can use Microsoft's creator Compatibility VPC images to test ) and opera. At the same time, different operating systems may also affect how browsers present your site.

1.2, in addition to the browser, the site has other ways to use: mobile phones, screen readers, search engines and so on. You should know the health of your site in these cases. Mobiforge provides some relevant knowledge of mobile website development.

1.3, know how to do not affect the basic user use of the situation to upgrade the site. Typically, you must have a version control system (CVS, Subversion, Git, and so on) and a data backup mechanism.

1.4, do not let users see those unfriendly error prompts.

1.5, do not directly display the user's email address, at least not in plain text display.

1.6, for your site to set some reasonable use restrictions, once the threshold is exceeded, automatically stop service. (This is also related to Web site security.) )

1.7, know how to achieve Incremental Web page enhancement (progressive enhancement).

1.8, after the user issued a POST request, always redirect it (redirect) to another Web page.

1.9, do not forget the accessibility of the site (accessibility, that is, people with disabilities how to use the site). Sometimes this is a statutory requirement for American websites. Aria has some good references in this area.

Ii. Security

2.1, read the "Owasp Development Guide", it provides a comprehensive web site security guidance.

2.2. Understand SQL injection (SQL injection) and its prevention methods.

2.3, never trust the user submitted data (cookies are also submitted by the client!).

2.4. Do not store the password of the user in clear text (Plain-text), and then store it after hash processing.

2.5, do not be too confident of your user authentication system, it may easily be breached, and you do not realize that there is a relevant vulnerability in advance.

2.6. Learn how to handle credit cards.

2.7, in the login page and other processing sensitive information page, use Ssl/https.

2.8, know how to deal with session hijacking (session hijacking).

2.9, avoid "cross-site Execution" (cross site SCRIPTING,XSS).

2.10, to avoid "cross-domain Forgery request" (Cross site request forgeries,xsrf).

2.11, timely patched, so that your system always keep up with the latest version.

2.12, confirm your database connection information security.

2.13, tracking the latest development of attack technology, as well as the platform you use the latest security vulnerabilities.

2.14. Read Google's browser safety manual (Browser Security Handbook).

2.15, read "Hacker Handbook of Network Software" (The Web Creator Hackers Handbook).

Iii. Performance (configured)

3.1. Use caching whenever possible (caching). Properly understand and use HTTP caching and HTML5 offline storage.

3.2, optimize the picture. Do not put a 20KB picture file as a recurring page background pattern.

3.3. Learn how to compress content with gzip/deflate (deflate method is preferable).

3.4. Combine multiple style sheet files or script files into one file, which reduces the number of HTTP requests to the browser and reduces the total volume of gzip compressed files.

3.5, browse Yahoo's exceptional configured website, which has a large number of excellent front-end performance recommendations, as well as their yslow tools. Google's page speed is another tool for analyzing Web page performance. Both require installation of Firebug.

3.6. If your Web page uses a large number of small volume images (such as toolbars), you should use CSS image Sprite to reduce the number of HTTP requests.

3.7, large flow of the site should consider the Web page objects scattered in multiple domain names (split rs across domains).

3.8. Static content (such as images, CSS, JavaScript, and other cookie-independent web content) should be placed on a separate domain that does not need to use cookies. If there is a cookie under the domain name, then each HTTP request sent by the client to the domain name will be accompanied by a cookie content. A good way to do this is to use the Content distribution network (IBuySpy Network,cdn).

3.9, the browser to complete the Web page rendering required to minimize the number of HTTP requests.

3.10, using Google's closure compiler compressed JavaScript files, YUI compressor can also be.

3.11, to ensure that the site root directory favicon.ico files, because even if the Web page does not include this file, the browser will automatically send its request. So if this file does not exist, a large number of 404 errors will be generated, consuming your server's bandwidth.

SEO (Search Engine optimization,seo)

4.1, the use of "search engine friendly" url form, such as Example.com/pages/45-article-title, rather than example.com/index.php?page=45.

4.2, do not use the "click here" hyperlink, because this is tantamount to wasting an SEO opportunity, but also reduce the "screen reader" (The effect of the use of screens readers).

4.3, create an XML sitemap file, its default location is generally/sitemap.xml (that is, placed in the site root directory).

4.4. When you have multiple URLs pointing to the same content, use it in the code of the Web page.

4.5, using Google's webmaster tools and Yahoo site Explorer.

4.6. Use Google Analytics (or open Source Traffic analysis tool Piwik) from the start.

4.7, know the role of robots.txt, as well as search engine spider working principle.

4.8, the www.example.com access request to the example.com (using the moved Permanently redirect), or to the contrary, the purpose is to prevent Google from using them as two sites, separate calculation rankings.

4.9, know that there are malicious or improper behavior of the network spider.

4.10, if your site has non-text content (such as video, audio, etc.), you should refer to Google's sitemap extension protocol.

V. Technology (Marvell)

5.1, understand the HTTP protocol, and concepts such as GET, POST, sessions, cookies, including "stateless" (stateless) what does it mean.

5.2, make sure that your xhtml/html and CSS conform to the standards of the consortium, so that they can pass the test. This allows your Web page to avoid triggering the quirky behavior of the browser (quirk) and makes it work on "screen readers" and mobile phones as well.

5.3. Understand how browsers handle JavaScript scripts.

5.4, understand how the JavaScript files on the Web page, style sheet files and other resources are loaded and run, considering how they affect the performance of the page. In some cases, you might want to place the script file at the end of the page.

5.5. Understand how JavaScript sandbox (JavaScript sandbox) works, especially if you intend to use IFRAME.

5.6, know that JavaScript may not be used or disabled, and Ajax does not necessarily run. Remember, "Do not allow script to run" (NoScript) is becoming popular among some users, the mobile browser to support the script is very different, and Google index Web pages do not run most of the script files.

5.7. Understand the difference between 301 redirects and 302 redirects (this is also an SEO-related issue).

5.8, as much as possible to understand your deployment platform (deployment platform).

5.9. Consider using style sheet resets (reset style Sheet).

5.10. Consider using JavaScript frameworks (such as jquery, MooTools, Prototype), which will allow you to not consider the differences between browsers.

Vi. Solving Bugs

6.1, understand the programmer 20% of the time for coding, 80% of the time for maintenance, according to the corresponding arrangements for time.

6.2. Establish an effective error reporting mechanism.

6.3, the establishment of certain channels or systems, so that users can contact you to make suggestions and criticisms.

6.4, for future maintenance and customer service personnel to write documents, explain how the system is running.

6.5, regular backup! (and make sure that these backups are valid.) In addition to the backup mechanism, you must also have a recovery mechanism.

6.6, use a version of the control system to store your files, such as Subversion or Git.

6.7, do not forget to do unit test (units testing), such as selenium framework will be useful to you.

This article by http://www.zenyangjianfei.cn Webmaster Friendship feeds!