Que detalhes técnicos um programador de uma aplicação web deve considerar antes de tornar o site público?

A ideia aqui é que a maioria de nós já deve saber o que está nesta lista. Mas pode haver apenas um ou dois itens que você não tenha realmente investigado antes, não entenda completamente, ou talvez nunca tenha ouvido falar. **Interface e Experiência do Utilizador***

• Esteja ciente de que os navegadores implementam padrões de forma inconsistente e certifique-se de que seu site funciona razoavelmente bem em todos os principais navegadores. Em um teste mínimo contra um recente motor Gecko (Firefox), um motor WebKit (Safari e alguns navegadores móveis), Chrome, seus navegadores IE suportados (tire vantagem das Application Compatibility VPC Images), e Opera. Considere também como browsers renderizam o seu site em diferentes sistemas operativos.
• Considere como as pessoas podem usar o site sem ser dos principais navegadores: telefones celulares, leitores de tela e mecanismos de busca, por exemplo. — Algumas informações de acessibilidade: WAI e Secção508, Desenvolvimento móvel: MobiForge.
• Encenação: Como implementar actualizações sem afectar os seus utilizadores. Tenha um ou mais ambientes de teste ou encenação disponíveis para implementar mudanças na arquitetura, código ou conteúdo de varredura e garantir que eles possam ser implantados de forma controlada sem quebrar nada. Tenha uma forma automatizada de implementar alterações aprovadas para o site ao vivo. Isto é implementado mais eficazmente em conjunto com a utilização de um sistema de controlo de versões (git, Subversion, etc.) e um mecanismo de construção automática (Ant, NAnt, etc.).
• Não mostre erros não amigáveis diretamente ao usuário.
• Não coloque os endereços de e-mail dos usuários em texto simples, pois eles receberão spam até a morte.
• Adicione o atributo rel="nofollow" aos links gerados pelo usuário para evitar spam.
• Construa limites bem pensados no seu site - Isto também pertence à área de Segurança.
• Aprenda como fazer aprimoramento progressivo.
• Redirecionar após um POST se esse POST foi bem sucedido, para evitar que um refresh seja submetido novamente.
• Não se esqueça de levar em conta a acessibilidade. É sempre uma boa ideia e em certas circunstâncias é um requisito legal. WAI-ARIA e WCAG 2 são bons recursos nesta área.
• Leia Don't Make Me Think. **Segurança***
• É muito para digerir, mas o guia de desenvolvimento OWASP cobre a segurança do site de cima para baixo.
• Saiba mais sobre Injection especialmente injeção SQL e como preveni-la.
• Nunca confie na entrada do usuário, nem em nada mais que venha no pedido (que inclui cookies e valores de campos de formulário ocultos!).
• Hash passwords usando sal e use sais diferentes para as suas linhas para prevenir ataques do arco-íris. Use um algoritmo de hashing lento, como bcrypt (tempo testado) ou scrypt (ainda mais forte, mas mais recente) (1, 2), para armazenar senhas. (Como Armazenar uma Senha com Segurança). O NIST também aprova o PBKDF2 para senhas de hash", e é FIPS aprovado em .NET (mais informações aqui). Evite usando a família MD5 ou SHA diretamente.
• Não tente criar o seu próprio sistema de autenticação extravagante. É uma coisa tão fácil de errar de forma sutil e não testada e você não saberia até após estar hackeado.
• Conheça as regras para processar cartões de crédito. (Veja esta pergunta também)
• Utilize SSL/TLS/HTTPS para quaisquer sites onde sejam introduzidos dados sensíveis (como credenciais, informações pessoais identificáveis, informações de cartão de crédito). Let's Encrypt é uma autoridade certificadora gratuita que pode ajudar.
• Prevenir o sequestro de sessão.
• Evite cross-site scripting (XSS).
• Evite falsificações de pedidos entre sites (CSRF).
• Evite Clickjacking.
• Mantenha o(s) seu(s) sistema(s) atualizado(s) com os últimos patches.
• Assegure-se de que as informações de ligação à sua base de dados estão seguras.
• Mantenha-se informado sobre as mais recentes técnicas de ataque e vulnerabilidades que afectam a sua plataforma.
• Leia O Manual de Segurança do Navegador do Google.
• Leia The Web Application Hacker's Handbook.
• Considere O princípio do privilégio mínimo. Tente executar seu servidor de aplicativos como não-root. (exemplo tomcat)
• Coloque rel="noopener noreferrer" em todos os links fornecidos pelo usuário com target="_blank" para evitar que o JavaScript na página de destino redirecione sua página para outro lugar, tal como uma página de login falsa. Mais informações
• Considere o uso de uma Política de Segurança de Conteúdo estrita. **Performance***
• Implementar o cache, se necessário, entender e usar cache HTTP corretamente, assim como Manifesto HTML5.
• Otimizar imagens - não use uma imagem de 20 KB para um fundo repetitivo.
• Comprima o conteúdo para velocidade, veja brotli, gzip/deflate (deflate is better).
• Combine/concatenate múltiplas folhas de estilo ou múltiplos arquivos de script para reduzir o número de conexões do navegador e melhorar a capacidade do gzip de comprimir duplicações entre arquivos.
• Dê uma olhada no site Yahoo Exceptional Performance, muitas diretrizes excelentes, incluindo a melhoria do desempenho do front-end e sua ferramenta YSlow (requer Firefox, Safari, Chrome ou Opera). Além disso, Google page speed (use com extensão do navegador) é outra ferramenta para a criação de perfis de desempenho, e também otimiza suas imagens.
• Utilizar CSS Image Sprites para pequenas imagens relacionadas como barras de ferramentas (veja o ponto "minimizar pedidos HTTP")
• Use SVG image sprites para pequenas imagens relacionadas, como barras de ferramentas. A coloração SVG é um pouco complicada. Você pode ler sobre isso aqui.
• Websites ocupados devem considerar divisão de componentes entre domínios. Especificamente...
• O conteúdo estático (isto é, imagens, CSS, JavaScript, e geralmente conteúdo que não precisa de acesso a cookies) deve ir em um domínio separado que não usa cookies, porque todos os cookies de um domínio e seus subdomínios são enviados com cada pedido para o domínio e seus subdomínios. Uma boa opção aqui é utilizar uma Rede de Entrega de Conteúdo (CDN), mas considere o caso em que essa CDN pode falhar ao incluir CDNs alternativos, ou cópias locais que podem ser servidas em seu lugar.
• Minimize o número total de solicitações HTTP necessárias para que um navegador possa renderizar a página.
• Escolha um template engine e renderize/pre-compile-a usando task-runners como gulp ou grunt
• Certifique-se de que há um arquivo favicon.ico na raiz do site, ou seja, /favicon.ico. Os navegadores irão solicitá-lo automaticamente, mesmo que o ícone não seja mencionado no HTML. Se você não tiver um /favicon.ico, isso resultará em um monte de 404s, drenando a largura de banda do seu servidor. SEO (Search Engine Optimization)
• Utilize URLs "amigáveis aos motores de busca", ou seja, utilize example.com/pages/45-article-title em vez de example.com/index.php?page=45.
• Quando utilizar # para conteúdo dinâmico mude o # para #! e depois no servidor $_REQUEST["_escaped_fragment_"] é o que o googlebot utiliza em vez de #!. Em outras palavras, ./##!page=1 torna-se ./?_escaped_fragments_=page=1. Também, para usuários que podem estar utilizando FF.b4 ou Chromium, history.pushState({"foo": "bar"}, "About", "./?page=1"); É um ótimo comando. Portanto, mesmo que a barra de endereço tenha mudado a página não é recarregada. Isto permite que você utilize ? ao invés de #! para manter o conteúdo dinâmico e também dizer ao servidor quando você enviar o link por e-mail que estamos depois desta página, e o AJAX não precisa fazer outro pedido extra.
• Não utilize links que digam "clique aqui". Você está desperdiçando uma oportunidade de SEO e isso torna as coisas mais difíceis para as pessoas com leitores de tela.
• Tenha um XML sitemap, de preferência no local padrão /sitemap.xml.
• Use `` quando você tem várias URLs que apontam para o mesmo conteúdo, esta questão também pode ser abordada a partir de Google Webmaster Tools.
• Use Ferramentas do Google para webmasters e Ferramentas do Bing para webmasters.
• Instale Google Analytics logo no início (ou uma ferramenta de análise de código aberto como Piwik).
• Saiba como funcionam robots.txt e as aranhas dos motores de busca.
• Redirecionar solicitações (utilizando 301 Movido Permanentemente') pedindowww.example.com' para `example.com' (ou o contrário) para evitar a divisão do ranking do google entre os dois sites.
• Saiba que pode haver aranhas mal-comportadas por aí.
• Se você tiver conteúdo que não seja de texto, verifique as extensões do mapa de sites do Google para vídeos, etc. Há algumas boas informações sobre isso em resposta de Tim Farley. **Tecnologia***
• Entenda HTTP e coisas como GET, POST, sessões, cookies, e o que significa ser "stateless".
• Escreva o seu XHTML/HTML e CSS de acordo com as especificações W3C e certifique-se de que eles validam. O objetivo aqui é evitar modos quirks do navegador e como bônus facilitar muito o trabalho com navegadores não tradicionais como leitores de tela e dispositivos móveis.
• Entenda como o JavaScript é processado no navegador.
• Entenda como o JavaScript, folhas de estilo e outros recursos utilizados pela sua página são carregados e considere o seu impacto no desempenho percebido. Agora é amplamente considerado apropriado mover scripts para a parte inferior de suas páginas, com exceções tipicamente sendo coisas como aplicativos analíticos ou calços HTML5.
• Entenda como o JavaScript sandbox funciona, especialmente se você pretende usar iframes.
• Esteja ciente de que o JavaScript pode e será desativado, e que o AJAX é, portanto, uma extensão e não uma linha de base. Mesmo que a maioria dos usuários normais o deixem ligado agora, lembre-se que NoScript está se tornando mais popular, os dispositivos móveis podem não funcionar como esperado, e o Google não executará a maior parte do seu JavaScript ao indexar o site.
• Saiba a diferença entre 301 e 302 redirecionamentos (esta também é uma questão de SEO).
• Saiba o máximo que puder sobre a sua plataforma de implementação.
• Considere usar uma Reset Style Sheet ou normalize.css.
• Considere frameworks JavaScript (tais como jQuery, MooTools, Prototype, Dojo ou YUI 3), o que irá esconder muitas das diferenças do navegador ao usar o JavaScript para manipulação DOM.
• Tomando o desempenho percebido e frameworks JS juntos, considere o uso de um serviço como a Google Libraries API para carregar frameworks para que um navegador possa usar uma cópia do framework que já está em cache ao invés de baixar uma cópia duplicada do seu site.
• Não reinvente a roda. Antes de fazer QUALQUER coisa procure por um componente ou exemplo de como fazê-lo. Existe uma probabilidade de 99% que alguém o tenha feito e lançado uma versão OSS do código.
• Ao lado disso, não comece com 20 bibliotecas antes mesmo de ter decidido quais são as suas necessidades. Particularmente na web do lado do cliente onde é quase sempre mais importante manter as coisas leves, rápidas e flexíveis. **Corrigir erros***
• Entenda que você vai gastar 20% do seu tempo codificando e 80% dele mantendo, então codifique de acordo.
• Configure uma boa solução de relatório de erros.
• Tenha um sistema para que as pessoas o contactem com sugestões e críticas.
• Documente como a aplicação funciona para o pessoal de suporte futuro e para as pessoas que realizam a manutenção.
• Faça backups frequentes! (E certifique-se de que esses backups estão funcionais) Tenha uma estratégia de restauração, não apenas uma estratégia de backup.
• Use um sistema de controle de versão para armazenar seus arquivos, como Subversion, Mercurial ou Git.
• Não se esqueça de fazer seu Teste de Aceitação. Estruturas como Selenium podem ajudar. Especialmente se você automatizar completamente seus testes, talvez usando uma ferramenta de Integração Contínua, tal como Jenkins.
• Assegure-se de que você tem logon suficiente usando frameworks como log4j, log4net ou log4r. Se algo correr mal no seu site ao vivo, vai precisar de uma forma de descobrir o quê.
• Ao efectuar o registo certifique-se de que capta tanto as excepções tratadas, como as excepções não tratadas. Relate/analise a saída do log, pois isso lhe mostrará onde estão as principais questões no seu site. **Outros***
• Implementar monitoramento e análise tanto do lado do servidor quanto do lado do cliente (deve-se ser pró-ativo em vez de reativo).
• Use serviços como UserVoice e Intercom (ou qualquer outra ferramenta similar) para manter contato constante com seus usuários.
• Siga o Vincent Driessen do modelo de ramificação Git. Muitas coisas omitidas não necessariamente porque não são respostas úteis, mas porque ou são muito detalhadas, fora do escopo, ou vão um pouco longe demais para alguém que quer ter uma visão geral das coisas que deveria saber. Por favor, sinta-se livre para editar isto também, eu provavelmente perdi algumas coisas ou cometi alguns erros.