2

PHP is a ubiquitous language that among other things allows a server to render a webpage on request and serve the resulting HTML to the client.

For example, the served page might be different for different clients and the server "builds" the HTML per request.

I assume that this in general is practically instantaneous. But can this be a problem for more complex webpages? (Example: if by rendering a page the server needs to acess a third party service that may have its own latency)

If so, what solutions can we implement to avoid this problem?

  • Is accessing third party resources a real concern? You say "for example", is this your desire? There are always latency issues associated with accessing resources not on your own server. However this is not a language problem. PHP is the most popular language for web development but not the only one. – closetnoc Feb 8 '18 at 17:40
  • Yes this is my desire, (I tried to make my question more general and usefull for future people.) – gota Feb 8 '18 at 17:45
  • PHP is fine and simple to use. In particular, it is good for fetching data from other resources. However, much is dependant upon the resource, speed, reliability, consistency, etc. I have always fetched external resources independent of user input or request, but that is just me. I found it an opportunity to make up for issues that may arise, however, in cases, this may not even be necessary. Cheers!! – closetnoc Feb 8 '18 at 18:18
  • "I assume that this in general is practically instantaneous" -- It is rarely ever that fast. It is very common for PHP powered pages to take many seconds to process a request. That is usually due to busy servers and large numbers of database queries used to build pages. – Stephen Ostermiller Feb 17 '18 at 13:56
1

Is the time PHP takes to render a page and serve it to the client ever a problem?

Without finishing reading the body of your question, I have the perfect answer.

YES

This is because all of the processing time required to present the page to the user from the moment the user hits the enter key (from typing in a URL or clicking a link) is of supreme importance. It's so important that if the amount of time is too long, the guest will think the site is broken.

The process time can worsen when alot of people are connecting to the server at once because the computer will have to handle each request along with the processing of each request and if there are way too many people connecting, then some people might experience delays before any part of their request is processed. This depends on the processing power of the server.

There is a term that is valuable to you. It's called "Time to First Byte". It means the amount of time it takes for people to see any part of the page from when they first request it. webpagetest.org can measure this value for you when you run any website through them. You want to keep the value as small as possible (roughly 20 to 50ms if pages are served locally, or up to 1ms if pages are served to a far away place with poor internet connection).

Now if you're looking for a way in which the time the PHP processor takes to render a page is meant to not be an issue, then you can either:

  1. Ditch PHP and use another server side scripting language, but then you'll have to factor the processing time of that language.

  2. Look at other factors that could cause significant rendering times, such as the javascript used in todays sites to change the entire appearance and/or functionality of the site.

Even if you take one of the above two options, you still will want to factor the time the server processes requests as a whole, even if it means the PHP and/or any other server scripting languages that are used to process the requests for the guests.

1

PHP can indeed be slow at times depending on what kind of PHP is being used server side.

Computers can compute and render data very quickly, but there can be latency in the event that the server speed is not quick enough to instantaneously compute the request.

This can happen when the amount of variables stored uses up a substantial amount of RAM, or when there are simply too many processes and requests for the CPU to be able to handle all of the information.

It's also very common for PHP language to be utilizing various file_get_content and file_put_content requests. And the PHP script cannot continue processing further code until the server delivers or receives the file_get_content or file_put_content request. In other words, if it takes 2 seconds to load a page through file_get_content, that will be an extra 2 seconds that is required for your site to render and load.

0

This was an issue...20 years ago.

Sure, if you have other major issues such as poorly written php code or a server that has some serious problems with load and resource management it will eventually be problematic and manifest itself as "slow loading php pages". But the same would be true if you were using any server side scripting or calls to the databases; or really serving ANYTHING at all under those conditions.

I code exclusively data-driven php webpages on everything right now; and the php compiling and execution is NEVER an issue or slowdown for me.

Loading large resources such as jquery, css libraries, bootstrap, etc can possibly be an issue. But if you load them using async (whenever possible) then your page will continue to load and not wait on them either. And they will most likely be cached after the first time they're loaded, so zero time after that as well.

In short: While there are a lot of things to worry about when designing your web site and user interface, properly written PHP code is not one of them.

  • There is a reason why high performance web sites do not use PHP and other script type programming languages. As performance requirements go up, such as increased number of users, PHP will become an issue where further server improvements will need to be made or a change in the language used. – Rob Feb 18 '18 at 14:51
  • The Facebook framework Hack is built on PHP. Are you suggesting they are not a "high performance" site? Xenforo sites also all run on the Zend framework, also built on PHP. Starting with version 5-5.5 PHP became much more robust language, allowing interfacing. – Keith Feb 18 '18 at 17:25
  • I have not seen any benchmark tests in the last 5+ years that suggest PHP is "slow" compared to other SS programming languages. Or that it is generally the bottleneck in any performance issues related to high traffic on a website when implemented properly. If you have some sources, please quote them here as I'd love to see them. – Keith Feb 18 '18 at 17:27
  • Throw enough hardware at a language and it will appear fast to anyone. If you want to be sensible, use a language that doesn't need as much hardware to appear fast. And no interpreted language, such as PHP, can compare to a compiled language. – Rob Feb 18 '18 at 20:28
  • I want to add, but don't have the time, that Facebook has a compiler for turning PHP into native code and relies on C/C++ on the backend along with other languages. Quickly searching I couldn't find anything but one former engineer said they only use PHP because there is still legacy code lying around. New code is more likely not written in PHP or is compiled ahead of time. – Rob Feb 18 '18 at 20:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.