Comparativa de rendimiento de plantillas Wordpress

Como sabemos desde hace algún tiempo en muchos casos se ha ido dejando de lado el rendimiento de los sitios web dando prioridad a otros aspectos como eran la “espectacularidad” del sitio y la inserción numerosos scripts por parte del programador que ralentizaban de manera increíble la carga de una página.

Esta tendencia está cambiando en gran parte a las preferencias de buscadores como google en la red .net a situar mejor a aquellos sitios que tienen una carga de página más liviana, y así de paso para promocionar sus servicios como por ejemplo page speed service.

La razón de realizar esta comparativa de rendimiento de plantillas WordPress es simplemente analizar la evolución en este aspecto de estas themes con respecto al rendimiento. Sabemos que existen numerosas plantillas en el mercado pero nos centraremos únicamente en las que proporciona WordPress al inicio de la instalación:

• Twenty Fifteen


• Twenty Fourteen


• Twenty Thirteen

Para realizar la métrica utilizaremos PageSpeed Insights de Google.

Nota: existen factores externos de terceros que pueden afectar a la carga de una página como puede ser el servidor que aloja el sitio o la velocidad de transferencia, en nuestro caso y para que la comparativa sea más justa se ha procurado realizar esta comparativa en las mismas condiciones para todas las plantillas.

Twenty Fifteen

Resultado Móvil: 64 / Resultado Ordenador: 74

Twenty Fourteen

Resultado Móvil: 67 / Resultado Ordenador: 78

 

Twenty Thirteen

Resultado Móvil: 68 / Resultado Ordenador: 83

 

 

Resultado

Como vemos no hay grandes diferencias entre ellos pero estamos viendo que la evolución de las plantillas tampoco muestra una mejora en el rendimiento.

Comparativa de rendimiento de plantillas Wordpress

Timeout en MySQL con Entity Framework

Si se produce un timeout en MySQL con Entity Framework la primera opción que se nos podría ocurrir es agregar el parámetro default command timeout en la cadena de conexión:

<add name="Entities" connectionString="metadata=res://*/DAL.MyModel.csdl|res://*/DAL.MyModel.ssdl|res://*/DAL.MyModel.msl;provider=MySql.Data.MySqlClient;provider connection string='server=localhost;persistsecurityinfo=False;user id=root;password=;database=myddatabase;default command timeout=300'" providerName="System.Data.EntityClient" />

Por desgracia esta solución no funciona debido a un bug en el connector / NET de MySQL. Ver ref. bug.

Por suerte existe una opción para cambiar este valor para el object context en Entity Framework, dependiendo de la versión de Entity Framework:

Entity Framework 6:

this.context.Database.CommandTimeout = 180;

Entity Framework 5:

((IObjectContextAdapter)this.context).ObjectContext.CommandTimeout = 180;

Entity Framework 4 e inferiores:

this.context.CommandTimeout = 180;

Timeout en MySQL con Entity Framework

Convertir UNIX TimeStamp a DateTime

Es posible que en alguna ocasión te hayas encontrado con valores de fecha que aparentemente no lo son, pueden ser generalmente valores enteros muy grandes.

En mi experiencia lo que puedes estar viendo es un valor almacenado en un formato Excel o un UNIX timestamp.

Para convertir UNIX TimeStamp a DateTime en C# .Net podremos utilizar lo siguiente:

public static DateTime UnixTimeStampToDateTime( double unixTimeStamp )

 // Unix timestamp son los segundos pasados después de una época
 System.DateTime dtDateTime = new DateTime(1970,1,1,0,0,0,0,System.DateTimeKind.Utc);
 dtDateTime = dtDateTime.AddSeconds( unixTimeStamp ).ToLocalTime();
 return dtDateTime;

Convertir UNIX TimeStamp a DateTime

Copiar y restaurar bases de datos MySQL con codificación de caracteres intacta

Si quieres preservar caracteres como ñ, ó, ç u otros del estilo cuando migras una base de datos MySQL deberás usar mysqldump con las siguientes opciones:

mysqldump -u <tu_usario> -p <tu_password> –default-character-set latin1 –skip- character-set <tu_db> archivo.sql

Para restaurarla:

mysql -u <tu_usuario> -p <tu_password> –default-character-set latin1 <tu_db> < archivo.sql 

Esto solucionará problemas al restaurar copias de seguridad mediante código. En mi código .Net realizaba un proceso que creaba tanto la copia de seguridad en scripts .sql y también tenía otro proceso que realizaba la copia de seguridad a partir del fichero generado anteriormente. Sin embargo si el comando lo ejecutaba a través de la consola de windows el proceso lo realizaba correctamente.

Aparentemente el primer proceso generaba correctamente el archivo sql pero a la hora de ejecutar el proceso no podía continuar cuando encontraba un caracter especial, (en mi caso la ñ).

Si realizas copias programadas también deberás tenerlo en cuenta sobre todo si ejecutas la restauración mediante alguna aplicación .net. Y sobre todo leer el fichero de esta manera:

StreamReader reader = new StreamReader(file,Encoding.GetEncoding(“latin1″));

Como ves los ingleses lo tienen más fácil porque nunca le ocurrirán problemas de este tipo a no ser que trabajen con aplicaciones multiidioma. Pero en cualquier caso deberías tener siempre en cuenta copiar y restaurar bases de datos MySQL con codificación adecuada.

 

Copiar y restaurar bases de datos MySQL con codificación de caracteres intacta

Code First - Resetear Entity Framework Migrations

Si trabajas con Code First, Entity Framework y Migrations es posible que a medida que avanzas en el proyecto llegues a un estado inconsistente de la base de datos cuando intentas actualizarla con el comando update-database.

Lo ideal es solucionarlo con las opciones que te puede ofrecer codefirst, pero si aún así llegas a un punto que creas necesario resetear las migraciones lo que deberás hacer es lo siguiente:

1. – Borrar el directorio Migrations de tu proyecto.

2. – Borrar la tabla _MigrationsHistory de tu base de datos.

3. – Ejecutar el siguiente comando en la consola de administración de paquetes.

Enable-Migrations -EnableAutomaticMigrations -Force

4. – Finalmente ejecutar:

Add-Migration Initial

Todo este proceso hace que se cree un nuevo archivo Initial.cs en la carpeta de Migrations. En él podrás ver (como siempre que realizas una migración) los métodos Up() y Down() que permiten la aplicación de la migración o el regreso al estado anterior.

En este punto antes de utilizar el comando update-database deberás tener en cuenta si quieres borrar la base de datos y partir con la base de datos vacía o aprovechar los datos que ya tenías previamente.

A) Si deseas partir con una base de datos vacía será tan sencillo como borrar todas las tablas de la base de datos y ejecutar update-database.

B) Si quieres aprovechar los datos deberás profundizar en el método Up() de la migración creada y ver que tablas quieres que se regeneren. Previamente a ejecutar update-database deberás borrar las tablas que te interesan resetear en tu base de datos y comentar las líneas de código que crean las tablas que deseas conservar en el método Up(). Una vez realizadas estas dos comprobaciones podrás utilizar el comando update-database.

Espero que este artículo te haya servido de ayuda para Resetear Entity Framework Migrations.

Code First - Resetear Entity Framework Migrations