Contenido

No uses @import

9 abr

+ 10

¿Que momento sería mejor para optimizar nuestros CSS que el día en el que no tenemos ninguno cargado? Steven Souders publica hoy un interesante artículo en el que nos aconseja no usar la propiedad @import del CSS y nos invita a mejorar el rendimiento de nuestras páginas mediante el tag <link />.

<link /> versus @import

Existen dos formas de cargar hojas de estilos (CSS) mediante HTML. Las dos funcionan de formas diferentes para conseguir un mismo objetivo, cargar un fichero .css y darle color y forma a nuestro contenido.

<link />

Se trata de un tag que los estándares web indican que debe ir declarado entre los tags <head />, este tag indica una relación con un documento externo. Con él, indicamos los ficheros RSS, los favicon y por supuesto, las hojas de estilos.

Para ello, hacemos uso del atributo rel, y posteriormente mediante el atributo href indicamos la ubicación del fichero que relacionamos directamente con el HTML. También es interesante destacar el atributo media, que indica que dispositivos van a poder usar ese documento.

<link rel='stylesheet' href='a.css' media='screen'>

@import

Se trata de una funcionalidad del CSS que nos permite cargar un fichero .css desde el propio CSS. Al igual que el anterior, con ella podemos indicar la ruta y el tipo de dispositivo que podrá usar ese código CSS.

Esta funcionalidad omite el atributo rel, debido a que se ha de llamar desde el tag <style /> o desde un fichero .css, entendiéndose así que se ha de tratar de un fichero CSS.

<style type="text/css">
	@import url('a.css') screen;
</style>

¿Cual es mejor?

Steve Souders, nos muestra mediante un pequeño test las diferentes opciones posibles que ha usado para ilustrar su prueba.

@import @import

<style>
@import url('a.css');
@import url('b.css');
</style>

En la prueba que opta por cargar dos fichero .css mediante la @import vemos como ambos ficheros cargan a la vez. Si generalmente usas este sistema, no deberías tener problemas de rendimiento ya que ambas peticiones se ejecutan simultáneamente evitando tiempos de espera innecesarios.

<link /> @import

<link rel='stylesheet' type='text/css' href='a.css'>
<style>
@import url('b.css');
</style>

Si por el contrario usas este sistema, todas las versiones de Internet Explorer (6,7 y 8)  harán que los ficheros se carguen secuencialmente así que primero se cargará a.css y cuando este termine comenzará b.css.

<link /> con @import

//HTML
<link rel='stylesheet' type='text/css' href='a.css'>

//CSS
@import url('b.css');

Entendamos que el fichero a.css, contiene la llamada al fichero b.css. De esta forma no solo ocurre en Internet Explorer, sino que la carga se convierte secuencial en todos los navegadores. Tiene sentido ya que cargamos a.css y una vez cargado lo procesamos y este nos llama a b.css.

varios <link /> @import

//HTML
<link rel='stylesheet' type='text/css' href='a.css'>
<link rel='stylesheet' type='text/css' href='proxy.css'>

//PROXY.CSS
@import url('b.css');

Mediante este sistema, descubrimos que Internet Explorer se vuelve loco. Únicamente en Internet Explorer, carga el fichero a.css y simultáneamente comienza a cargar el fichero proxy.css (que únicamente tiene la llamada a b.css), una vez terminado el fichero proxy.css este se queda esperando a que termine a.css para lanzar la llamada a b.css. Mejor ver la imagen.

link-blocks-import
(Ver Imagen)

muchos @import

<style>
@import url('a.css');
@import url('b.css');
@import url('c.css');
@import url('d.css');
@import url('e.css');
@import url('f.css');
</style>
<script src='one.js' type='text/javascript'></script>

Misteriosamente Internet Explorer vuelve a hacer de las suyas, en este caso, el fichero Javascript se carga antes que los ficheros .css, haciendo que toda relación con las posibles sentencias CSS no sean tratadas en el momento de la carga. A la vez que carga el fichero javascript, se lanza de forma secuencial la carga de los ficheros CSS.

<link /> <link />

<link rel='stylesheet' type='text/css' href='a.css'>
<link rel='stylesheet' type='text/css' href='b.css'>

Sin duda la mejor opción, para todos los navegadores es el uso del tag <link /> que permite que ambos ficheros sean cargados de forma simultánea.

Conclusión

No uses @import. Y si lo has de usar, se consciente de lo que implica.

CSS Naked Day 09

8 abr

+ 18

Como muchos habrán visto el diseño de la web está desactivado. Esto se debe a la celebración del CSS Naked Day, un día en el que los desarrolladores web reivindicamos la importancia de cumplir los estándares web. En este día, que desde 2006 se está realizando rigurosamente por parte de la mayoría de desarrolladores del mundo entero fué una idea de Dustin Diaz y que en anteriores ediciones se pasaron fácilmente los 1000 participantes. Este año podríamos batir los 2000 y lo vamos a hacer.

¿Pero no era mañana día 9?

Si, el día del CSS Naked Day es el 9 de Abril. En algunas zonas del mundo ya el día 9 (aunque sea 8) por este motivo realmente el CSS Naked Day dura casi 48 horas. Cada uno puede implementarlo como vea, y pueda, yo personalmente estaré las 48 horas para hacer que el día 9, sin importancia de la zona geográfica en la que se haye el usuario, vea los estilos desactivados.

El viernes me vuelvo a vestir :D

ie6fixer, aplicación que añade hacks por ti

8 abr

+ 7

ie6fixer es una aplicación a la que le pasámos un fichero .css y nos revisa el contenido para aplicar los hacks para IE6 que pueda necesitar. Aunque las opciones disponibles no son muy extensas, muestran una idea muy interesante con una funcionalidad muy, pero que muy importante. Ojalá pronto no sea necesaria.

Ext Core 3.0 ha visto la luz

6 abr

+ 8

Los amantes de Ext.js deben estar contentos ya que el día 4 de este mes ha salido a la luz la versión 3.0 del Core (o funcionalidades básicas).

Ext.onReady(function() {
    Ext.DomHelper.append(document.body, {tag: 'p', cls: 'some-class'});
    Ext.select('p.some-class').update('Ext Core successfully injected');
});

Esta versión, puede ser comparada con otros frameworks, como jQuery, MooTools, Prototype,… debido a que únicamente usa dispone de las funcionalidades necesarias para manipular el DOM, gestionar Eventos, aplicar estilos CSS, todo lo que puedas necesitar de Ajax y JSON y un pequeño set de animaciones.

Esta implementación, de tan solo 25kb (minified y gzipped) permite tenerlo en cuenta a la hora de optar por un frameworks JS debido a su peso, comparable con jQuery (19kb),  MooTools (18kb) o Prototype (29kb “sin comprimir”).

Esto es una gran noticia ya que recordemos en las pruebas que estuve haciendo sobre los frameworks JS, quedó bastante claro que a falta de las pruebas de Dojo (Gonzalo, muchísimas gracias por el fichero pero aún no he tenido tiempo de mirarlo), Ext.js era el framework JS más rápido en manipulación DOM.

Al puro estilo de MooTools, Prototype y otros, Ext.js permite la creación de Clases con fin de mejorar la integración de plugins para esta framework.

Más Información

  1. Manual de Ext.js Core 3.0
  2. Guía rápida de Ext.js para amantes de jQuery.
  3. Comparativa entre Ext.js Core 3.0 y jQuery 1.3.

Creando Widgets con la nueva Widget API de WordPress 2.8

6 abr

+ 6

WordPress 2.8 incorpora como novedad una nueva API para Widgets muy, pero que muy interesante. La gente de WP-Engineer.com nos muestran un avance de lo que será desarrollar usando esta nueva funcionalidad.

class My_RSS_Widget extends WP_Widget {
	function My_RSS_Widget() {
		//Constructor
	}

	function widget($args, $instance) {
		// Pintamos el Widget
	}

	function update($new_instance, $old_instance) {
		// Guardamos en Widget
	}

	function form($instance) {
		// Backend del Widget
	}
}
register_widget('My_RSS_Widget');

La funcionalidad nos permite crear objetos que extienden de una clase WP_Widget que nos permitirá crear Widgets de una forma sencilla, los que tendremos que registrar mediante register_widget() para que esté disponible para nuestros themes.

#frase

5 abr

+ 4

Programa siempre como si el tipo que acabe manteniendo tu código fuera un psicópata violento que sabe dónde vives.

Martin Golding (via)

CSS Naked Day (9 de Abril del 2009)

5 abr

+ 14

Faltan 4 días para la llegada del CSS Naked Day, que recordemos que es un día en el que los desarrolladores web reivindicamos los estándares web desnundando nuestras aplicaciones eliminando todo rastro de CSS que podamos haber implementado en ellas.

En aNieto2k llevo 3 años (desde que comenzó) dejando “en pelotillas” la web este día, y este año no va a ser diferente.

Recordemos como implementarlo

Necesitamos una función que nos indique que estamos en el CSS Naked Day. Dustin Diaz nos ofrece esta que realiza perfectamente su comentido:

<?php
function is_naked_day($d) {
  $start = date('U', mktime(-12, 0, 0, 04, $d, date('Y')));
  $end = date('U', mktime(36, 0, 0, 04, $d, date('Y')));
  $z = date('Z') * -1;
  $now = time() + $z;
  if ( $now >= $start && $now <= $end ) {
    return true;
  }
  return false;
}
?>

Después, en nuestro <head></head> condicionaremos la visualización de los ficheros CSS indicando el día de Abril indicado para el CSS Naked Day, que este año se ha establecido el día 9.

<head>
...
<?php
if ( is_naked_day(9) ) {
  echo '<!-- naked day has no styles -->';
} else {
  echo '<link rel="stylesheet" type="text/css" href="styles.css" />';
}
?>
...
</head>

Alternativas

Hagamos que el Jueves que viene (9 de Abril) Internet sea más “nudista” que nunca. Todo por los estándares web.

Recopilación de enlaces 05-04-2009

5 abr

+ 3

Es Domingo por la mañana y hay muchas cosas analógicas que hacer (comer con la familia, salir a pasear, …) así que una recopilación rápida de cosillas interesantes:

  1. Por fin MySQL Workbench, editor visual para crear bases de datos relacionales. Gracias Pablasso.
  2. Crea un Captcha Numérico en PHP.
  3. Conviértete en un experto SEO en solo un mes.
  4. Nace Todo jQuery, un blog sobre todo lo relacionado a jQuery.
  5. CSS Hacks específicos para cada navegador.
  6. Usando las propiedades de CSS3 para crear un bonito menú.
  7. 10 ricos y creativos interfaces de usuario y como implementarlos tu mismo.

Análisis de los principales servicios de acortamiento de URL’s

4 abr

+ 10

Las herramientas como TinyURL, está muy de moda en servicios de microblogging por que ofrecen URL’s funcionales más cortas que las normales. Pero de todos los servicios existentes ¿con cual nos quedamos?

Search Engine Land, ha intentado ayudarnos a contestar a esta pregunta, con una serie de factores que han tenido en cuenta para valorar estos servicios.

shorturl-services
(Ver Imagen)

Entre los factores a tener en cuenta podemos encontrar:

  • Redirección: Código que aplica a la URL cuando redirige a la URL correcta. Vemos como los que aplican el código 301 aparecen en verde frente a los 302 que aparecen en rojo, esto es debido a que el 301 implica una redirección permanente y el código 302 se usa para redirecciones temporales. Diferencia sutil, pero importante para el SEO y la indexación de la página.
  • Trackeable: Capacidad de ser detectadas por Google Analytics u otros servicios de estadísticas. Ideal para conocer mediante que servicio acceden más a nuestras páginas.
  • Soporte por clientes: En este punto se han tenido en cuenta las integraciones en los clientes, haciendo más fácil su uso para los usuarios.
  • Tamaño del dominio: El tamaño del dominio es una pieza clave para estas pequeñas url’s, por ejemplo tinyurl.com (11 carácteres) ya parte con esa cantidad de carácteres de desventaja (aunque gana en claridad al ver la dirección) frente a is.gd (5 carácteres). Ambos servicios despues añaden el identificador único de cada URL.
  • URL’s personalizables: Tambien se mide la capacidad de permitir establecer el nombre de la URL, evitando esas combinaciones de carácteres aleatorios.
  • Compartida: Algunos servicios ofrecen la posibilidad de conocer los enlaces más visitados como por ejemplo el caso de bit.ly sobre twitter.

Si ninguno te parece interesante… createlo tu mismo :D

Crealo tu mismo

  1. Con PHP y MySQL
  2. Con PHP y sin MySQL
  3. Usa Shorty, una aplicación en PHP (con un bonito interface para contabilizar clicks)
  4. Con Apache RewriteMap
  5. Usa este plugin de WordPress, o este otro.

Optimiza la carga de imagenes de tus aplicaciones web

4 abr

+ 16

Los nuevos diseños cada vez usan más imágenes, y es normal ya que la vistosidad de los sitios web es un factor determinante a la hora de llamar la atención de usuario. Pero esto también, penaliza la carga de la página, principalmente por que ha de realizar N peticiones al servidor de aplicaciones para que este sirva las imágenes que hemos definido en nuestras aplicaciones.

En la página de resultados de Google he encontrado una técnica, que ya hemos comentado previamente, que nos ayuda a mitigar este número de peticiones.

background-position-power
(Ver Imagen)

La idea es muy sencilla. Y si nos fijamos en la imagen superior, veremos como la imagen nav_logo4.png engloba todas imágenes visibles de la página. Veámosla:

nav_logo4
(Ver Imagen)

Después, usando background-position haremos que únicamente se vea la porción que nos interesa en cada posición de la página.

background-position-power2
(Ver Imagen)

Actualización

He montado un ejemplo para comparar la diferencia entre usar 100 imagenes frente a usar una sola imagen con las 100 en ella.

100 imagenes / 1 sola imagen

Revisar los tiempos con Firebug.

Resultados

100 imagenes

<?php for ($x=0; $x<100; $x++):
	$file = "img".$x.".jpg";
	?>
	<img src="<?=$file?>" alt="img" />
<?php endfor;?>

El tamaño de todas las imágenes por separado es de 93kb (siendo cada una de ellas de 906 Bytes).

100-imagenes
(Ver Imagen)

1 sola imagen

<img src="bigs.jpg" alt="img" />

La imagen pesa 48KB y la he creado copiando el resultado anterior y guardándola con el máximo de calidad posible.

1-imagen
(Ver Imagen)

La diferencia es increíble, 599ms (100 imágenes) frente a los 81 ms de 1 sola imagen. Interesante para tenerlo en cuenta a la hora de usar sprites en nuestras aplicaciones.

Más información

  1. Gimenete nos muestra como generar estos CSS Sprites.
  2. Generador de sprites y CSS online.