O que um programador que implementa os detalhes técnicos de uma aplicação web deve considerar antes de tornar o site público? Se Jeff Atwood consegue esquecer HttpOnly cookies, sitemaps, e pedidos de falsificação cruzada tudo no mesmo site, que coisa importante eu poderia estar esquecendo também?
I'estou a pensar nisto da perspectiva de um programador web's, de tal forma que outra pessoa está a criar o design e o conteúdo real do site. Portanto, embora a usabilidade e o conteúdo possam ser mais importantes do que a plataforma, você, o programador, tem pouco a dizer sobre isso. O que você precisa se preocupar é que sua implementação da plataforma seja estável, tenha bom desempenho, seja segura e atenda a quaisquer outros objetivos comerciais (como não custar muito, demorar muito para construir, e ser classificado tão bem com o Google quanto o conteúdo suporta).
Pense nisso da perspectiva de um desenvolvedor que's fez algum trabalho para aplicações do tipo intranet em um ambiente bastante confiável, e está prestes a ter sua primeira chance e a lançar um site potencialmente popular para toda a grande rede mundial ruim.
Também, I'estou procurando por algo mais específico do que apenas um vago "padrões web" resposta. Quero dizer, HTML, JavaScript, e CSS sobre HTTP são praticamente um dado adquirido, especialmente quando eu'já especifiquei que você'é um desenvolvedor web profissional. Então, indo além disso, Quais os padrões? Em que circunstâncias, e porquê? Prover um link para a especificação do padrão's.
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***
rel="nofollow"
aos links gerados pelo usuário para evitar spam.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çõesfavicon.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)example.com/pages/45-article-title
em vez de example.com/index.php?page=45
.#
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./sitemap.xml
.<link rel="canonical" ... />
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.301 Movido Permanentemente') pedindo
www.example.com' para `example.com' (ou o contrário) para evitar a divisão do ranking do google entre os dois sites.