Algunas veces no nos paramos a pensar en los cambios que añade una web, en este caso Google, los problemas que pueden aparecer en tema de rendimiento. Y estos problemas suelen ser fundamentales a la hora de la impresión que se lleva un usuario de la web, claro, que Google no se caracteriza por problemas de rendimiento y los expertos que están trabajando allá deben ser de lo mejorcito que existe.
Después de este rollo introductorio, me gustaría apuntar los 3 aspectos que utiliza Google para mejorar el rendimiento que se centran sobre todo en la reducción del número de peticiones HTTP:
Compilación de Javascript: mediante Closure Compiler, consigue reducir el tamaño de los ficheros js, reutilizar variables, …
JSONP bajo demando: JSONP permite envolver la respuesta JSON con una llamada Javascript. Se realizan llamadas directas al script en vez de usar Ajax, lo cual permite hacer llamadas crossdomain y que el navegador lo cachee perfectamente. El problema es que si se añade la llamada con un createElement, el navegador se queda cargando, por lo que es mejor meterlo entre un setTimeout.
DATA URIs: es un método de añadir contenido en URLs usando base64, el problema es que IE8 sólo admite DATA URIs de 32k, por lo que dividen las imagenes en trozos y los “empalman” con etiquetas IMG. También han comprobado que aunque base64 añade hasta un 33% del tamaño, como lo devuelven en gzip, el tamaño final es más o menos el mismo.
Buen ejemplo para obtener la URL que nos dibuja gráficas usando Google Graph mediante procedimientos almacenados de MySQL. Está sacado de este ejemplo, que a su vez está sacado de este otro para Oracle.
DELIMITER $$
DROP FUNCTION IF EXISTS `dm_midas`.`FNC_GOOGRAPH_DB_SIZE`$$
CREATE FUNCTION `dm_midas`.`FNC_GOOGRAPH_DB_SIZE` (
p_chart_type CHAR,
p_height INT,
p_width INT) RETURNS varchar(3000) CHARSET latin1
READS SQL DATA
BEGIN
/* Author: Walter Heck - OlinData */
/* Date: 20090216 */
/* Note: After an idea by Alex Gorbachev - Pythian */
/* http://www.pythian.com/blogs/1490/google-charts-for-dba-tablespaces-allocation */
/* variable declaration */
DECLARE v_done BOOLEAN default false;
DECLARE v_url varchar(3000);
DECLARE v_schema_name varchar(3000);
DECLARE v_data_length_sum int;
DECLARE v_data_length_total int;
DECLARE v_legend_labels varchar(3000);
DECLARE v_chart_labels varchar(3000);
DECLARE v_chart_data varchar(3000);
/* Cursor declaration */
DECLARE c_schema_sizes cursor for
select
t.table_schema,
round(sum(t.data_length + t.index_length) / 1024 / 1024) as data_length_schema
from
information_schema.tables t
group by
t.table_schema
order by
t.table_schema;
/* Handler declaration */
DECLARE CONTINUE HANDLER FOR NOT FOUND SET v_done = true;
/* Initialize the variables */
SET v_legend_labels = '';
SET v_chart_labels = '';
SET v_chart_data = '';
/* Get the total data length + index_length for all tables */
select
round(sum(t.data_length + t.index_length) / 1024 / 1024) as data_length_total
into
v_data_length_total
from
information_schema.tables t;
/* Open the cursor */
OPEN c_schema_sizes;
/* Loop through the cursor */
get_data: LOOP
/* Fetch the next row of data into our variables */
FETCH c_schema_sizes INTO v_schema_name, v_data_length_sum;
/* if there is no more data, v_done will be true */
IF v_done THEN
/* Exit the loop */
LEAVE get_data;
END IF;
/* Add the schema name to the labels for the legend */
IF v_legend_labels = '' THEN
SET v_legend_labels = v_schema_name;
ELSE
SET v_legend_labels = concat(v_legend_labels, '|', v_schema_name);
END IF;
/* Add the total size of the schema to the labels */
IF v_chart_labels = '' THEN
SET v_chart_labels = v_data_length_sum;
ELSE
SET v_chart_labels = concat(v_chart_labels, '|', v_data_length_sum);
END IF;
/* Get the percentage of the total size as the graph's data */
IF v_chart_data = '' THEN
SET v_chart_data = ROUND(v_data_length_sum / v_data_length_total, 2) * 100;
ELSE
SET v_chart_data = concat(v_chart_data, ',', ROUND(v_data_length_sum / v_data_length_total, 2) * 100);
END IF;
END LOOP get_data;
/* Close the cursor */
CLOSE c_schema_sizes;
/* Build up the google graph url */
SET v_url = 'http://chart.apis.google.com/chart?';
SET v_url = CONCAT(v_url, 'cht=', p_chart_type);
SET v_url = CONCAT(v_url, '&chs=', p_width , 'x', p_height);
SET v_url = CONCAT(v_url, '&chtt=Database Sizes (MB)');
SET v_url = CONCAT(v_url, '&chl=', v_chart_labels);
SET v_url = CONCAT(v_url, '&chd=t:', v_chart_data);
SET v_url = CONCAT(v_url, '&chdl=', v_legend_labels);
/* return the url as the function's result */
RETURN v_url;
END$$
DELIMITER ;
Como se puede ver, existen dos scripts dentro de npm: build que compila el js y extrae los CSS, y dev, que arranca el servidor de webpack habilitando HMR (🎶 ¡ya no puedo vivir sin él! 🎶).
Ambas configuraciones de webpack usan un script en común (webpack.config.common.js):
const webpack = require( 'webpack' );
const path = require( 'path' );
// Carga los ficheros .vueconst VueLoaderPlugin = require( 'vue-loader/lib/plugin' );
// Configura stylelintconst StyleLintPlugin = require( 'stylelint-webpack-plugin' );
// Para obtener un path para los aliasfunctionresolve( dir ) {
return path.join( __dirname, '.', dir );
}
module.exports = {
mode: 'production',
// Fichero inicial del proyecto
entry: './js/main.js',
// Fichero final para incluir
output: {
filename: 'js/main.js',
publicPath: '/dist/',
},
module: {
// Reglas para los ficheros
rules: [
{
test: /\.js$/,
exclude: /node_modules/,
loader: 'babel-loader',
},
{
test: /\.vue$/,
loader: 'vue-loader',
},
{
test: /\.css$/,
use: [
'css-loader',
'sass-loader',
],
},
],
},
plugins: [
new webpack.HotModuleReplacementPlugin(),
new VueLoaderPlugin(),
new StyleLintPlugin( {
files: [ '**/*.{vue,htm,html,css,sss,less,scss,sass}' ],
} ),
],
resolve: {
extensions: [ '.js', '.vue', '.json' ],
alias: {
'@': resolve( '' ),
},
},
};
El frontend se gestiona desde el fichero main.js, que inicializará Vue y añadirá el componente principal:
import Vue from 'vue';
import Buefy from 'buefy';
import'buefy/dist/buefy.css';
import App from './components/App.vue';
import'@/assets/scss/main.scss';
Vue.use( Buefy );
new Vue( {
el: '#app',
components: {
App,
},
render: ( c ) => c( 'app' ),
} );
// accept replacement modulesif ( module.hot ) {
module.hot.accept();
}
Y ya por último el componente App.vue, que muestra simplemente un poco de HTML
Una de las cosas que mas me gusta del iPhone/iPod Touch es que cuando estás metiendo una password ves el último carácter que has tecleado.
Por ello he hecho este pequeño plugin para jQuery (inacabado) que realiza la misma función. Muestra la última letra tecleada y oculta el resto. Para conseguirlo lo que he hecho es transformar el input en tipo text y guardar lo que se va tecleando.
Le faltan muchas cosas por hacer, y fallan otras, por ejemplo tratar el pulsar los cursores, restaurar el valor antes del submit del formulario, ocultar el texto despues del formulario, …
Yo personalmente no lo usaría en mi página ni loco, pero para experimento no está mal.
Interesantes consejos que nos ofrece Ilia Alshanetsky sobre la optimización de nuestras aplicaciones. Resumiendo el PDF de una charla que dió que ha compartido, tenemos:
Ten claro que va a hacer tu aplicación antes de meterte a optimizar
Basa tus cálculos sobre crecimiento y escalabilidad sobre datos reales, no sobre pajaras mentales de los comerciales
Más código no implica más lentitud, modulariza tu código para obtener mejores resultados
Piensa sobre el tiempo/gasto de desarrollo por ingenieros y el gasto en nuevo hardware. Esta solución no siempre es válida, ya que evitar cuellos de botella añadiendo servidores puede ser causa de mayores problemas en el futuro. Si tu código o consultas a la BD no son eficiente, es mejor optimizarlas. Para conseguir una mejora de rendimiento del 5% mejor no te molestes en optimizar el código.
La optimización de código puede originar fallos en otras partes de la aplicación
Cuidado con los includes: la compilación puede tardar más que la propia ejecución
Cache, preferiblemente en memoria, tanto datos recuperados de la BD como procesos que tarden en ejecutarse
No todo tiene que ser en tiempo real
Fíjate sobre todo en la base de datos, suele ser lo primero que necesita optimización
Usa herramientas para encontrar los cuellos de botella
Micro-optimizaciones no solucionarán tus problemas de rendimiento
Si crees que vas a crecer, la escalabilidad es más importante que la velocidad
No reinventes la rueda, crearte funciones que hacen lo mismo que funciones nativas de PHP es inutil
La verdad es que tiro de vez en cuando Google Translate, pero sobre todo para temas personales, para alguna aplicación web no creo que sea muy útil, entre otras cosas porque a veces las traducciones en algunos casos son un poco raras, pero nunca vienen mal tener esta librería para realizar traducciones.
El uso es muy sencillo:
require_once('googleTranslate.class.php');
$gt = new GoogleTranslateWrapper();
/* Traduce una pagina web */
$page_contents = file_get_contents('http://some-web-page/');
/* Traduce al frances */
echo $gt->translate(page_contents , "fr", "en");
/* Si hay error lo muestra */
if(!$gt->isSuccess()) {
echo $gt->getLastError();
}
Actualización: me avisa Javier Martín que él ha implementado una librería parecida que añade algunas características interesantes como independencia de CURL.